Aller au contenu

Architecture

Comment Clearcote ajoute à Chromium une couche de contrôle de la confidentialité et de l’identité — en toute transparence.

La stack

Le build ouvert est une stack légère et auditable. Chaque couche est ouverte et remplaçable :

text
            Chromium  (Google, BSD-3)
                |
   ungoogled-chromium  ->  removes Google services, telemetry, integration
                |
       Clearcote patches  ->  engine-level identity & privacy controls
                |
   reproducible build  ->  checksummed, GPG-signed, rebuildable by anyone (open build)
                |
        Clearcote Browser  +  SDK (Playwright objects) / CDP endpoint

Le build sous licence (Gratuit avec GitHub et Pro) ajoute par-dessus cette stack des patchs qui ne sont pas publics. Son SHA-256 est vérifié au téléchargement, mais il ne peut pas être recompilé à partir des sources publiques.

Au niveau du moteur, pas par injection de script

La plupart des outils « stealth » injectent du JavaScript pour écraser les propriétés de navigator à l’exécution. Cette approche est fragile et se trahit d’elle-même — les surcharges deviennent à leur tour une empreinte (chaînes de prototypes incorrectes, timing des getters, absence de « native code » à la stringification).

Clearcote modifie plutôt le moteur C++. Les valeurs lues par une page sont produites par les mêmes chemins de code que Chromium utilise toujours : il n’y a donc aucune couche injectée à détecter. Cela couvre des API que JavaScript ne peut pas du tout intercepter proprement.

Identité cohérente, bruit de rendu par site (farbling)

Randomiser chaque signal indépendamment produit une identité qui ne tient pas debout — un signe qui ne trompe pas. Clearcote dérive le persona d’une seule seed, et dérive le bruit de rendu de cette seed combinée au domaine enregistrable du site :

  • Cohérence interne — plateforme, GPU, écran et matériel concordent entre eux ; le fuseau horaire et la langue proviennent de vos options ou de geoip.
  • Stable par site — un même site voit la même identité pendant toute la session.
  • Bruit de rendu par site — les lectures canvas et WebGL (readbacks) diffèrent d’un site à l’autre, si bien que les hashs de rendu ne correspondent pas d’un domaine à l’autre. Les valeurs liées au matériel restent identiques partout, comme sur une vraie machine.

Ce modèle de bruit par eTLD+1 s’inspire de l’approche de farbling de Brave. Le bruit est conditionné à la seed : sans seed --fingerprint, pas de bruit.

Persona cohérent — une seed, une machine crédible

Clearcote va plus loin que le bruit signal par signal. Une seule seed --fingerprint produit un persona cohérent pour la plateforme que vous présentez — une seule machine crédible dont les propriétés concordent entre elles. Par défaut, le SDK présente l’OS de votre hôte (Windows ou Linux) ; un UA macOS et un persona Android en best-effort sont disponibles sur demande. À partir de la seed, il tire un niveau de matériel (cœurs CPU et RAM réellement vendus ensemble — jamais 20 cœurs avec 4 Go), une résolution d’écran, une profondeur de couleur et un device pixel ratio assortis, un GPU cohérent et une vraie version de Chrome.

Les propriétés liées au matériel restent constantes pendant la session — une vraie machine ne change pas de nombre de cœurs ni de taille d’écran d’un site à l’autre — tandis que les surfaces de rendu perturbées (pixels canvas et WebGL) restent soumises au farbling par site, pour que vous restiez décorrélé d’un domaine à l’autre. Les client rects et l’audio rendu ne sont pas perturbés — en revanche, les valeurs sampleRate, baseLatency et outputLatency de l’AudioContext sont servies par le persona dès qu’un persona est actif ; la section ce qui est soumis au farbling, et ce qui ne l’est volontairement pas explique ce compromis.

Pourquoi c’est important : le signal de détection moderne le plus fort n’est pas une valeur isolée, c’est la contradiction interne — une machine qui se déclare sous un OS mais dont le rendu trahit un autre, ou qui associe un CPU à nombreux cœurs à trop peu de RAM. Dériver chaque signal d’une seule table de persona leur fait raconter la même histoire. Le tout repose sur la seed --fingerprint que vous passez déjà (aucun nouveau flag).

Il existe trois façons de présenter une identité : le preset light-stealth (quelques métadonnées, pas de seed, pas de bruit), le persona dérivé d’une seed décrit ci-dessus, ou un profil capturé sur une vraie machine (fingerprint_profile, ou profile="auto" depuis la bibliothèque de profils du build sous licence). Consultez les Recommandations pour savoir par où commencer.

Ce que Clearcote contrôle

Canvas 2DRenderer WebGL (GPU constant sur la session)Limites getParameter WebGLAdaptateur WebGPUPolicesFuseau horaireLangue (Accept-Language, navigator.languages, Intl)User-Agent + UA-CHPersona TLS ClientHello (JA3/JA4)hardwareConcurrencydeviceMemoryGéométrie de l'écranQuota de stockagenavigator.webdriverIndices de mode headlessShadow roots fermésIP du proxy via WebRTCnavigator.getBatterynavigator.connectionDisposition du clavier (layout map)getScreenDetails / multi-écranMedia queries CSS pointer/hoverMétadonnées AudioContext (fréquence d'échantillonnage / latence)Voix de synthèse vocalenavigator.shareCohérence OS des lettres de lecteur dans les URLAgent IA intégré au navigateurCodecs MediaCapabilitiesenumerateDevicesUA-CH bitness/WoW64

Cibles de build

Le build ouvert cible Windows x64 (cross-compilé depuis Linux) et Linux x64 (natif), sur Chromium 149 ; le build sous licence est sur Chromium 153. La recette complète du build ouvert — y compris chaque piège de la compilation croisée — est documentée pour que chacun puisse la reproduire. Voir Compiler depuis les sources.