Os conjuntos de sites relacionados (RWS, na sigla em inglês) são um mecanismo de plataforma da Web que ajuda os navegadores a entender as relações entre um conjunto de domínios. Isso permite que os navegadores tomem decisões importantes para ativar determinadas funções do site (como permitir o acesso a cookies entre sites) e apresentar essas informações aos usuários.
Como o Chrome descontinua o uso de cookies de terceiros, o objetivo é manter os principais casos de uso na Web e melhorar a privacidade dos usuários. Por exemplo, muitos sites dependem de vários domínios para oferecer uma única experiência do usuário. As organizações podem querer manter diferentes domínios de nível superior para vários casos de uso, como domínios específicos do país ou domínios de serviço para hospedagem de imagens ou vídeos. Com os conjuntos de sites relacionados, os sites podem compartilhar dados entre domínios com controles específicos.
O que é um conjunto de sites relacionados?
De forma geral, um conjunto de sites relacionados é uma coleção de domínios, que tem um único "conjunto principal" e potencialmente vários "membros do conjunto".
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"]
}
A lista canônica de conjuntos de sites relacionados é uma lista visível publicamente em um formato de arquivo JSON hospedado no repositório de conjuntos de sites relacionados do GitHub, que serve como a fonte da verdade para todos os conjuntos. O Chrome usa esse arquivo para aplicar o comportamento.
Somente quem tem controle administrativo sobre um domínio pode criar um conjunto com ele. Os remetentes precisam declarar a relação entre cada "elemento do conjunto" e o "principal do conjunto". Os membros do conjunto podem incluir vários tipos de domínio diferentes e precisam fazer parte de um subconjunto com base em um caso de uso.
Se o aplicativo depender do acesso a cookies entre sites (também chamados de cookies de terceiros) em sites do mesmo conjunto de sites relacionados, use a API Storage Access (SAA) e a API requestStorageAccessFor para solicitar acesso a esses cookies. Dependendo do subconjunto em que cada site faz parte, o navegador pode processar a solicitação de maneira diferente.
Para saber mais sobre o processo e os requisitos para enviar conjuntos, consulte as diretrizes de envio. Os conjuntos enviados passam por várias verificações técnicas para validação.
Casos de uso de conjuntos de sites relacionados
Os conjuntos de sites relacionados são uma boa opção para casos em que uma organização precisa de uma forma de identidade compartilhada em diferentes sites de nível superior.
Alguns dos casos de uso para conjuntos de sites relacionados são:
- Personalização por país. Usar sites localizados com infraestrutura compartilhada (example.co.uk pode depender de um serviço hospedado por example.ca).
- Integração de domínio de serviço. Usar domínios de serviço com que os usuários não interagem diretamente, mas que fornecem serviços nos sites da mesma organização (example-cdn.com).
- Separação do conteúdo do usuário. Acesso a dados em diferentes domínios que separam o conteúdo enviado pelo usuário de outros conteúdos do site por motivos de segurança, permitindo que o domínio em sandbox acesse cookies de autenticação (e outros). Se você estiver veiculando conteúdo inativo enviado pelo usuário, também poderá hospedar esse conteúdo com segurança no mesmo domínio seguindo as práticas recomendadas.
- Conteúdo autenticado incorporado. Suporte a conteúdo incorporado de propriedades afiliadas (vídeos, documentos ou recursos restritos ao usuário conectado no site de nível superior).
- Fazer login. Suporte ao login em propriedades afiliadas. A API FedCM também pode ser adequada para alguns casos de uso.
- Google Analytics. Implantar análises e medições das jornadas do usuário em propriedades afiliadas para melhorar a qualidade dos serviços.
Detalhes da integração dos conjuntos de sites relacionados
API Storage Access
A API Storage Access (SAA) oferece uma maneira de o conteúdo incorporado de várias origens acessar o armazenamento que normalmente só teria acesso em um contexto próprio.
Os recursos incorporados podem usar métodos de SAA para verificar se eles têm acesso ao armazenamento e solicitar acesso ao agente do usuário.
Quando os cookies de terceiros são bloqueados, mas os conjuntos de sites relacionados (RWS, na sigla em inglês) estão ativados, o Chrome concede a permissão automaticamente em contextos intra-RWS e mostra uma solicitação ao usuário. Um "contexto intra-RWS" é um contexto, como um iframe, em que o site incorporado e o site de nível superior estão no mesmo RWS.
Verificar e solicitar acesso ao armazenamento
Para verificar se eles têm acesso ao armazenamento, os sites incorporados podem usar o método Document.hasStorageAccess()
.
O método retorna uma promessa que é resolvida com um valor booleano indicando se o documento já tem acesso aos cookies ou não. A promessa também retorna true se o iframe tiver a mesma origem que o frame principal.
Para solicitar acesso a cookies em um contexto entre sites, os sites incorporados podem usar Document.requestStorageAccess()
(rSA).
A API requestStorageAccess()
precisa ser chamada em um iframe. Esse iframe precisa ter recebido uma interação do usuário (um gesto do usuário, que é obrigatório para todos os navegadores), mas o Chrome também exige que, em algum momento nos últimos 30 dias, o usuário tenha visitado o site proprietário desse iframe e interagido com ele especificamente, como um documento de nível superior, e não em um iframe.
requestStorageAccess()
retorna uma promessa que resolve se o acesso ao armazenamento foi concedido. A promessa é rejeitada, citando o motivo, se o acesso foi negado por qualquer motivo.
requestStorageAccessFor no Chrome
A API Storage Access só permite que sites incorporados solicitem acesso ao armazenamento em elementos <iframe>
que receberam interação do usuário.
Isso dificulta a adoção da API Storage Access para sites de nível superior que usam imagens entre sites ou tags de script que exigem cookies.
Para resolver esse problema, o Chrome implementou uma maneira de sites de nível superior solicitarem acesso de armazenamento em nome de origens específicas com Document.requestStorageAccessFor()
(rSAFor).
document.requestStorageAccessFor('https://target.site')
A API requestStorageAccessFor()
precisa ser chamada por um documento de nível superior. Esse documento também precisa ter recebido interação do usuário. No entanto, ao contrário do requestStorageAccess()
, o Chrome não verifica uma interação em um documento de nível superior nos últimos 30 dias porque o usuário já está na página.
Verificar as permissões de acesso ao armazenamento
O acesso a alguns recursos do navegador, como câmera ou geolocalização, é baseado nas permissões concedidas pelo usuário. A API Permissions oferece uma maneira de verificar o status de permissão para acessar uma API, seja ela concedida, negada ou se ela exige alguma forma de interação do usuário, como clicar em um comando ou interagir com a página.
É possível consultar o status da permissão usando navigator.permissions.query()
.
Para verificar a permissão de acesso ao armazenamento para o contexto atual, é necessário transmitir a string 'storage-access'
:
navigator.permissions.query({name: 'storage-access'})
Para verificar a permissão de acesso ao armazenamento de uma origem específica, transmita a string 'top-level-storage-access'
:
navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
Para proteger a integridade da origem incorporada, esse método verifica apenas as permissões concedidas pelo documento de nível superior usando document.requestStorageAccessFor
.
Dependendo se a permissão pode ser concedida automaticamente ou se ela exige um gesto do usuário, ela vai retornar prompt
ou granted
.
Modelo por frame
Os grants de rSA são aplicados por frame. Os grants de rSA e rSAFor são tratados como permissões separadas.
Cada novo frame precisará solicitar o acesso de armazenamento individualmente, e o acesso será concedido automaticamente. Apenas a primeira solicitação requer um gesto do usuário. As solicitações subsequentes iniciadas pelo iframe, como navegação ou subrecursos, não precisam esperar por um gesto do usuário, porque isso será concedido para a sessão de navegação pela solicitação inicial.
A atualização, o recarregamento ou a recriação do iframe vão exigir que você solicite o acesso novamente.
Requisitos de cookies
Os cookies precisam especificar os atributos SameSite=None
e Secure
, já que o rSA só oferece acesso a cookies que já estão marcados para uso em contextos entre sites.
Os cookies com SameSite=Lax
, SameSite=Strict
ou sem um atributo SameSite
são usados apenas pela própria empresa e nunca são compartilhados em um contexto entre sites, independentemente do rSA.
Segurança
Para rSAFor, as solicitações de subrecurso exigem cabeçalhos de compartilhamento de recursos entre origens (CORS) ou o atributo crossorigin
nos recursos, garantindo a ativação explícita.
Exemplos de implementação
Solicitar acesso ao armazenamento de um iframe entre origens incorporado

requestStorageAccess()
em uma incorporação em outro site.Verificar se você tem acesso de armazenamento
Para verificar se você já tem acesso ao armazenamento, use document.hasStorageAccess()
.
Se a promessa for resolvida como verdadeira, você poderá acessar o armazenamento no contexto entre sites. Se o resultado for falso, você vai precisar solicitar acesso ao armazenamento.
document.hasStorageAccess().then((hasAccess) => {
if (hasAccess) {
// You can access storage in this context
} else {
// You have to request storage access
}
});
Solicitar acesso ao armazenamento
Se você precisar solicitar o acesso ao armazenamento, primeiro verifique a permissão de acesso ao armazenamento navigator.permissions.query({name: 'storage-access'})
para saber se ela exige um gesto do usuário ou se pode ser concedida automaticamente.
Se a permissão for granted
, você poderá chamar document.requestStorageAccess()
, e ela será bem-sucedida sem uma ação do usuário.
Se o status da permissão for prompt
, você precisará iniciar a chamada document.requestStorageAccess()
após um gesto do usuário, como um clique no botão.
Exemplo:
navigator.permissions.query({name: 'storage-access'}).then(res => {
if (res.state === 'granted') {
// Permission has already been granted
// You can request storage access without any user gesture
rSA();
} else if (res.state === 'prompt') {
// Requesting storage access requires user gesture
// For example, clicking a button
const btn = document.createElement("button");
btn.textContent = "Grant access";
btn.addEventListener('click', () => {
// Request storage access
rSA();
});
document.body.appendChild(btn);
}
});
function rSA() {
if ('requestStorageAccess' in document) {
document.requestStorageAccess().then(
(res) => {
// Use storage access
},
(err) => {
// Handle errors
}
);
}
}
As solicitações subsequentes dentro do frame, navegações ou subrecursos terão permissão automática para acessar cookies entre sites. hasStorageAccess()
retorna "true", e os cookies entre sites do mesmo conjunto de sites relacionados são enviados nessas solicitações sem chamadas JavaScript adicionais.
Sites de nível superior que solicitam acesso a cookies em nome de sites de origem cruzada

requestStorageAccessFor()
em um site de nível superior para uma origem diferenteOs sites de nível superior podem usar requestStorageAccessFor()
para solicitar acesso ao armazenamento em nome de origens específicas.
O hasStorageAccess()
verifica apenas se o site que o chama tem acesso ao armazenamento. Assim, um site de nível superior pode verificar as permissões de outra origem.
Para descobrir se o usuário vai receber uma solicitação ou se o acesso ao armazenamento já foi concedido à origem especificada, chame navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})
.
Se a permissão for granted
, chame document.requestStorageAccessFor('https://target.site')
. Ele precisa ser bem-sucedido sem um gesto do usuário.
Se a permissão for prompt
, você vai precisar vincular a chamada document.requestStorageAccessFor('https://target.site')
ao gesto do usuário, como um clique no botão.
Exemplo:
navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
if (res.state === 'granted') {
// Permission has already been granted
// You can request storage access without any user gesture
rSAFor();
} else if (res.state === 'prompt') {
// Requesting storage access requires user gesture
// For example, clicking a button
const btn = document.createElement("button");
btn.textContent = "Grant access";
btn.addEventListener('click', () => {
// Request storage access
rSAFor();
});
document.body.appendChild(btn);
}
});
function rSAFor() {
if ('requestStorageAccessFor' in document) {
document.requestStorageAccessFor().then(
(res) => {
// Use storage access
},
(err) => {
// Handle errors
}
);
}
}
Depois de uma chamada requestStorageAccessFor()
bem-sucedida, as solicitações entre sites vão incluir cookies se incluírem CORS ou o atributo crossorigin. Portanto, os sites podem esperar antes de acionar uma solicitação.
As solicitações precisam usar a opção credentials: 'include'
, e os recursos precisam incluir o atributo crossorigin="use-credentials"
.
function checkCookie() {
fetch('https://related-website-sets.glitch.me/getcookies.json', {
method: 'GET',
credentials: 'include'
})
.then((response) => response.json())
.then((json) => {
// Do something
});
}
Como testar localmente
Pré-requisitos
Para testar conjuntos de sites relacionados localmente, use o Chrome 119 ou mais recente iniciado na linha de comando e ative a flag do Chrome test-third-party-cookie-phaseout
.
Ativar a flag do Chrome
Para ativar a flag necessária do Chrome, acesse chrome://flags#test-third-party-cookie-phaseout
na barra de endereço e mude a flag para Enabled
. Reinicie o navegador depois que as flags forem alteradas.
Iniciar o Chrome com um conjunto de sites relacionados locais
Para iniciar o Chrome com o conjunto de sites relacionados declarado localmente, crie um objeto JSON que contenha URLs que sejam membros de um conjunto e transmita-o para --use-related-website-set
.
Saiba mais sobre como executar o Chromium com flags.
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
Exemplo
Para ativar os conjuntos de sites relacionados localmente, você precisa ativar o test-third-party-cookie-phaseout
em chrome://flags
e iniciar o Chrome na linha de comando com a flag --use-related-website-set
e o objeto JSON que contém os URLs que são membros de um conjunto.
--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/
Verifique se você tem acesso a cookies entre sites
Chame as APIs (rSA ou rSAFor) dos sites que estão sendo testados e valide o acesso aos cookies entre sites.
Processo de envio de conjuntos de sites relacionados
Siga as etapas abaixo para declarar a relação entre os domínios e especificar o subconjunto a que eles pertencem.
1. Identificar o RWS
Identifique os domínios relevantes, incluindo o principal do conjunto e os membros do conjunto que vão fazer parte do conjunto de sites relacionados. Identifique também a qual tipo de subconjunto cada membro do conjunto pertence.
2. Criar seu envio de RWS
Crie uma cópia local (clone ou bifurcação) do repositório do GitHub. Em uma nova ramificação, faça as mudanças no arquivo related_website_sets.JSON para refletir seu conjunto. Para garantir que o conjunto tenha a formatação e a estrutura JSON corretas, use a ferramenta de geração de JSON.
3. Verifique se o RWS atende aos requisitos técnicos
Verifique se os requisitos de formação do conjunto e os requisitos de validação do conjunto estão em vigor.
4. Testar o RWS localmente
Antes de criar uma pull request (PR) para enviar o conjunto, teste o envio localmente para garantir que ele passe por todas as verificações necessárias.
5. Enviar o RWS
Envie o conjunto de sites relacionados criando um PR para o arquivo related_website_sets.JSON, em que o Chrome hospeda a lista canônica de conjuntos de sites relacionados. É necessário ter uma conta do GitHub para criar PRs, e você vai precisar assinar um contrato de licença do colaborador (CLA, na sigla em inglês) antes de contribuir para a lista.
Depois que a PR é criada, uma série de verificações é concluída para
garantir que os requisitos da etapa 3 estejam em vigor, como verificar se você
assinou o CLA e se o arquivo .well-known
é válido.
Se for bem-sucedido, a PR vai indicar que as verificações foram aprovadas. Os PRs aprovados serão mesclados manualmente em lotes à lista canônica de conjuntos de sites relacionados uma vez por semana (às terças-feiras, às 12h do horário da Costa Leste dos EUA). Se alguma das verificações falhar, o remetente vai receber uma notificação de falha de PR no GitHub. O remetente pode corrigir os erros e atualizar a PR, mas lembre-se de que:
- Se a PR falhar, uma mensagem de erro vai fornecer mais informações sobre o motivo da falha. (exemplo).
- Todas as verificações técnicas que regem os envios de conjuntos são realizadas no GitHub. Consequentemente, todas as falhas de envio resultantes de verificações técnicas vão aparecer no GitHub.
Políticas empresariais
O Chrome tem duas políticas para atender às necessidades dos usuários corporativos:
- Os sistemas que não podem ser integrados aos conjuntos de sites relacionados podem desativar o recurso em todas as instâncias corporativas do Chrome com a política
RelatedWebsiteSetsEnabled
. - Alguns sistemas corporativos têm sites somente internos (como uma intranet) com domínios registráveis diferentes dos domínios do conjunto de sites relacionados. Se eles precisarem tratar esses sites como parte do conjunto de sites relacionados sem expô-los publicamente (já que os domínios podem ser confidenciais), eles poderão aumentar ou substituir a lista pública de conjuntos de sites relacionados com a política
RelatedWebsiteSetsOverrides
.
O Chrome resolve qualquer interseção dos conjuntos público e Enterprise de uma das duas
maneiras, dependendo se replacemements
ou additions
são especificados.
Por exemplo, para o conjunto público {primary: A, associated: [B, C]}
:
replacements set: |
{primary: C, associated: [D, E]} |
O conjunto de empresa absorve o site comum para formar um novo conjunto. | |
Conjuntos resultantes: | {primary: A, associated: [B]} {primary: C, associated: [D, E]} |
additions set: |
{primary: C, associated: [D, E]} |
Os conjuntos público e Enterprise são combinados. | |
Conjunto resultante: | {primary: C, associated: [A, B, D, E]} |
Resolver problemas de conjuntos de sites relacionados
"Prompt do usuário" e "gesto do usuário"
Um "prompt do usuário" e um "gesto do usuário" são coisas diferentes. O Chrome não vai mostrar uma
solicitações de permissão
para usuários de sites que estão no mesmo conjunto de sites relacionados, mas ainda
exige que o usuário tenha interagido com a página. Antes de conceder a permissão,
o Chrome exige um
gesto do usuário,
também chamado de "interação do usuário" ou "ativação do usuário". Isso ocorre porque o uso da
API Storage Access fora do contexto de um conjunto de sites relacionados (ou seja, requestStorageAccess()
) também exige um gesto do usuário devido aos
princípios de design da plataforma da Web.
Acessar cookies ou armazenamento de outros sites
Os conjuntos de sites relacionados não mesclam o armazenamento de sites diferentes. Eles apenas permitem
chamadas requestStorageAccess()
mais fáceis (sem aviso). Os conjuntos de sites relacionados
apenas reduzem a fricção do usuário ao usar a API Storage Access, mas não
dizem o que fazer depois que o acesso é restaurado. Se A e B forem sites diferentes
no mesmo conjunto de sites relacionados e A incorporar B, B poderá chamar
requestStorageAccess()
e ter acesso ao armazenamento próprio sem solicitar
ao usuário. Os conjuntos de sites relacionados não realizam nenhuma comunicação entre sites. Por
exemplo, a configuração de um conjunto de sites relacionados não vai fazer com que os cookies pertencentes
a B comecem a ser enviados para A. Se você
quiser compartilhar esses dados, faça isso por conta própria, por exemplo,
enviando um window.postMessage
de um iframe B para um
frame A.
Acesso de cookies não particionados por padrão
Conjuntos de sites relacionados não permitem o acesso implícito de cookies não particionados
sem invocar nenhuma API. Os cookies entre sites não são disponibilizados
por padrão no conjunto. Os conjuntos de sites relacionados permitem que os sites do conjunto
ignorem a solicitação de permissão da API Storage Access.
Um iframe precisa chamar document.requestStorageAccess()
se quiser acessar os
cookies, ou a página de nível superior pode chamar document.requestStorageAccessFor()
.
Compartilhar feedback
Envie um conjunto no GitHub e trabalhe com a API Storage Access e a API requestStorageAccessFor
para compartilhar sua experiência com o processo e os problemas que encontrar.
Para participar das discussões sobre os conjuntos de sites relacionados:
- Participe da lista de e-mails pública sobre conjuntos de sites relacionados.
- Informe problemas e siga a discussão no repositório do GitHub de conjuntos de sites relacionados.