Posição de padrões da Mozilla se opõe à Web Environment Integrity API

 (github.com/mozilla)
1 pontos por GN⁺ 2023-07-26 | 1 comentários | Compartilhar no WhatsApp
  • Em uma issue do Mozilla standards-positions, foi solicitada uma posição sobre a Web Environment Integrity API, e a Mozilla concluiu com position: negative, afirmando que a proposta entra em conflito com os princípios de abertura da Web
  • A proposta diz que o protótipo do Chromium atualmente depende do Google Play Integrity, mas que, na especificação, é neutra em relação a fornecedores; o solicitante manifestou preocupação de que, assim como o EME, ela possa na prática se consolidar em torno de poucos fornecedores
  • A Mozilla avaliou que essa API poderia se tornar um mecanismo para restringir a escolha de dispositivos, sistemas operacionais e navegadores, sendo prejudicial à abertura do ecossistema Web e ruim para os usuários
  • Entre os casos de uso propostos, a “detecção de tráfego não humano” poderia bloquear usos existentes da Web que transformam, verificam, indexam ou resumem conteúdo destinado a humanos, como tecnologias assistivas, testes automatizados, arquivamento e spiders de mecanismos de busca
  • A Mozilla afirmou que detectar fraude e tráfego inválido é um problema difícil e que tem interesse em resolvê-lo, mas considerou que a proposta carece de explicação sobre avanços nos casos de uso reais e tem desvantagens claras caso seja adotada

Solicitação da issue e escopo da proposta

Preocupações iniciais levantadas

  • O solicitante citou como exemplo o fato de o EME ser, em teoria, neutro em relação a fornecedores, mas, na prática, haver apenas poucos fornecedores amplamente reconhecidos
    • Google Widevine: usado no Firefox, Chrome e Android na maioria das plataformas
    • Microsoft PlayReady: usado no Microsoft Edge, no Windows e, junto com o Widevine, em alguns dispositivos Android
    • Apple FairPlay: usado no Safari e no ecossistema Apple
  • Há a preocupação de que a mesma situação possa se repetir com a Web Environment Integrity API, e que sites reais passem a exigir navegadores pré-aprovados
  • Um comentário criticou que essa API não oferece nada ao usuário final, pode ser usada apenas para restringir usuários, e que a especificação é vaga e o underlying mechanism não está claro

Motivos da oposição da Mozilla

  • A Mozilla afirmou que essa proposta contraria seus princípios e visão para a Web
  • A visão da Mozilla para a Web é que navegadores, servidores e publishers que implementam padrões comuns devem se tornar automaticamente parte da Web
  • Padrões devem evitar pressupostos sobre hardware ou software implantáveis, e nenhuma entidade específica deve decidir quais form factors, dispositivos, sistemas operacionais ou navegadores podem acessar a Web
  • Esse direito de escolha permite que pessoas diversas cheguem à mesma Web em termos de tecnologias assistivas, localização, form factors e preço
  • Portanto, mecanismos que tentam restringir escolhas são prejudiciais à abertura do ecossistema Web e ruins para os usuários

Problemas no caso de uso de “detecção de tráfego não humano”

  • A Mozilla entende que os casos de uso propostos dependem da capacidade de “detectar tráfego não humano”
  • Essa abordagem pode interferir em usos existentes da Web

    • Tecnologias assistivas

      • Testes automatizados
      • Arquivamento
      • Spiders de mecanismos de busca
      • Essas ferramentas precisam poder receber conteúdo destinado a humanos e transformá-lo, testá-lo, indexá-lo e resumi-lo novamente para humanos
      • A salvaguarda proposta, chamada “holdback”, ou a criação de falhas aleatórias na geração de attestation, é considerada pouco propensa a ser eficaz e insuficiente para resolver as preocupações levantadas pela Mozilla

Conclusão e tratamento da issue

  • A Mozilla afirmou que detectar fraude e tráfego inválido é um problema difícil e que tem interesse em resolver essa questão
  • No entanto, a proposta da Web Environment Integrity API não explica como produziria avanços substanciais nos casos de uso listados e tem desvantagens claras caso seja adotada
  • Com base nessa análise, um membro da Mozilla rotulou a posição sobre a proposta como negative
  • Como essa proposta é de um repositório pessoal no GitHub e não é trabalho em uma trilha de padronização nem de um grupo público de incubação, considerou-se que não era necessária uma dashboard entry separada
  • A issue foi marcada com o rótulo position: negative em 25 de julho de 2023 e depois fechada como concluída

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-26
Opiniões no Hacker News

  • O ataque funciona mais ou menos assim: o invasor cria um dispositivo, como um smartphone, gera um par de chaves e o armazena dentro do HSM do aparelho, normalmente chamado de trusted enclave, depois assina a chave pública com uma chave mestra.
    O dispositivo executa o software do invasor e é projetado para que, quando um software escolhido pelo usuário seja executado com privilégios elevados, o HSM fique sabendo disso de uma forma irreversível até a próxima reinicialização. O HSM assina a frase “este dispositivo está executando o software do invasor” e o conteúdo que o software do invasor quer transmitir, mas não assina se o software escolhido pelo usuário estiver em execução. Ao incluir também a chave pública assinada pela chave mestra, isso permite que um cúmplice verifique que o dispositivo não está sob controle do usuário, mas sob o controle de uma entidade que restringe a liberdade do usuário.
    Opcionalmente, essa comprovação pode passar pelo servidor do invasor e ser transformada em uma nova comprovação, após anonimização ou verificação de condições arbitrárias. No fim, um terceiro recebe por esse método a garantia de que o dispositivo está executando o software do invasor, podendo impedir o usuário de executar o software que deseja ou forçá-lo a usar o dispositivo da forma desejada pelo invasor e seus cúmplices. Esse ataque já está em execução no Android, por meio do SafetyNet e da Play Integrity API do Google, e no iOS, pela Apple; agora está sendo estendido para a web.

    • Gosto da escolha de chamar isso de ataque. Eu ainda não tinha classificado mentalmente o Google e seus amigos como “intermediários”, mas é exatamente isso que está acontecendo.
      Esta Web Integrity API é um meio de se consolidarem não como intermediários opcionais, mas como intermediários obrigatórios.
    • Seria útil apresentar o problema com esse enquadramento na imprensa, em blogs etc. O outro lado já está forçando o significado das palavras, e ver DRM ser apresentado como “a espinha dorsal da internet aberta” foi realmente nojento.
    • Nesse cenário, o invasor fabricaria meu hardware, mas isso não faz sentido. Se a situação fosse essa, ele poderia fazer qualquer coisa de qualquer maneira, e isso não parece substancialmente diferente de “o invasor possui o hardware, então literalmente tudo é possível”.
      E esse “invasor” também não ganha nada com isso. Isso não é um invasor, é o fabricante do dispositivo. É estranho porque é como explicar o processo de atestação remota chamando o TPM de invasor.
    • No fim, por causa da realidade de enviar eletricidade por fios, também há um efeito colateral impossível de corrigir: uma parte adicional capaz de modificar suficientemente o hardware ainda pode atacar o invasor e seus cúmplices.
      Por isso, sistemas assim repassam o custo para usuários comuns, enquanto só beneficiam quem tem esse tipo de capacidade.
    • Existe algum jeito de evitar esse ataque usando um smartphone? Me vem à cabeça o moribundo Ubuntu Phone.

  • Era esperado, mas não significa nada se não conseguirmos levar as pessoas para o Firefox e afastá-las dos derivados do Chromium. Há certa responsabilidade por parte de quem investiu na segurança, na proteção e, de forma mais ampla, na confiança da web.
    Ainda não vi nada sobre se o Brave vai dar suporte a isso. Mas, se entendi corretamente, usando Chromium não deve haver escolha; espero estar enganado.

    • Vendo as críticas que a Mozilla recebe por aqui, espero que pelo menos reconheçam o crédito que ela merece.
      No fim, acho que precisamos voltar permanentemente a uma tela de escolha de navegador respaldada por lei, como depois do caso do empacotamento do IE. Caso contrário, o atrito e os incentivos continuarão consolidando ainda mais um único player dominante.
    • O resultado final provavelmente será sites com DRM e sites de bancos dizendo “use o Chrome para continuar”. Os usuários continuarão migrando para o Chrome, e a Mozilla acabará sendo forçada a implementar isso também.
    • A expressão “segurança e proteção” se tornou repulsiva para muita gente, porque remete à distopia autoritária que Google e outros estão construindo.
      O mais importante são liberdade e interoperabilidade.
    • Uma opção para administradores de sistemas ou organizações de TI que atendem SMBs é pré-instalar o Firefox nas estações de trabalho. Os usuários se acostumam com esse navegador e podem passar a usá-lo também pessoalmente.
      De quebra, dá para pré-instalar o uBlock Origin também. É o que fazemos.
    • Esse movimento só vai acontecer quando as pessoas deixarem de poder fazer no navegador o que costumavam fazer. Achei que o Manifest V3 quebraria scripts de usuário e tornaria o bloqueio de anúncios inconveniente, mas isso ainda não aconteceu, então não houve motivo para sair do Chrome.
      Se isso for implementado, a identidade do usuário pode ser considerada “insuficiente” e ele pode perder acesso a determinados sites ou serviços; nesse caso, pode surgir motivação para migrar para outro navegador que não tenha esse recurso.

  • Como já disse em outros lugares, as pessoas precisam usar o Firefox. Se todo mundo parar, não haverá ninguém com voz para enfrentar as besteiras do Google. O Google é dono do Chrome e pode fazer o que quiser com ele.
    Não estou dizendo que o Firefox é perfeito ou melhor, mas que ele é necessário. Precisamos de um navegador concorrente com participação significativa e um mecanismo de renderização que não seja, em última instância, controlado pelo Google. Caso contrário, só resta parar de reclamar e deixar o Google fazer o que quiser.

    • A maior parte da receita da Mozilla não vem da colocação paga do Google como mecanismo de busca padrão? Não sei se isso mudou nos últimos anos.
      Fazendo uma busca rápida, há 5 a 10 anos mais de 50% da receita vinha do Google, mas não encontrei dados mais recentes. Se o Google é a principal fonte de receita da Mozilla, especialmente se for mais da metade, então o Google na prática controla a Mozilla pela alavanca de poder cortar sua maior fonte de receita.
      Também surge a pergunta: que empresa ou organização deveria desenvolver um navegador? Todo mundo espera que navegadores sejam gratuitos, mas desenvolvimento, operação e manutenção não são de graça. Empresas de navegadores com fins lucrativos, como a Brave, acabam tendo que monetizar o navegador, seja com o token cripto BAT ou com anúncios na nova aba.
    • Se o Firefox fosse de fato usável para mim, eu o usaria, mas não é, então não consigo.

  • A Mozilla também pode esclarecer sua posição sobre sua própria proposta IPA, que rastreia usuários por toda a internet?
    Se alguém vê um anúncio de produto em searchengine.example, depois procura esse produto em reviews.example e então compra em shop.example, o navegador da Mozilla envia todos esses eventos para um ou mais serviços de agregação, permitindo que shop.example entenda, ao menos em nível agregado, que o usuário foi exposto ao anúncio em searchengine.example e novamente exposto em reviews.example. Claro, isso parte do pressuposto de que se confia no cartel que opera os serviços de agregação.
    Antes, uma empresa de ad tech podia rastrear usuários com base no endereço IP de origem mesmo com cookies desativados, mas o IPA permite rastrear por vários endereços IP por meio de um identificador único de rastreamento, independentemente das configurações de cookies. Também foi proposta uma abordagem em que o sistema operacional forneça um identificador único de rastreamento utilizável por todos os apps e navegadores no dispositivo, permitindo distinguir vários dispositivos por trás do mesmo IP.
    https://github.com/patcg-individual-drafts/ipa/

    • Para que a publicidade funcione, atribuição é necessária. Sem atribuição independente da plataforma onde o anúncio foi comprado, essa plataforma de anúncios pode cometer fraude.
      Isso é separado do rastreamento publicitário que cria perfis de interesses do usuário ou do remarketing, em que se compra anúncios direcionados a visitantes anteriores. A maioria dos sistemas de atribuição privada é projetada para permitir que o operador da campanha conte quantas pessoas clicaram no anúncio, mas sem saber quem clicou nem o que mais fez. A proposta do Safari tinha um limite para o número de campanhas executáveis por domínio, tentando impedir que se criasse uma “campanha” separada para cada usuário e se fizesse fingerprinting de uma só vez. Não sei em que a proposta da Mozilla difere.
      Se o agente de usuário deve se preocupar com esse tipo de coisa é uma questão à parte.
      https://www.theregister.com/2023/06/29/google_trueview_skepticism/
      Em particular, o remarketing é o que cria a “sensação de estar sendo vigiado” da publicidade moderna, em que, depois de pesquisar uma coisa, 10 mil anúncios daquele item seguem você pela semana inteira.
    • Pelo texto original, parece que é possível perguntar a posição da Mozilla abrindo uma issue no GitHub em https://github.com/mozilla/standards-positions
    • Para ser justo, “Web Integrity”, ou seja, atestação remota ou um agente de vigilância corporativa dentro do “meu” hardware, é um problema muito mais fundamental. Isso porque poderia impedir a própria execução de navegadores derivados que removam vulnerabilidades de segurança intencionais como o IPA.
      É lamentável que a Mozilla acompanhe lixo como o IPA, mas pelo menos hoje o usuário ainda tem a liberdade de desativar, remover, fazer um fork etc. Já a atestação remota é, na prática, fim de jogo para o próprio conceito de agente do usuário.
    • Por pior que seja a proposta da Mozilla, isso é desviar o foco. No fim, serve aos interesses do Google e acaba defendendo uma proposta muito mais distópica.
    • “O navegador da Mozilla envia todos esses eventos para um ou mais serviços de agregação” é algo que acontece quando o usuário permite.

  • Detecção de navegador, detecção de “ambiente”
    Operadores de certos sites poderiam, como forma de protesto, criar sites inacessíveis no Chrome. Seria interessante ver o Google tentando contornar isso. Especialmente se virasse moda apenas entre sites pequenos e não comerciais.

    • Boa ideia. Isso poderia ajudar treinando usuários a usar vários navegadores com frequência. Meus filhos já usam vários navegadores em dispositivos Android para bloquear anúncios no YouTube. Quando há motivo suficiente, as pessoas estão dispostas a usar outros navegadores.
      Mas, em vez de bloquear completamente, eu deixaria apenas as funcionalidades estritamente necessárias e ficaria lembrando o usuário de trocar de navegador ou usar algo como Tampermonkey. Também seria preciso fornecer instruções claras sobre o que fazer.
      Qual seria uma boa forma de detectar suporte a esse recurso? Uma API JavaScript?
    • Durante longos 6 anos, o Chrome não conseguiu acessar meu site. Todos os outros navegadores conseguiam, mas o Chrome não respeitava uma configuração no lado do servidor que forçava a negociação apenas de um modo que não fosse HTTP/3 e permitia somente ChaCha/Poly, excluindo AES/RSA. O Microsoft Edge corrigiu isso algum tempo depois.
      Felizmente, o Google também corrigiu há cerca de 4 meses. Em várias ferramentas gratuitas de teste cross-browser, ainda dá para demonstrar essa quebra com testes de versão.
    • Pode servir de referência: https://news.ycombinator.com/item?id=25240299

  • O equivalente no lado mobile, a Play Integrity API, deveria ser tornado ilegal e contestado nos tribunais. Como a ideia central é eliminar ROMs de terceiros, acho que provavelmente também entra em conflito com o direito ao reparo e as leis de lixo eletrônico da UE.
    Precisamos começar a redirecionar o foco do debate para os problemas de segurança criados pelo Google e por sua publicidade.

    • O Google está abusando da computação confiável. Dá para entender que alguns bancos prefiram que o código de processamento de pagamentos rode em dispositivos bloqueados, mas hoje esses dispositivos Android contêm adware e spyware do Google que não são necessários de forma alguma para um dispositivo confiável de pagamentos.
      O Google deve ser desmembrado para que seus interesses não contaminem o Android e o Chrome.

  • Quero doar para a Mozilla, mas fico preocupado que meu dinheiro acabe no bolso de executivos de nível C. Existe alguma forma de doar especificamente para a equipe principal do Firefox ou para a MDN?

    • Restringir dessa forma não faz sentido do ponto de vista da Mozilla. Mesmo que haja doações para o Firefox, se não for possível pagar a equipe de limpeza do escritório, aluguel, RH, contabilidade e jurídico, não dá para contratar e manter a “equipe principal do Firefox e a MDN”
      Até um CEO absurdamente bem pago é necessário para uma empresa. Não acredito no argumento de que, nos EUA, é preciso pagar muito para trazer um bom CEO, mas um CEO ruim pode destruir uma empresa, como GE, Enron, Boeing e Twitter
      Um exemplo divertido de como restrições de uso do orçamento dão errado é a MARTA, de Atlanta. Antigamente, por causa de uma lei de financiamento, os custos operacionais e os gastos de capital eram fixados em 50/50; o resultado foi que havia trens novos, enquanto todo o resto estava desmoronando
    • Você faz a mesma análise para todas as compras? A lanchonete onde você comprou o sanduíche do almoço pode ter usado esse dinheiro para comprar pizza para o dono e a esposa dele, que nem trabalharam naquele dia. Isso te deixaria irritado?
      Um negócio funciona assim: dinheiro entra, dinheiro sai e produtos são feitos. Você escolhe pagar ou não por um produto de que gosta. Como eles usam o dinheiro que recebem é decisão deles
    • É possível fazer uma doação restrita para a Mozilla Foundation e, se eles aceitarem, ficam vinculados a essa restrição, a menos que o doador concorde em alterá-la
      Mas dinheiro é fungível. Se você doar 500 dólares para apoiar a MDN, isso pode substituir 500 dólares que originalmente iriam para a MDN a partir da receita existente, permitindo que outros 500 dólares acabem no bolso de executivos de nível C, no Pocket etc. Os dólares em si vão para o destino indicado, mas podem viabilizar outros gastos de que você não gosta
      Por outro lado, se você doar 50 bilhões de dólares para apoiar a MDN, aí é um pouco diferente. O orçamento existente de apoio à MDN certamente seria liberado, mas os gastos da MDN obviamente não seriam de 50 bilhões de dólares, então o dinheiro que excedesse as necessidades da MDN não teria para onde ir
    • A Mozilla não é uma cooperativa, é apenas uma entidade sem fins lucrativos. Os desenvolvedores também são funcionários dessa entidade, como em qualquer outra empresa. Francamente, acho que a empresa tem uma receita considerável e não depende tanto de doações
      Usar os produtos e se tornar cliente provavelmente é mais valioso para eles e para o manifesto deles
    • No momento, o caminho mais próximo é pagar por um dos produtos. Há Pocket Premium, Firefox Relay e Mozilla VPN

  • A Mozilla pode ser contra, mas, se isso for incluído no Chrome e começar a ser usado ativamente, no fim eles vão implementar, como fizeram com CDM
    No fim, os usuários só verão que determinado site funciona no Chrome e não no Firefox. Quando houver um custo real na forma de possível perda de participação de mercado, o Firefox vai concluir que não há motivo para continuar contra

    • Basta lembrar como a estratégia de “não é Chrome, mas é quase Chrome” funcionou em termos de participação. Usuários assim não veem problema em simplesmente usar o Chrome, então esse mercado talvez nem seja tão grande assim

  • A posição de padrões do WebKit também vale uma olhada: https://webkit.org/standards-positions/
    Este caso ainda não foi refletido lá e provavelmente será rejeitado

  • Há uma longa história de hackers, no sentido clássico, usando computadores para fazer coisas que outras pessoas não queriam, enquanto essas outras pessoas não conseguiam fazer nada ou, no máximo, entravam em uma corrida armamentista. Foi ruim para elas, mas muito bom para a sociedade como um todo
    Isso deu origem a inúmeras coisas, como GNU, “IBM Compatible”, bloqueadores de anúncios, Firefox, BitTorrent, YouTube ReVanced/youtube-dl etc.
    O objetivo da atestação de dispositivo para software de consumo é acabar com isso. A Apple foi pioneira nisso no iOS, e agora, pela força do capitalismo, está se espalhando para toda a computação. Atestação de dispositivo significa que os hackers perdem, e esse é um final ruim
    Outra ameaça gêmea é que a indústria de software está finalmente colocando a segurança em ordem. Antigamente, jailbreaks de iOS eram comuns, mas passamos um ano sem um jailbreak de iOS. Rust também não ajuda
    Estamos correndo para um mundo em que produtores e detentores de propriedade intelectual controlam totalmente o conteúdo que criaram e mantêm esse estado por meio de criptografia de ponta e software extremamente seguro, porém hostil ao consumidor. Esta é uma das evoluções mais perigosas da história e, se se tornar realidade, não haverá como voltar atrás. Stallman estava certo

    • Bem resumido. Na prática, todo esse lixo de atestação, na minha opinião, é DRM. Claro, está sendo vendido como um recurso opcional que “pode melhorar a experiência”
      É parecido com dizer que entregar a carteira sob a mira de uma arma pode melhorar sua felicidade