Como o Chrome aprimorou a proposta de conjuntos primários

Diagrama de conjuntos primários

Os conjuntos primários (QPS) foram projetados para oferecer suporte à experiência de navegação na Web dos usuários após a descontinuação dos cookies de terceiros no Chrome. A proposta evoluiu significativamente em fóruns de Web aberta durante a incubação de QPS, primeiro no Grupo da comunidade de privacidade do W3C e agora no Grupo da comunidade de incubadoras da Web.

Nesta postagem do blog, vamos recapitular o processo de evolução, destacar as principais mudanças e discutir por que acreditamos que essas mudanças melhoram a privacidade na Web sem deixar de apoiar o ecossistema.

Contexto

Os sites geralmente dependem do acesso aos cookies em um contexto de terceiros para oferecer experiências perfeitas e personalizadas aos usuários. Além das APIs de anúncios que preservam a privacidade (Topics, Protected Audience e Attribution), a equipe do Chrome buscou entender o escopo dos cenários em que cookies de terceiros eram usados, além de personalização de anúncios ou medição, para fornecer experiências de navegação aprimoradas aos usuários.

Descobrimos que as organizações dependem de cookies de terceiros porque a arquitetura da Web delas foi projetada para usar vários domínios. Por exemplo, uma organização pode ter um domínio para o blog de caminhadas e outro para a loja de acampamento e quer oferecer suporte às jornadas dos usuários nesses sites. Uma organização também pode manter vários domínios de código de país com infraestrutura compartilhada para o serviço da Web. Em casos como esses, decidimos criar uma solução alinhada às necessidades dessas organizações, preservando as expectativas dos usuários com relação à privacidade na Web.

Onde começamos

Como o navegador atualmente usa o limite no nível do site para interpretar "próprios" e "de terceiros", considerando o intervalo de domínios que uma organização pode gerenciar, parece apropriado substituir esse limite técnico por uma definição mais detalhada.

Diagrama de um site com um iframe incorporado

Em 2021, o Chrome propôs inicialmente o atributo de cookie SameParty para conjuntos primários de modo que os sites pudessem definir cookies provenientes de sites da "mesma parte". Usamos uma política de user agent para definir o que constituiria uma "mesma parte". Essa definição de política tentou aproveitar estruturas existentes de "parte" (por exemplo, da especificação DNT do W3C) e recomendações incorporadas de discursos de privacidade relevantes (como o relatório da Comissão Federal de Comércio dos EUA de 2012 intitulado "Como proteger a privacidade do consumidor em uma era de mudança rápida").

Na época, percebemos que essa abordagem fornecia flexibilidade suficiente para diferentes tipos de organizações em todos os setores, além de aderir ao nosso objetivo fundamental de minimizar o rastreamento generalizado com cookies de terceiros.

Feedback sobre a proposta inicial

Em muitas conversas com as partes interessadas no ecossistema da Web, descobrimos que havia limitações com esse design inicial.

Outros fornecedores de navegadores preferem uma abordagem ativa para o acesso a cookies de terceiros que exigem uma invocação explícita da API, em vez de estabelecer um limite dentro do qual o acesso a cookies passivos pode ser mantido. As solicitações ativas de acesso a cookies fornecem visibilidade e controle do navegador para diminuir o risco de rastreamento oculto com cookies de terceiros. Além disso, essa visibilidade permitiria que os navegadores fornecessem aos usuários a opção de permitir ou bloquear o acesso a cookies.

Para buscar a interoperabilidade da Web em todos os navegadores, bem como melhorar os benefícios da privacidade, decidimos seguir essa direção.

Desafios de implementação com a política proposta

A política original propôs três requisitos para que os domínios estivessem em um único conjunto: "propriedade comum", "política de privacidade comum" e "identidade de grupo comum".

Do ecossistema como um todo, encontramos o feedback que recebemos sobre a política seguindo quatro temas principais.

A propriedade comum é muito restritiva

Em relação ao requisito de "propriedade comum", recebemos feedback de que uma definição de FPS focada apenas na propriedade corporativa daria a empresas maiores uma capacidade maior de agrupar dados em uma ampla variedade de domínios e serviços voltados para o usuário, em comparação com empresas menores. Como nosso objetivo é criar o Sandbox de privacidade para o ecossistema como um todo, levamos esse feedback a sério e priorizamos uma solução mais inclusiva.

Uma única política limita a extensibilidade aos casos de uso

Embora a ideia de uma política holística para controlar um limite visa fornecer flexibilidade a diferentes tipos de domínios que precisam estar no QPS de uma organização, descobrimos que alguns casos de uso críticos não atendem a esse design de políticas. Por exemplo, domínios de serviço (como aqueles que hospedam conteúdo gerado pelo usuário) podem exigir acesso aos cookies em um contexto de terceiros para autenticar ou identificar usuários. Esses domínios raramente têm uma página inicial acessível ao usuário, então não foi possível atender aos requisitos de "identidade de grupo comum" ou "política de privacidade comum" com outros domínios no mesmo QPS.

A percepção e compreensão dos usuários sobre a identidade do grupo podem ser diferentes

Originalmente, propusemos proteções para definir uma "identidade de grupo comum" como uma tentativa de definir o escopo de domínios em um único conjunto àqueles que poderiam ser facilmente associados a uma identidade de grupo comum. No entanto, não foi possível definir um meio técnico para medir e avaliar se a identidade do grupo comum poderia ser "identificada com facilidade pelos usuários". Isso deixava potencial para abuso e perguntas sobre a aplicação da política.

Também recebemos feedback de que a compreensão do significado de limites de "propriedade comum" pode variar de acordo com o usuário, o que dificulta a criação de diretrizes que podem ser aplicadas a todos os sites.

É difícil aplicar uma política subjetiva em grande escala

Recebemos várias solicitações de diretrizes mais detalhadas devido à natureza subjetiva de determinados requisitos (como "identidade de grupo comum") e à necessidade de cobrir exceções ou casos extremos para outros (referentes à "Política de Privacidade comum").

Para garantir que a política fosse aplicada de maneira equitativa e consistente, o Chrome precisaria fornecer diretrizes muito mais específicas aos autores de sites. Determinamos que a tentativa de criar diretrizes mais rígidas poderia ser exclusiva para prejudicar o ecossistema.

Embora tínhamos inicialmente proposto que uma entidade de aplicação independente assumisse o papel de investigar e aplicar a política, no ecossistema atual, encontrar uma entidade de aplicação independente com a experiência apropriada para desempenhar essas responsabilidades de maneira imparcial era um desafio. Em vez disso, nos esforçamos para mudar para uma política que pudesse ser tecnicamente aplicada para garantir que a implementação pudesse ser aplicada de maneira consistente e objetiva.

A evolução

Em resposta ao feedback, reformulamos o QPS. Voltamos aos problemas específicos que estávamos tentando resolver e decidimos enquadrar a proposta mais diretamente em casos de uso específicos que estávamos resolvendo.

Soluções para os principais casos de uso

O Chrome desenvolveu três "subconjuntos" diferentes para atender aos principais casos de uso na Web. A abordagem de subconjuntos melhorou a abordagem antiga, sendo mais privada, mais específica e mais fácil de aplicar de maneira consistente.

Diagrama de subconjuntos de conjuntos primários.
  • "ccTLDs" (domínios de nível superior com código de país): as organizações podem manter sites com diferentes ccTLDs para experiências localizadas. Esses sites ainda podem exigir acesso a serviços e infraestrutura compartilhados.
  • Domínios de "serviço": os sites podem usar domínios distintos para fins de segurança ou desempenho. Esses sites podem exigir acesso à identidade de um usuário para realizar o próprio trabalho.
  • Domínios "associados": as organizações podem manter vários sites para marcas ou produtos diferentes e relacionados. Eles podem querer acesso a cookies entre sites para casos de uso, como análise de jornadas do usuário em sites relacionados, para entender melhor como a base de usuários de uma organização interage com os sites ou para lembrar o estado de um usuário conectado em um site relacionado que depende da mesma infraestrutura de login.

