Pular para o conteúdo

Arquitetura

Como o Clearcote adiciona, em camadas, controle de privacidade e de identidade ao Chromium — de forma transparente.

A stack

O build aberto é uma stack enxuta e auditável. Cada camada é aberta e substituível:

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

O build licenciado (Grátis com GitHub e Pro) adiciona, sobre essa stack, patches que não são públicos. O SHA-256 dele é verificado no download, mas ele não pode ser recompilado a partir do código-fonte público.

No nível do motor, não por injeção de script

A maioria das ferramentas de “stealth” injeta JavaScript para sobrescrever propriedades de navigator em tempo de execução. Isso é frágil e acaba se denunciando — as próprias sobrescritas viram um fingerprint (cadeias de protótipo erradas, timing dos getters, ausência da stringificação de código nativo).

O Clearcote, em vez disso, modifica o motor em C++. Os valores que uma página lê são produzidos pelos mesmos caminhos de código que o Chromium sempre usa, então não existe camada injetada para detectar. Isso cobre inclusive APIs que o JavaScript simplesmente não consegue interceptar de forma limpa.

Identidade coerente, ruído de renderização por site (farbling)

Randomizar cada sinal de forma independente produz uma identidade que não fecha — e isso denuncia na hora. O Clearcote deriva a persona de uma única seed, e deriva o ruído de renderização dessa seed combinada com o domínio registrável do site:

  • Consistente internamente — plataforma, GPU, tela e hardware batem entre si; fuso horário e idioma vêm das suas opções ou do geoip.
  • Estável por site — o mesmo site vê a mesma identidade ao longo de uma sessão.
  • Ruído de renderização por site — as leituras de canvas e WebGL mudam de um site para outro, então os hashes de renderização não batem entre domínios. Os valores da classe de hardware continuam iguais em todo lugar, como aconteceria em uma máquina real.

Esse modelo de ruído por eTLD+1 é inspirado na abordagem de farbling do Brave. O ruído depende da seed: sem uma seed --fingerprint, não há ruído nenhum.

Persona coerente — uma seed, uma máquina crível

O Clearcote vai um passo além do ruído por sinal. Uma única seed --fingerprint deriva uma persona coerente para a plataforma que você apresenta — uma única máquina crível, com propriedades que batem entre si. Por padrão, o SDK apresenta o sistema operacional do seu host (Windows ou Linux); um UA de macOS e uma persona Android, em regime de melhor esforço, estão disponíveis sob demanda. A partir da seed, ele sorteia uma faixa de hardware (núcleos de CPU e RAM que de fato são vendidos juntos — nunca 20 núcleos com 4 GB), uma resolução de tela compatível, profundidade de cor e device pixel ratio, uma GPU coerente e uma versão real do Chrome.

As propriedades da classe de hardware ficam constantes durante a sessão — uma máquina real não muda a quantidade de núcleos nem o tamanho da tela de um site para outro —, enquanto as superfícies de renderização perturbadas (pixels de canvas e WebGL) continuam com farbling por site, para que você siga descorrelacionado entre domínios. Client rects e o áudio renderizado não são perturbados — embora o sampleRate, o baseLatency e o outputLatency do AudioContext venham da persona sempre que houver uma ativa; o que recebe farbling e o que deliberadamente não recebe explica esse trade-off.

Por que isso importa: o sinal de detecção moderno mais forte não é nenhum valor isolado, e sim a contradição interna — uma máquina que diz ter um sistema operacional mas renderiza como outro, ou que combina uma CPU com muitos núcleos com pouca RAM. Derivar todos os sinais de uma única tabela de persona faz com que todos contem a mesma história. Tudo isso sai da mesma seed --fingerprint que você já passa (nenhuma flag nova).

Há três formas de apresentar uma identidade: o preset light-stealth (alguns valores de metadados, sem seed, sem ruído), a persona com seed descrita acima ou um perfil capturado de uma máquina real (fingerprint_profile, ou profile="auto" a partir da biblioteca de perfis do build licenciado). Veja Recomendações para saber por qual começar.

O que ele controla

Canvas 2DRenderer WebGL (GPU constante na sessão)Limites do getParameter do WebGLAdaptador WebGPUFontesFuso horárioIdioma (Accept-Language, navigator.languages, Intl)User-Agent + UA-CHPersona do ClientHello TLS (JA3/JA4)hardwareConcurrencydeviceMemoryGeometria da telaCota de armazenamentonavigator.webdriverIndícios de headlessShadow roots fechadosIP do proxy no WebRTCnavigator.getBatterynavigator.connectionMapa de layout do tecladogetScreenDetails / várias telasMedia queries CSS pointer/hoverMetadados do AudioContext (taxa de amostragem / latência)Vozes de síntese de falanavigator.shareCoerência do SO na letra de unidade em URLsAgente de IA no navegadorCodecs do MediaCapabilitiesenumerateDevicesUA-CH bitness/WoW64

Alvo de build

O build aberto tem como alvo o Windows x64 (com compilação cruzada a partir do Linux) e o Linux x64 (nativo), sobre o Chromium 149; o build licenciado está no Chromium 153. A receita completa do build aberto — e cada pegadinha do cross-build — está documentada para que qualquer pessoa consiga reproduzi-la. Veja Compilar a partir do código-fonte.