O First-Party Sets (FPS) foi criado 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 FPS, primeiro no Grupo da comunidade de privacidade do W3C e agora no Grupo da comunidade do Incubador 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, continuando a oferecer suporte ao 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 (APIs Topics, Protected Audience e Attribution), a equipe do Chrome buscou entender o escopo dos cenários em que os cookies de terceiros foram usados, além de fins de personalização ou medição de anúncios, para oferecer experiências de navegação aprimoradas aos usuários.
Descobrimos que as organizações podem depender 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. Para casos como esses, criamos uma solução alinhada às necessidades dessas organizações, preservando as expectativas dos usuários em relação à privacidade na Web.
Onde começamos
Como o navegador atualmente usa o limite no nível do site para interpretar "primário" em vez de "terceiro", para considerar o intervalo de domínios que uma organização pode gerenciar, parecia apropriado substituir esse limite técnico por uma definição mais sutil.
Em 2021, o Chrome propôs inicialmente o atributo de cookie SameParty para
conjuntos primários, para que os sites pudessem definir cookies originados de sites
no "mesmo site". Usamos uma
política de user agent
para definir o que constituiria uma "mesma parte". Essa definição de política tentou
se basear em estruturas existentes de "parte" (por exemplo, da especificação
DNT do W3C) e
incorporou recomendações de discurso de privacidade relevante (como o relatório
da Comissão Federal de Comércio de 2012 intitulado
"Proteger a privacidade do consumidor em uma era de mudanças rápidas").
Na época, achamos que essa abordagem oferecia flexibilidade suficiente para diferentes tipos de organizações em vários setores, além de aderir à nossa meta de minimizar o rastreamento generalizado por cookies de terceiros.
Feedback sobre a proposta inicial
Em muitas conversas com as partes interessadas no ecossistema da Web, descobrimos que havia limitações nesse design inicial.
Desafios de privacidade com acesso passivo a cookies pelo atributo SameParty
Outros fornecedores de navegadores preferiram uma abordagem ativa para o acesso de cookies de terceiros que exige uma invocação de API explícita, em vez de estabelecer um limite em que o acesso de cookies passivo pudesse ser mantido. As solicitações ativas de acesso a cookies oferecem visibilidade e controle do navegador para que o risco de rastreamento secreto por cookies de terceiros possa ser mitigado. Além disso, essa visibilidade permitiria que os navegadores oferecessem aos usuários a opção de permitir ou bloquear esse acesso.
Para buscar a interoperabilidade da Web em todos os navegadores e melhorar os benefícios de privacidade, decidimos seguir nessa 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".
No ecossistema mais amplo, descobrimos que o feedback recebido sobre a política segue 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 às empresas maiores uma maior capacidade de agrupar dados em uma ampla gama de domínios e serviços voltados ao 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 governar um limite tenha sido criada para oferecer flexibilidade a diferentes tipos de domínios que precisariam estar no FPS de uma organização, descobrimos que alguns casos de uso importantes não atendiam a esse design de política. 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 pelo usuário. Portanto, os requisitos de "identidade de grupo comum" ou "política de privacidade comum" com outros domínios no mesmo FPS não puderam ser atendidos.
A percepção e o entendimento dos usuários sobre a identidade do grupo podem ser diferentes
Originalmente, propusemos limites para definir uma "identidade de grupo comum" como uma tentativa de definir o escopo de domínios em um único conjunto para aqueles que podem 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 "facilmente descoberta pelos usuários". Isso deixou espaço para abuso e dúvidas sobre a aplicação.
Também recebemos feedback de que entender o significado dos limites de "propriedade comum" pode variar de usuário para usuário, o que dificulta a criação de diretrizes que podem ser aplicadas a todos os sites.
Uma política subjetiva é difícil de aplicar em grande escala
Recebemos muitos pedidos de diretrizes mais detalhadas, devido à natureza subjetiva de alguns requisitos (como "identidade de grupo comum") e à necessidade de cobrir exceções ou casos extremos para outros (em relação à "política de privacidade comum").
Para garantir que a política fosse aplicada de maneira justa e consistente, o Chrome teria que fornecer aos autores de sites diretrizes muito mais específicas. Determinamos que tentar criar diretrizes mais rígidas poderia prejudicar o ecossistema.
Embora tenhamos proposto inicialmente que uma entidade independente de aplicação da lei assumisse a função de investigar e fazer cumprir a política, no atual ecossistema, encontrar uma entidade independente de aplicação da lei com a experiência adequada para realizar essas responsabilidades de maneira imparcial era difícil. Em vez disso, nos esforçamos para mudar para uma política que pudesse ser aplicada tecnicamente para garantir que a implementação pudesse ser aplicada de forma consistente e objetiva.
A evolução
Em resposta ao feedback, reformulamos o FPS. Voltamos aos problemas específicos que estávamos tentando resolver e decidimos definir mais diretamente a proposta em torno de casos de uso específicos.
Soluções para casos de uso importantes
O Chrome desenvolveu três "subconjuntos" diferentes criados para atender aos principais casos de uso na Web. A abordagem de subconjuntos melhorou a abordagem antiga por ser mais privada, mais específica e mais fácil de aplicar de forma consistente.
- "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, e esses sites ainda podem requerer 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, e esses sites podem exigir acesso à identidade de um usuário para executar as funções.
- 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álises 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 login de um usuário em um site relacionado que usa a mesma infraestrutura de login.
Para cada um desses casos de uso, há requisitos de política discretos, verificações de validação técnica correspondentes e comportamento específico de processamento do navegador. Saiba mais nas diretrizes de envio. Essas mudanças abordam as limitações da proposta original, abandonando um design "tamanho único" e favorecendo um modelo compartimentado e orientado a casos de uso.
Oportunidade de interoperabilidade com solicitações ativas de acesso a cookies de terceiros
O Chrome quer promover a interoperabilidade com outros navegadores para manter a saúde da plataforma da Web. Como outros navegadores, como Safari, Firefox e Edge, atualmente usam a API Storage Access (SAA) para facilitar as solicitações de cookies ativas, optamos por usar a SAA no Chrome não apenas para ajudar a resolver os principais feedbacks que recebemos, mas também para oferecer suporte à interoperabilidade da Web.
Para oferecer mais flexibilidade aos desenvolvedores e resolver limitações conhecidas do SAA,
também propusemos a API requestStorageAccessForOrigin.
Oportunidade de usar a API Storage Access e o FPS juntos
Ao implementar a API Storage Access (SAA), os navegadores podem pedir permissão diretamente aos usuários, e outros podem permitir um número limitado de solicitações sem uma solicitação de permissão.
O Chrome acredita que o FPS pode oferecer uma camada transparente sobre a SAA, limitando a fricção do usuário e evitando a fadiga do prompt para casos de uso importantes e limitados. O FPS também oferece aos navegadores a flexibilidade de fornecer aos usuários mais contexto sobre a associação definida, caso eles solicitem permissão.
Com o FPS, os desenvolvedores têm a oportunidade de identificar os próprios sites afetados que atendem aos principais casos de uso. Isso permite que os desenvolvedores da agência antecipem como os sites vão funcionar para os usuários e tomem medidas para limitar o impacto na experiência do usuário, usando FPS ou uma alternativa de cookie de terceiros. Além disso, o FPS oferece previsibilidade da plataforma aos desenvolvedores, ao contrário das heurísticas, que podem mudar com o tempo ou resultar em comportamentos variados para usuários diferentes.
Por fim, os desenvolvedores que implementarem o SAA para trabalhar com FPS no Chrome também poderão aproveitar o SAA para a performance dos sites em outros navegadores, mesmo aqueles que não enviam FPS.
Discussão contínua
Acreditamos que nossa proposta mais recente atinge o equilíbrio certo em um espaço de competição desafiador que considera as necessidades dos usuários e dos desenvolvedores. Agradecemos o feedback das partes interessadas do ecossistema da Web que nos ajudaram a desenvolver a proposta de QPS.
Sabemos que as partes interessadas do ecossistema da Web ainda estão se familiarizando com a proposta atualizada. Entre em contato com a gente para que possamos continuar melhorando o design de uma forma mais útil para os desenvolvedores e melhorar a privacidade na Web. O Google também vai 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 interagir, confira estes recursos:
- Incubação no WICG
- Instruções para o teste de QPS
- Conjuntos primários: guia de integração
- Diretrizes de envio de FPS
Como trabalhar com o ecossistema
É ótimo ver empresas como o Salesforce e o CafeMedia engajadas com o feedback e o desenvolvimento de conjuntos diretos. Eles foram fundamentais para o avanço da tecnologia. Várias outras pessoas 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 primários para se alinhar a muitos dos nossos casos de uso, como preservar 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, garantindo que os casos de uso genuínos sejam atendidos. É ótimo que a equipe esteja colaborando com o ecossistema de desenvolvedores e melhorando constantemente a implementação da proposta de conjuntos próprios com base no feedback das partes interessadas da Web. Estamos felizes por fazer parte da jornada de testes da proposta e ansiosos para a incorporação dela ao navegador." - Nitish Mittal, diretor de engenharia, VWO