Para cada um desses casos de uso, há requisitos de política distintos, verificações de validação técnica correspondentes e comportamentos específicos de processamento do navegador. Saiba mais nas Diretrizes de envio. Essas mudanças abordam as limitações da proposta original, abandonando um design de "tamanho único" e favorecendo uma estrutura compartimentada e orientada por casos de uso.

O Chrome quer promover a interoperabilidade com outros navegadores para manter a integridade da plataforma da Web. Como outros navegadores, como Safari, Firefox e Edge, atualmente usam a API Storage Access (SAA) para facilitar as solicitações ativas de cookies, optamos por usar a SAA no Chrome não apenas para ajudar a lidar com os principais feedbacks que recebemos, mas também para dar suporte à interoperabilidade da Web.

Para oferecer mais flexibilidade aos desenvolvedores e solucionar as limitações conhecidas da SAA, também sugerimos a API requestStorageAccessForOrigin.

Oportunidade de usar a API Storage Access e o QPS juntos

Ao implementar a API Storage Access (SAA), os navegadores podem optar por solicitar permissão aos usuários diretamente, e outros podem optar por permitir um número limitado de solicitações sem um prompt de permissão.

O Chrome acredita que o FPS pode fornecer uma camada transparente sobre o SAA, limitando o atrito do usuário e evitando a fadiga da solicitação em casos de uso importantes e limitados. O QPS também oferece aos navegadores a flexibilidade de fornecer aos usuários mais contexto sobre a assinatura definida, caso eles solicitem permissão.

Com o QPS, os desenvolvedores podem identificar os próprios sites afetados que atendem aos principais casos de uso. Isso permite que os desenvolvedores prevejam o funcionamento dos sites para os usuários e tomem medidas para limitar o impacto na experiência do usuário, aproveitando QPS ou uma alternativa de cookie de terceiros. Além disso, os QPS oferecem previsibilidade da plataforma aos desenvolvedores, em vez da heurística, que pode mudar com o tempo ou resultar em comportamentos variados para usuários diferentes.

Por fim, os desenvolvedores que implementam SAA para trabalhar com QPS no Chrome também podem usá-los para o desempenho dos sites em outros navegadores, mesmo aqueles que não enviam QPS.

Discussão contínua

Acreditamos que nossa proposta mais recente atinge o equilíbrio certo em um espaço desafiador que considera as necessidades de usuários e desenvolvedores. Agradecemos o feedback das partes interessadas do ecossistema da Web que nos ajudaram a aprimorar a proposta de QPS.

Reconhecemos que as partes interessadas do ecossistema da Web ainda estão se familiarizando com a proposta atualizada. Entre em contato conosco para que possamos continuar a melhorar o design de uma maneira que seja mais útil para os desenvolvedores e continue a melhorar a privacidade na Web. O Google também continuará trabalhando com a Autoridade de Concorrência e Mercados (CMA, na sigla em inglês) do Reino Unido para garantir a conformidade com os Compromissos.

Para isso, confira os recursos a seguir:

Como trabalhar com o ecossistema

É ótimo ver empresas como a Salesforce e a CafeMedia participando de feedbacks importantes e do desenvolvimento de conjuntos primários. Elas têm sido fundamentais para o avanço da tecnologia. Vários outros também compartilharam suas opiniões sobre os conjuntos primários e os esforços do Chrome para trabalhar com o ecossistema da Web:

"O Chrome está desenvolvendo conjuntos próprios para se alinhar a muitos dos nossos casos de uso, por exemplo, preservando as jornadas do usuário. Isso demonstra que a equipe do Google está trabalhando para entender os diferentes tipos de necessidades dos proprietários de sites na Web." - Mercado Livre

"Na VWO, agradecemos os esforços do Google para elevar os padrões de privacidade e garantir que casos de uso genuínos sejam tratados. É ótimo que a equipe esteja colaborando com o ecossistema de desenvolvedores e melhore constantemente a implementação da proposta de conjuntos primários com base no feedback das partes interessadas na Web. Estamos felizes em fazer parte da jornada de teste da proposta e ansiosos para que ela seja incorporada ao navegador." – Nitish Mittal, Diretor de Engenharia, VWO