Instruções de teste para conjuntos primários

A iteração mais recente dos conjuntos primários está pronta para testes de flag de recurso para desenvolvedores a partir do Chrome 108. Estamos trabalhando ativamente em conjuntos primários com o objetivo de avançar para o envio. Por isso, vamos considerar o feedback para essa fase de testes de 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 vão ser afetados quando os 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 para que ele possa realizar a ação apropriada em nome do usuário e/ou apresentar efetivamente essas informações 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 os cookies em um conjunto primário. As instruções abaixo permitem que você teste e valide os conjuntos que quer 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 (FPS, na sigla em inglês) são um mecanismo de plataforma da Web para desenvolvedores declararem relações entre sites, de modo que os navegadores possam usar essas informações a fim de ativar o acesso limitado a cookies entre sites para fins específicos e voltados ao usuário. O Chrome usará essas relações declaradas para decidir quando permitir ou negar o acesso de um site aos cookies dele quando estiver em um contexto de terceiros.

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

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

Com a 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 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.

Atualmente, 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 de QPS em sites de nível superior que usam imagens entre sites ou tags de script que exigem cookies. Para resolver alguns desses desafios, propomos 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á exibida publicamente em formato de arquivo JSON e armazenada em um novo repositório de FPS 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 o 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 em versões estáveis do Chrome.

Como o processo de envio de conjuntos ainda está em desenvolvimento, para testes locais, você só pode criar conjuntos na linha de comando e transmiti-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 mais recente, iniciado na linha de comando.

Para visualizar os próximos recursos do Chrome antes de serem lançados, 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 mais sobre como executar o Chromium com sinalizações.

Etapas

Para ativar o QPS localmente, use a opção --enable-features do Chrome com uma lista separada por vírgulas de sinalizações explicadas nesta seção e declare um conjunto de sites relacionados como um objeto JSON a ser transmitido para --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 cookies de terceiros são bloqueados pelo navegador.

Observe que, quando chamado, requestStorageAccess() exige um gesto do usuário para ser resolvido. Versões futuras do Chrome poderão impor diferentes conjuntos de requisitos, já que a especificação SAA ainda está em evolução. Consulte aqui uma lista das melhorias planejadas para a implementação do SAA pelo 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 aborda alguns dos desafios na adoção de SAA.

Declarar um conjunto localmente

Um conjunto primário é um conjunto de domínios em que há um único "conjunto principal" e, possivelmente, vários "membros do conjunto". Os membros do conjunto podem incluir vários tipos de domínio diferentes com subconjuntos baseados 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, você só pode criar conjuntos na linha de comando e passá-los diretamente para o navegador. Para fins de teste local, não haverá validação definida, mas quando o QPS for enviado em versões estáveis, todos os conjuntos precisarão ser enviados ao repositório de FPS do GitHub 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", que pode ser acessada pela barra de URL.

PrivacySandboxFirstPartySetsUI

Ativa a interface de FPS "Permitir que sites relacionados vejam sua atividade no grupo" 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á ativado.
  3. Verifique se a subopção "Permitir que sites relacionados vejam sua atividade no grupo" também seja ativado.

Considerações sobre segurança

Como a API Storage Access permite que os sites recuperem o acesso a cookies de terceiros em casos selecionados, ela pode deixar os aplicativos da Web suscetíveis a ataques entre sites e a vazamentos de informações. Os sites que dependem de cookies em contextos entre sites precisam estar cientes dos riscos do 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 dos elementos incorporados. As melhorias propostas iriam: conceder acesso apenas por frame, exigir CORS em solicitações credenciadas e manter o escopo do acesso apenas à origem. Saiba mais na análise de segurança recente.

Confira a lista de melhorias planejadas para a implementação da SAA pelo 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 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 com um QPS, e os sites devem continuar usando as práticas recomendadas de segurança padrão.

Interaja e compartilhe feedback

Os testes locais são uma oportunidade de usar 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 para compartilhar sua experiência com as etapas de processo e validação. Para interagir e compartilhar feedback sobre a proposta atualizada: