Instruções de teste para conjuntos primários

A iteração mais recente da API First-Party Sets está pronta para testes de flag de recurso do desenvolvedor no Chrome 108. Estamos trabalhando ativamente nos conjuntos de terceiros com o objetivo de enviar. Por isso, vamos considerar o feedback desta fase de testes com desenvolvedores até o lançamento do Chrome 111 no início de março (7 de março de 2023).

O feedback do ecossistema destacou casos de uso entre sites que serão afetados quando os cookies de terceiros não forem mais compatíveis com o Chrome. A proposta de conjuntos próprios examina e aborda uma classe de casos de uso entre sites em que os sites interdependentes compartilham uma relação que pode ser expressa ao navegador, de modo que ele possa tomar a ação apropriada em nome do usuário e/ou apresentar essas informações de maneira eficaz.

A proposta atualizada usa duas APIs (a API Storage Access e uma nova API com o nome provisório requestStorageAccessForOrigin) para fornecer aos sites um método ativo de solicitação de acesso entre sites para os cookies em um conjunto próprio. Com as instruções abaixo, você pode testar e validar quais conjuntos gostaria de criar para seus sites e os pontos certos para chamar as duas APIs diferentes.

Visão geral dos conjuntos próprios

Os conjuntos primários (FPS, na sigla em inglês) são um mecanismo de plataforma da Web para que os desenvolvedores declarem relações entre sites. Assim, os navegadores podem usar essas informações para permitir o acesso limitado de cookies entre sites para fins específicos voltados ao usuário. O Chrome vai usar essas relações declaradas para decidir quando permitir ou negar o acesso de um site aos cookies em um contexto de terceiros.

De forma geral, um conjunto primário é uma coleção de domínios com um único "conjunto principal" e potencialmente vários "membros do conjunto". Somente os autores do site podem enviar domínios para um conjunto e precisam declarar a relação entre cada "membro do conjunto" e o "principal do conjunto". Os membros do conjunto podem incluir uma variedade de tipos de domínio diferentes com subconjuntos com base em casos de uso.

Para facilitar o processamento de cada subconjunto pelo navegador de acordo com as implicações de privacidade de cada um deles, sugerimos o uso da API Storage Access (SAA) e do requestStorageAccessForOrigin para permitir o acesso a cookies em um FPS.

Com o SAA, os sites podem solicitar ativamente o acesso a cookies entre sites. O Chrome vai conceder a solicitação automaticamente se o site solicitante e o site de nível superior estiverem no mesmo FPS. Consulte a documentação da API Storage Access (SAA) para informações sobre como as chamadas para a SAA são processadas por outros navegadores.

No momento, o SAA exige que o documento receba a ativação do usuário antes de chamar os métodos da API.

Isso pode dificultar a adoção do FPS para sites de nível superior que usam imagens entre sites ou tags de script que exigem cookies. Para resolver alguns desses desafios, propusemos uma nova API, requestStorageAccessForOrigin, para facilitar a adoção dessa mudança pelos desenvolvedores. Essa API também está disponível para testes.

Definir envio

A lista canônica de FPS será uma lista visível publicamente em um formato de arquivo JSON armazenado em um novo repositório do GitHub de FPS, que vai servir como a fonte de verdade para todos os conjuntos. O Chrome vai consumir esse arquivo para aplicar ao comportamento.

Para saber mais sobre o processo proposto e os requisitos para enviar conjuntos, consulte as diretrizes de envio. Você também pode tentar enviar um conjunto para testar as várias verificações técnicas que vão validar os envios. Todos os envios serão limpos antes que o FPS esteja disponível nas versões estáveis do Chrome.

Como o processo de envio de conjuntos ainda está em desenvolvimento ativo, para testes locais, só é possível criar conjuntos na linha de comando e transmiti-los diretamente ao navegador. Para testes locais, não é necessário enviar um conjunto para o repositório do GitHub para testar com flags de recursos.

Como testar localmente

Pré-requisitos

Para testar o QPS localmente, use o Chrome 108 ou versão mais recente iniciado na linha de comando.

Para conferir os próximos recursos do Chrome antes do lançamento, faça o download da versão Beta ou Canary do Chrome.

Exemplo

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Saiba como executar o Chromium com flags.

Etapas

Para ativar o FPS localmente, use a opção --enable-features do Chrome com uma lista de flags separadas por vírgulas explicada nesta seção e declare um conjunto de sites relacionados como um objeto JSON para transmitir a --use-first-party-set.

