Importante: Este documento é um trabalho em andamento e representa uma proposta arquitetônica em estágio inicial. Ele define os limites pretendidos do sistema e os princípios de design, mas não não especificar implementações finalizadas ou garantias de segurança. Por favor, note que Eterveil é um nome provisório. O objetivo desta postagem é coletar feedback da comunidade, então por favor, compartilhe seu feedback!
Visão
Etherveil é um navegador baseado no Firefox/Gecko construído no conjunto de patches do navegador Tor, com Kohaku incorporado como um mecanismo de carteira nativo. A premissa central é simples: a privacidade deve ser uma propriedade do tempo de execução, não algo que os usuários configuram.
A maioria das ferramentas de privacidade sobrecarrega o usuário, ou seja, instale esta extensão, faça o roteamento por meio desta VPN, lembre-se de usar seu endereço protegido, etc., você escolhe. Etherveil trata isso como uma falha de projeto. O navegador impõe privacidade por padrão em três camadas: rede (IP e metadados de tráfego), execução (superfícies de impressão digital do navegador) e na cadeia (endereços, origem da transação, saldos). Um usuário deve ser capaz de abrir o navegador, navegar para algum site de suporte Ethereum e realizar transações sem gerar sinais distinguíveis estáveis e vinculáveis além de sua classe de anonimato atribuída (e sem exigir que o usuário entenda os mecanismos subjacentes). Etherveil substitui mecanismos de privacidade probabilísticos pela aplicação de restrições determinísticas em todas as superfícies de execução observáveis.
Invariante do Sistema
Invariante: todas as APIs de navegador observáveis devem ser resolvidas em um conjunto finito de classes de equivalência compartilhadas entre usuários dentro do mesmo Perfil de impressão digital aula.
Em palavras simples: todos que usam o mesmo perfil de privacidade parecem exatamente iguais aos sites, porque o navegador força todo o comportamento observável em um pequeno número de padrões padronizados.
Arquitetura
┌────────────────────────────────────────────────────┐
│ Etherveil Browser Shell (Firefox/Tor Fork) │
├───────────────────────────┬────────────────────────┤
│ Execution & Fingerprint │ Kohaku Engine │
│ Normalisation Layer │ (Wallet + Tx) │
│ (Tor Browser Base) │ │
├───────────────────────────┴────────────────────────┤
│ Network Privacy & Verification Layer │
│ Tor/Optional Mixnet, Helios Light Client │
│ ERC-4337 Bundler Relay │
└────────────────────────────────────────────────────┘
Camada de normalização de impressão digital
O navegador Tor já resolve a maioria dos problemas difíceis de impressão digital; estamos ampliando-o, não reinventando-o. A principal adição é o que chamamos de Perfil de impressão digital: uma classe de equivalência fixa e pré-computada sobre observáveis do navegador, construída como uma tupla que satisfaz restrições sobre sinais de navegador correlacionados derivados de distribuições empíricas, atribuídas por contexto de navegação e imutáveis durante o tempo de vida de uma sessão. Isso garante consistência entre campos (por exemplo, coerência de fuso horário-localidade-idioma) e evita falsificação de atributos independentes.
A principal decisão de design é que não se trata de configuração por usuário ou randomização de tempo de execução. A randomização é na verdade contraproducente: se a semente de ruído da tela mudar entre o carregamento da página, essa transição é uma impressão digital. Em vez disso, cada perfil é um instantâneo consistente derivado offline de distribuições do mundo real, mas não amostrado em tempo de execução, escolhido para maximizar o tamanho do conjunto de anonimato ao qual pertence. Se um site for interrompido em um perfil atribuído, todo o contexto de navegação será reiniciado em uma classe compatível diferente. Não há mutação no meio da sessão.
Superfícies normalizadas no nível Gecko/SpiderMonkey por meio de interceptação e reescrita determinística de API (não scripts de conteúdo, que são detectáveis):
navigator.*: UA, plataforma, simultaneidade de hardware, memória do dispositivoIntl/Date: fuso horário, localidade, cabeçalhos de negociação de idioma- Canvas/WebGL: saídas determinísticas por perfil; strings de fornecedores e renderizadores alinhadas à distribuição de classes
screen.*,devicePixelRatio- WebRTC: candidatos ICE suprimidos ou padronizados
- APIs de alta entropia (áudio, fontes, tempo de desempenho): quantizadas em todas as classes de perfil
Todas as APIs de alta entropia são quantizadas, unificadas ou mapeadas em classes de equivalência limitadas por perfil.
Isolamento de armazenamento e interação
Armazenar (IndexedDB, localStoragecookies, cache) é particionado por origem e perfil sem vazamento entre perfis. Além do armazenamento, os sinais de interação – tempo de rolagem, movimento do ponteiro, cadência de teclas – são suavizados e quantizados dentro de modelos estocásticos limitados. O objetivo é reduzir a entropia comportamental o suficiente para derrotar a reidentificação biométrica sem fazer com que o uso do navegador pareça quebrado. O limite de compensação entre usabilidade e entropia é um parâmetro central de design aberto do sistema.
Mecanismo de carteira Kohaku
A carteira é um subsistema de navegador nativonão uma extensão. O navegador expõe uma API de transação única para dApps e deliberadamente não revela se uma determinada transação está sendo executada de forma privada ou pública. Essa distinção é um detalhe de implementação do mecanismo, não algo que os dApps precisam saber.
dApp -> Wallet API -> Kohaku Engine -> Privacy Relay -> Chain
| Componente | Papel |
|---|---|
tornado-cash |
Camada de transação protegida padrão |
provider |
RPC unificado (Helios/nós externos/cliente local) |
pq-account |
Tipo de conta padrão ERC-4337 pós-quântico |
Todas as novas contas são pq-account contas inteligentes por padrão. As transações são roteadas através do Tornado Cash (ou, mais geralmente, uma camada de proteção zk abstrata), a menos que o usuário opte explicitamente por um fluxo público. UserOperations são enviados por meio de empacotadores ERC-4337 roteados por Tor, portanto, o IP do usuário nunca é associado a uma transação no mempool público.
Camada de privacidade de rede
A pilha de rede é herdada do navegador Tor e estendida:
- Tor (padrão): isolamento de circuito por origem; todo o tráfego e DNS totalmente roteados
- Mixnet (opcional): resistência mais forte dos metadados contra ataques de correlação temporal, às custas da latência; se isso deve ser opcional ou o padrão é adiado
- Cliente leve Helios: verificação local do estado Ethereum por meio de provas do comitê de sincronização, eliminando a dependência de provedores RPC centralizados; A resolução ENS passa apenas pelo Helios
- Modelagem de tráfego: preenchimento de latência determinística e solicitação em lote para reduzir a correlação de tempo
Modelo de ameaça
O navegador foi projetado para se defender contra:
- Análise de tráfego do ISP e do nó de saída
- Impressão digital entre sites via canvas, WebGL e outras APIs de alta entropia
- Vigilância de endpoint RPC (endereçar consultas ao Infura/Alchemy etc.)
- Clustering de endereços na cadeia e análise de gráficos de transações
- Reidentificação biométrica comportamental (mitigação limitada)
Ele não resolve totalmente (e não tem a pretensão de resolver) ataques de adversários passivos globais com visibilidade completa da rede, canais laterais no nível do sistema operacional ou de hardware ou falhas de segurança operacional do usuário.
Não-metas
Algumas coisas explicitamente fora do escopo, para manter o design coerente:
- Compatibilidade de extensões: APIs WebExtension reintroduzem superfície de identidade que prejudicaria o modelo de impressão digital
- Ajuste de impressão digital controlado pelo usuário: a garantia de anonimato depende de os usuários serem indistinguíveis uns dos outros, e não da personalização individual
- Modos de privacidade opt-in ou “melhor esforço”: o modelo só funciona se for aplicado de maneira uniforme
- Expondo o modo de execução (privado vs público) para dApps
Perguntas de design diferido
Algumas decisões que precisam ser tomadas antes da implementação, mas ainda não têm respostas corretas óbvias:
- Persistência do perfil: o mesmo perfil deve ser atribuído a uma determinada origem entre sessões ou alternado por sessão? A consistência por origem é melhor para a usabilidade; a rotação é melhor para a desvinculação.
- Padrão Mixnet: Somente Tor como linha de base com mixnet como opção ou ativado por padrão com uma saída de emergência para contextos sensíveis à latência?
- Endurecimento de interação: onde está a compensação aceitável entre supressão de entropia comportamental e usabilidade?
- Compatibilidade Web: alguns sites serão violados sob classes estritas de impressão digital. Qual é o caminho de escalonamento quando nenhuma classe de perfil de alta população compatível renderiza o site corretamente?
Fontesethresear
