Embora estejamos gratos pelos pacotes da Web e sugestões relacionadascomprometidos em enfrentar desafios específicos, acreditamos que há maneiras melhores de atingir os mesmos objetivos sem prejudicar a natureza aberta, transparente e centrada no usuário da web. Uma alternativa potencial é usar compromissos assinados para sub-recursos para download de forma independente. A descrição das alternativas exigirá um artigo separado, e alguns já foram compartilhados com os autores da especificação.
A web é um sistema aberto único graças aos links de URL
A web é valiosa porque é centrada no usuário, controlada pelo usuário e editada pelo usuário. Até mesmo usuários com pouca experiência podem descobrir quais recursos da web estão em uma página e decidir o que seu navegador deve carregar. Mesmo se você não for um especialista, você pode usar isso e instalar as extensões ou ferramentas adequadas para proteger sua privacidade.
O foco da Web nos usuários é diferente de como a maioria dos aplicativos e sistemas de distribuição de informações funcionam. A maioria dos aplicativos é uma coleção compilada de código e recursos que são difíceis ou mesmo impossíveis de separar uns dos outros para avaliar separadamente. E essa distinção importante explica por que existem tantas ferramentas de proteção de privacidade para a web e tão poucas para aplicativos "binários".
Basicamente, o que torna a web diferente de outros sistemas, mais aberta, mais centrada no usuário e diferente de outros aplicativos é a URL. Como uma URL geralmente aponta para um único recurso, pesquisadores e ativistas podem estudar e tirar conclusões sobre essas URLs com antecedência. Outros usuários podem usar essas informações para tomar decisões sobre se desejam fazer o download do que o URL aponta e como fazer isso. Mais importante, os especialistas podem baixar tracker.com/code.js , decidir que ele viola a privacidade e compartilhar essas informações com outras pessoas para que saibam que não devem baixar este código no futuro.
Existem exceções a esta regra e não existem tais requisitos na plataforma da web - no entanto, espera-se que os URLs permaneçam essencialmente inalterados. Essas expectativas estão espalhadas por toda a plataforma da web - em termos de políticas de cache, em instruções de biblioteca para implantação de código e assim por diante.
Pacotes da web tornam os URLs sem sentido
O Google recentemente propôs três padrões interconectados - Web Bundles, Signed HTTP Exchanges (às vezes abreviado para SXG) e Carregando. Basicamente, neste artigo, por Web Bundles, queremos dizer todos os três. Até agora, os Web Bundles têm sido promovidos como padrões a serem usados em sistemas de anúncios (TURTLEDOVE, SPARROW) e como parte do futuro sistema de AMP do Google - embora isso pareça ser apenas a ponta do iceberg.
Em um alto nível, Web Bundles são uma maneira de agrupar ativos. Em vez de baixar as páginas, imagens e arquivos JavaScript separadamente, seu navegador baixa todo o “pacote”, um arquivo que inclui todas as informações para carregar a página. Os URLs deixam de ser links globais comuns para recursos de rede e se tornam índices arbitrários dentro de pacotes.
Em outras palavras, Web Bundles transformam sites em PDFs (ou arquivos Flash SWF). PDF inclui todas as imagens, vídeos e scripts necessários para processar o PDF - você não os baixa individualmente. Isso tem suas vantagens de conveniência, mas torna impossível examinar partes individuais do PDF independentemente do arquivo inteiro. Portanto, não existem ferramentas de bloqueio de conteúdo para PDF. PDF é uma oferta tudo ou nada, e Web Bundles transformarão sites em ofertas como esta.
Ao alterar URLs de identificadores globais significativos para índices arbitrários de pacotes específicos, os Web Bundles oferecem aos anunciantes e rastreadores novas maneiras poderosas de contornar as ferramentas de privacidade e segurança. A seção a seguir fornece exemplos selecionados para ilustrar esse ponto.
Web Bundles permitirão que sites contornem ferramentas de privacidade e segurança
URLs em Web Bundles são links arbitrários para recursos dentro de um pacote, não links para recursos acessíveis globalmente. Isso oferece aos sites várias maneiras de contornar as ferramentas de privacidade e segurança.
Eles podem, é claro, referir-se a recursos fora do pacote, mas esse comportamento tornaria o sistema de pacotes sem sentido, portanto, esse problema não é discutido neste artigo.
A principal solução alternativa decorre do fato de que Web Bundles criam um namespace local para recursos, independente do que o resto do mundo vê, o que pode levar a todos os tipos de confusão com nomes, o que nega os anos de trabalho para melhorar a privacidade e a segurança que os ativistas vêm fazendo. privacidade e pesquisadores. A seguir, uma descrição de apenas três maneiras pelas quais os sites habilitados para Web Bundles tiram proveito dessa confusão.
Contornando as ferramentas de segurança por meio da randomização de URL
Anteriormente, se um site quisesse usar um script para rastrear as ações do usuário, ele incluiria uma tag <script> na página HTML que aponta para o mesmo script com um URL inalterado. Pesquisadores ou grupos de usuários podem ter adicionado este URL a uma lista EasyPrivacy para que questões de privacidade possam visitar o site sem baixar o script de rastreamento. É assim que a maioria das ferramentas de bloqueio funciona hoje.
Os Web Bundles tornam mais fácil para os sites contornar essas ferramentas, randomizando a URL de recursos indesejados. O que na web de hoje tem um nome global, digamos example.org/tracker.js, em um Web Bundles você pode nomear 1.js, em outro 2.js, no terceiro 3.js e assim por diante. Os pacotes da Web incentivam essa prática, tornando-a gratuita para sites. O armazenamento em cache torna-se sem sentido (uma vez que você fornece a cada usuário todos os recursos e armazena em cache o pacote inteiro), e você não precisa manter a marcação de URL (uma vez que o pacote enviado ao usuário já contém os URLs aleatórios).
Ignorando ferramentas de privacidade por meio da reutilização de URL
Para piorar as coisas, os Web Bundles permitirão que os sites contornem as ferramentas de bloqueio, fazendo com que os mesmos URLs apontem para recursos diferentes em cada pacote. Na web atual, digamos que example.org/ad.jpg aponta para a mesma coisa para qualquer usuário. É difícil para um site fazer com que o mesmo URL retorne duas imagens diferentes. Como resultado, as ferramentas de bloqueio podem bloquear ad.jpg sabendo que estão bloqueando anúncios para todos. Praticamente não há risco de que para alguns seja um anúncio e, para outros, um logotipo da empresa (isso não é impossível, mas difícil - a questão é que os Web Bundles transformam os métodos de contornar, que hoje são complexos e frágeis, em simples e gratuitos).
Os Web Bundles modificam este sistema de maneira perigosa. Example.org pode fazer seus pacotes de forma que em um delesexample.org/ad.jpg apontará para um anúncio, em outro - para o logotipo do site, em um terceiro - para outra coisa. Isso não apenas tornará muito mais difícil para os pesquisadores compilar listas, ou até mesmo impossível, como também dará aos sites novas maneiras de envenenar listas de bloqueio.
Contornando as ferramentas de privacidade, ocultando URLs perigosos
Por fim, os pacotes da Web oferecem soluções alternativas ainda mais perigosas. Hoje, grupos como uBlock Origin e Google's Safe Browsing listam URLs que incluem recursos da web maliciosos e perigosos. Esses projetos consideram a URL como o único, ou pelo menos o mais importante, identificador de um recurso perigoso. A natureza universal e global da URL torna essas listas úteis.
Os Web Bundles mais uma vez permitem que os sites contornem essa proteção, permitindo que eles se vinculem a recursos prejudiciais conhecidos por meio de URLs verificados. Na web, é muito difícil fazer com que os sites tratem cdn.example.org/cryptominer.js como se fossem cdn.example.org/jquery.js (e vice-versa). Em Web Bundles, essa será uma tarefa trivial.
Web Bundles ,
Os desenvolvedores e apoiadores das especificações dos Web Bundles argumentam que não há nada de novo aqui e que todos os métodos acima para contornar a proteção já existem. Tecnicamente, isso é verdade, mas, em essência, tal declaração ignora a economia do processo e, portanto, não descreve a situação como um todo. Os pacotes da Web tornam essas tecnologias caras, não confiáveis e complexas baratas ou até gratuitas.
Por exemplo, os sites podem fazer com que vários URLs apontem para o mesmo arquivo para dificultar a vida dos bloqueadores de anúncios, mas na prática é difícil para os sites fazerem isso. A randomização de URL prejudica o cache, exige o armazenamento de mapeamento aleatório de URL para os recursos corretos e a passagem dessas informações para o CDN e assim por diante. Os sites podem fazer isso, mas é caro e difícil, por isso raramente é feito.
De forma semelhante, os sites hoje podem usar cookies ou outros mecanismos de rastreamento de usuário para fazer a mesma URL funcionar de maneira diferente para diferentes usuários, executando os vários ataques de ofuscação de URL descritos acima. No entanto, este método não é confiável (o que fazer com novos visitantes?), Complexo (você precisa manter e distribuir a exibição de cookies e valores de recursos) e caro (a maioria dos servidores da web e serviços de hospedagem dependem de armazenamento em cache, então tais tecnologias para sites que não pertencem a grandes corporações são praticamente não disponível).
Em geral, os pacotes da Web tornam o comportamento indesejado muito mais fácil, tornando-o mais barato.
Outros problemas
Este artigo descreve os danos que os Web Bundles podem causar às ferramentas de privacidade e segurança. Mas existem outros problemas com este e outros padrões relacionados. Em particular, são eles:
- SXG não possui sistema de kickback. Se um recurso malicioso aparecer acidentalmente no site hoje, o site pode simplesmente ser atualizado. Se um site assina Web Bundles usando SXG, não há uma maneira clara de o signatário dizer a todos que "não confiem mais neste pacote específico".
- Interoperabilidade com o Manifest v3: o Manifest v3 restringe as extensões para usar padrões de URL para bloqueio. Os pacotes da Web tornam esses URLs sem sentido. Combinar essas duas coisas permitirá que os sites ignorem completamente o bloqueio.
- Confusão com fontes. O Loading + SXG permite que você baixe o conteúdo de um servidor e execute-o com as configurações de privacidade e segurança de outro servidor. O potencial de confusão do usuário é enorme - e embora tenhamos certeza de que os funcionários do Google estão trabalhando ativamente para resolver esse problema, o risco para os usuários continua muito alto.
Conclusão
A Brave está trabalhando para melhorar a privacidade na web, tanto em nosso navegador quanto nas ferramentas que criamos e distribuímos, e na defesa que fazemos para organizações de padronização. Este artigo é apenas um exemplo de nosso trabalho para garantir que os padrões da web continuem a se concentrar na privacidade, transparência e responsabilidade.
Tentamos por muito tempo, mas sem sucesso, prestar atençãoautores do padrão Web Bundles nos problemas listados. Instamos o Google e os Web Bundles a suspenderem esta proposta até que os problemas de privacidade e segurança descritos neste artigo sejam resolvidos. Também encorajamos os membros das comunidades de privacidade e segurança da web a participarem desta discussão e não implementarem este padrão até que os problemas descritos sejam resolvidos.
Uma maneira de fazer isso é descrever esses problemas nos comentários sobre a postagem que o autor deste artigo fez sobre o projeto Web Bundles. Outras opções são fazer novas notas de especificações, dizer aos desenvolvedores do navegador como as ferramentas de proteção de privacidade são importantes para você, e quais são os riscos que esses novos padrões representam para essas ferramentas.