Ativar QPS

FirstPartySets ativa o QPS no Chrome.

FirstPartySets

Ativar a API Storage Access

StorageAccessAPI

Ativa a API Storage Access (SAA) no Chrome, que permite que iframes incorporados usem requestStorageAccess() para solicitar acesso a cookies em um contexto entre sites, mesmo quando os cookies de terceiros são bloqueados pelo navegador.

Quando chamado, requestStorageAccess() exige um gesto do usuário para ser resolvido. Versões futuras do Chrome podem impor diferentes conjuntos de requisitos, já que a especificação do SAA ainda está em evolução. Consulte aqui uma lista de melhorias planejadas para a implementação do SAA no Chrome.

StorageAccessAPIForOriginExtension

Permite que sites de nível superior usem requestStorageAccessForOrigin() para solicitar acesso ao armazenamento em nome de origens específicas. Isso é útil para sites de nível superior que usam imagens entre sites ou tags de script que exigem cookies e resolve alguns dos desafios da adoção da SAA.

Declarar um conjunto localmente

Um First-Party Set é uma coleção de domínios, que tem um único "set primary" e potencialmente vários "set members". Os membros do conjunto podem incluir uma variedade de tipos de domínio diferentes com subconjuntos com base em casos de uso.

Crie um objeto JSON que contenha URLs que sejam membros de um conjunto e transmita-o para --use-first-party-set.

No exemplo abaixo, primary lista o domínio principal, e associatedSites lista os domínios que atendem aos requisitos do subconjunto associado.

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Exemplo:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

Para testes locais, só é possível criar conjuntos na linha de comando e transmiti-los diretamente para o navegador. Para fins de teste local, não haverá validação de conjunto, mas, quando o FPS for enviado em versões estáveis, todos os conjuntos precisarão ser enviados ao repositório do FPS no GitHub e estar sujeitos a critérios de validação.

Ativar a interface de QPS

PageInfoCookiesSubpage

Permite mostrar FPS na seção "PageInfo" acessível na barra de URL.

PrivacySandboxFirstPartySetsUI

Ativa a opção "Permitir que sites relacionados vejam sua atividade no grupo" na interface do FPS nas configurações do Chrome, em "Privacidade e segurança → Cookies e outros dados do site" (chrome://settings/cookies).

Verificar se os cookies de terceiros estão bloqueados

  1. Nas configurações do Chrome, acesse "Privacidade e segurança" → "Cookies e outros dados do site" ou "chrome://settings/cookies".
  2. Em "Configurações gerais", verifique se a opção "Bloquear cookies de terceiros" está ativada.
  3. Verifique se a subopção "Permitir que sites relacionados acessem sua atividade no grupo" também está ativada.

Considerações sobre segurança

Como a API Storage Access permite que os sites recuperem o acesso a cookies de terceiros em alguns casos, ela pode deixar os aplicativos da Web vulneráveis a ataques entre sites e vazamentos de informações. Os sites que dependem de cookies em contextos entre sites precisam estar cientes dos riscos de CSRF e de outros ataques.

Melhorias planejadas

Para melhorar isso, as próximas versões do Chrome vão exigir controles de segurança adicionais, com o objetivo de garantir a ativação explícita do embeddee. As melhorias propostas seriam: conceder acesso apenas por frame, exigir CORS em solicitações com credenciais e manter o escopo de acesso apenas para a origem. Leia mais na análise de segurança recente.

Confira a lista de melhorias planejadas para a implementação do SAA no Chrome.

O Chrome só envia cookies marcados como SameSite=None em contextos incorporados entre sites, que é onde a API Storage Access é relevante. No entanto, até que todos os navegadores desativem o acesso padrão a esses cookies, não é possível fazer suposições sobre onde o cookie pode ser usado. Não é seguro presumir que o acesso só será permitido em um FPS, e os sites precisam continuar usando as práticas recomendadas de segurança padrão.

Engajamento e compartilhamento de feedback

O teste local é uma oportunidade para testar o mecanismo da API Storage Access para ativar o FPS e compartilhar feedback ou problemas encontrados. Além disso, testar o processo de envio definido no GitHub é uma oportunidade para compartilhar sua experiência com o processo e as etapas de validação. Para interagir e compartilhar feedback sobre a proposta atualizada: