Instruções de teste para conjuntos primários

A iteração mais recente do First-Party Sets está pronta para testes de sinalização de recursos para desenvolvedores do Chrome 108. Estamos trabalhando ativamente nos conjuntos primários com o objetivo de migrar para o envio. Por isso, consideraremos o feedback para essa fase de testes para desenvolvedores até o lançamento do Chrome 111, no início de 7 de março de 2023.

O feedback do ecossistema destacou casos de uso entre sites que serão afetados quando cookies de terceiros não forem mais compatíveis com o Chrome. A proposta de conjuntos primários examina e aborda uma classe de casos de uso entre sites em que os sites interdependentes compartilham uma relação que pode ser expressada ao navegador de modo que ele possa realizar a ação adequada em nome do usuário e/ou apresentar de maneira eficaz essa informação a ele.

A proposta atualizada usa duas APIs (a API Storage Access e uma nova API provisoriamente chamada requestStorageAccessForOrigin) para fornecer aos sites um método ativo de solicitação de acesso entre sites para cookies em um conjunto primário. As instruções abaixo permitem que você teste e valide quais conjuntos você pode criar para seus sites e os pontos certos para chamar as duas APIs diferentes.

Visão geral dos conjuntos primários

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

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

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

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

No momento, a 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 QPS para sites de nível superior que usam imagens entre sites ou tags de script que exigem cookies. Para enfrentar alguns desses desafios, sugerimos 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 QPS será uma lista visível publicamente em um formato de arquivo JSON hospedada em um novo repositório de QPS do GitHub (link em inglês), que vai servir como a fonte da verdade para todos os conjuntos. O Chrome vai consumir esse arquivo para aplicar ao comportamento dele.

Para saber mais sobre o processo proposto e os requisitos para envio de conjuntos, confira as diretrizes de envio. Você também pode enviar um conjunto para testar as diversas verificações técnicas que validarão os envios. Todos os envios serão apagados antes que o QPS 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, você só pode criar conjuntos na linha de comando e passá-los diretamente para o 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 na linha de comando.

Para visualizar os próximos recursos do Chrome antes de eles serem lançados, faça o download da versão Beta ou Canary.

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 mais sobre como executar o Chromium com sinalizações.

Passos

Para ativar o QPS no local, é necessário usar a opção --enable-features do Chrome com uma lista de sinalizações separadas por vírgulas, explicadas nesta seção, e declarar um conjunto de sites relacionados como um objeto JSON a ser transmitido para --use-first-party-set.

Ativar QPS

FirstPartySets ativa 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 cookies de terceiros forem bloqueados pelo navegador.

Observe que, quando chamado, requestStorageAccess() exige um gesto do usuário para ser resolvido. Futuras versões do Chrome poderão impor diferentes conjuntos de requisitos, já que a especificação 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 o 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 enfrentam alguns dos desafios na adoção da SAA.

Declarar um conjunto localmente

Um conjunto primário é um conjunto de domínios em que há um único "conjunto primário" e possivelmente vários "membros do conjunto". Os membros do conjunto podem incluir uma variedade de tipos de domínio diferentes com subconjuntos com base nos casos de uso.

Crie um objeto JSON que contenha URLs que são 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, você só pode criar conjuntos na linha de comando e passá-los diretamente para o navegador. Para fins de teste locais, não há validação definida, mas quando o FPS for enviado em versões estáveis, todos os conjuntos precisarão ser enviados ao repositório do GitHub do FPS e estarão sujeitos aos critérios de validação.

Ativar interface de QPS

PageInfoCookiesSubpage

Ativa a exibição de QPS na seção "PageInfo" acessível pela barra de URL.

PrivacySandboxFirstPartySetsUI

Ativa a opção "Permitir que sites relacionados vejam sua atividade no grupo" na interface de 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 vejam 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 determinados casos, ela pode deixar os aplicativos da Web suscetí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, futuras versões do Chrome exigirão controles de segurança adicionais, com o objetivo de garantir a aceitação explícita das incorporações. As melhorias propostas seriam: conceder acesso somente por frame, exigir CORS em solicitações credenciadas e manter o escopo de acesso apenas à origem. Confira mais informações na análise de segurança recente.

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

O Chrome só envia cookies marcados como SameSite=None em contextos incorporados entre sites, quando a API Storage Access é relevante. Até que todos os navegadores tenham descontinuado o acesso padrão a esses cookies, nenhuma suposição pode ser feita sobre onde o cookie pode ser usado. Não é seguro presumir que o acesso só seria permitido em um QPS, e os sites devem continuar usando as práticas recomendadas de segurança padrão.

Interaja e compartilhe feedback

O teste local é uma oportunidade de testar o mecanismo da API Storage Access para ativar o QPS e compartilhar feedback ou qualquer problema encontrado. Além disso, testar o processo de envio de conjuntos no GitHub é uma oportunidade de compartilhar sua experiência com as etapas do processo e de validação. Para interagir e compartilhar feedback sobre a proposta atualizada, faça o seguinte: