Muitas APIs do Sandbox de privacidade estão chegando à disponibilidade geral (GA) no Chrome Stable para preparar a descontinuação dos cookies de terceiros a partir de 2024. Algumas dessas APIs vão ajudar a preservar casos de uso cruciais de cookies entre sites, como os CHIPS, e a API atualmente conhecida como Conjuntos primários (QPS). Nesta postagem, apresentamos os conjuntos de sites relacionados (RWS, na sigla em inglês), nosso novo nome para QPS que reflete melhor a finalidade dele, além de relembrar os principais casos de uso e atualizar o limite de domínio do subconjunto associado.
Preservando jornadas ideais do usuário
O RWS foi projetado para minimizar interrupções em recursos específicos voltados ao usuário quando o Chrome começar a limitar o acesso a cookies de terceiros por padrão. Nosso objetivo é permitir que os usuários naveguem na Web com o mínimo de interrupções e, ao mesmo tempo, manter os objetivos de privacidade do Sandbox de privacidade. Para atingir esse equilíbrio, o RWS segmenta casos de uso específicos relacionados à funcionalidade do site:
- O caso de uso do ccTLD trata de falhas como o exemplo de login registrado no nosso rastreador público. Esses casos geralmente são abordados no ecossistema com exceções baseadas em heurística (Consulte a ref 1).
- O caso de uso do domínio de serviço aborda uma prática comum de desenvolvedor para isolar funções sensíveis (como oferecer suporte a um fluxo de autenticação) dos domínios voltados ao usuário. Esses casos podem ser abordados no ecossistema com exceções direcionadas (consulte a ref 2).
- O caso de uso de domínios associados oferece mais flexibilidade para os tipos de domínios que talvez exijam acesso a cookies de terceiros em jornadas ideais do usuário (consulte a ref 3). Os casos de uso de ccTLD e domínio de serviço usam verificações técnicas rigorosas com base nas características do domínio para minimizar o abuso, mas o domínio associado usa um limite numérico. Leia mais sobre isso na próxima seção.
O limite de domínios associados aumentou para cinco domínios
O Chrome propôs um limite numérico de três domínios para o subconjunto associado (mais um domínio principal), de acordo com nosso objetivo de evitar abusos de rastreamento generalizados. Recebemos feedback dos participantes dos padrões da Web informando que o limite era muito baixo para diferentes tipos de casos de uso.
Decidimos aumentar o limite de domínios associados para cinco domínios (mais um domínio principal), o que melhor corresponde à implementação mais semelhante oferecida por outro grande navegador (consulte a ref 4). Isso entrará em vigor a partir do Chrome 117.
Como o RWS não é uma solução de publicidade, não consideramos o feedback sobre como melhorar o RWS para atender melhor aos casos de uso de publicidade. Para casos de uso de anúncios, os desenvolvedores precisam explorar o uso das APIs Topics, Protected Audience e Attribution Reporting e enviar feedback sobre elas.
Os usuários têm a opção de casos de uso estendidos, além de cinco domínios associados
Para experiências que afetam o usuário e não são compatíveis com esse limite, o Chrome está trabalhando em um fluxo de solicitações dos usuários que também aproveita a API Storage Access (SAA), um padrão adotado por outros navegadores. Para casos de uso que precisam de mais de cinco domínios associados, recomendamos que os desenvolvedores avaliem como o SAA pode ser suportado em contextos não RWS. Seguimos o processo de lançamento do Blink separadamente para esse recurso, que será lançado no Chrome para computadores a partir do Chrome 117.
Próximas etapas
Agradecemos o feedback do ecossistema que ajudou a moldar a API até o momento. Investimos no RWS como um método para oferecer aos desenvolvedores previsibilidade, controle e agência na preservação da experiência do usuário final nos sites que eles criam. Mal podemos esperar para saber como os desenvolvedores vão adotar e usar o RWS conforme avançamos. O processo de envio está ativo no momento, e a ferramenta de geração de JSON do RWS é um ótimo ponto de partida para ajudar nos envios.
Siga a conversa sobre intent de envio para acompanhar o progresso e confira estes materiais para orientações de implementação.
Referências
- Há um consenso geral entre os navegadores de que esses casos de uso de cookies entre sites são necessários, mas eles têm abordagens diferentes para ativá-los. O Firefox (código) e o Safari (código) implementaram a heurística de pop-up que corrige a falha observada, por exemplo, no fluxo de login do Nintendo.
- Também há vários exemplos em que os navegadores fixam exceções no código para minimizar interrupções para os usuários. O Firefox concede acesso ao armazenamento em fluxos de redirecionamento entre o Microsoft Teams e o login.microsoftonline.us.
- O Firefox oferece um "shim" que chamará requestStorageAccessForOrigin em nome de facebook.com quando o usuário fizer login em instagram.com. Um exemplo de agrupamento de sites também pode ser visto nas exceções codificadas do Safari para agrupar solicitações de acesso ao armazenamento de vários domínios.
- O Firefox concede automaticamente as cinco primeiras chamadas requestStorageAccess feitas por um site de terceiros (código) que o usuário já visitou. No Chrome, os cinco primeiros domínios listados no subconjunto associado, além do domínio principal do mesmo conjunto, terão acesso automático a cookies de terceiros pelo RWS.