Muitas organizações têm sites relacionados com nomes de domínio diferentes, como
brandx.site
e fly-brandx.site
ou domínios de diferentes países, como
example.com
, example.rs
, example.co.uk
e assim por diante.
Os navegadores estão caminhando para criar cookies de terceiros obsoleta para melhorar a privacidade na Web, mas sites como esses muitas vezes dependem de cookies para funcionalidades que exigem a manutenção e o acesso do estado em todos os domínios (como Logon único e gerenciamento de consentimento).

Os conjuntos primários podem permitir nomes de domínio relacionados que pertencem e são operados por a mesma entidade seja tratada como primária em situações em que um terceiro será tratado de modo diferente. Os nomes de domínio em um conjunto primário são considerados mesmos e podem rotular quais cookies são sejam definidos ou enviados no contexto da mesma parte. O objetivo é encontrar equilibrar a prevenção do rastreamento entre sites por terceiros e, ao mesmo tempo, e manter um caminho que não corrompa casos de uso válidos.
A proposta de conjuntos primários está em teste (em inglês), continue lendo para saber como funciona. e como você pode testá-lo.
Qual é a diferença entre cookies primários e de terceiros?
Os cookies não são primários ou de terceiros, isso depende da configuração
em que o cookie está incluído. Isso ocorre por meio de uma solicitação no
Cabeçalho cookie
ou via document.cookie
em JavaScript.
Se, por exemplo, video.site
tiver um cookie theme=dark
, quando você estiver navegando
video.site
e uma solicitação for feita para video.site
, que é o mesmo site
contexto e os
cookie incluído é primário.
No entanto, se você estiver em my-blog.site
, que incorpora um player de iframe para
video.site
, quando a solicitação é feita de my-blog.site
para video.site
em um contexto entre sites, e o cookie theme
é de terceiros.

A inclusão de cookies é determinada pelo atributo SameSite
do cookie:
- Mesmo site
contexto com
SameSite=Lax
,Strict
ouNone
tornam o cookie primário. - O contexto entre sites com
SameSite=None
torna o cookie de terceiros.
No entanto, isso nem sempre é tão claro. Imagine que brandx.site
é uma viagem
site de reservas e eles também usam fly-brandx.site
e drive-brandx.site
para
voos e aluguel de carros separados. Ao reservar uma viagem, os visitantes
vão entre esses sites para selecionar as diferentes opções. Eles esperam que seus
"carrinho de compras" de seleções sejam mantidas nesses sites. brandx.site
gerencia a sessão do usuário com um cookie SameSite=None
para permitir o acesso
contextos entre sites. A desvantagem é que agora o cookie não tem opção cross-site
Solicitar proteção contra falsificação (CSRF, na sigla em inglês). Se evil.site
incluir uma solicitação para
brandx.site
, ele vai incluir esse cookie.
O cookie é usado entre sites, mas todos esses sites pertencem e são operados pela mesma organização. Os visitantes também entendem que é a mesma organização e querem que mesma sessão, ou seja, uma identidade compartilhada entre eles.

Política de conjuntos primários
Os conjuntos primários propõem
para definir explicitamente essa relação em vários sites que
sejam de propriedade e operadas pela mesma parte. Isso permitiria ao brandx.site
definir sua relação própria com fly-brandx.site
,
drive-brandx.site
e assim por diante.
O modelo de privacidade que impulsiona as várias propostas do Sandbox de privacidade são baseadas no conceito de particionamento identidade para evitar o rastreamento entre sites, traçando um limite entre os sites que limita o acesso a qualquer informação que possa ser usada para identificar os usuários.

A opção padrão é particionar por site, o que resolve muitos problemas
casos de uso diferentes, o exemplo de brandx.site
mostra que um primário pode ser maior
de apenas um site.

Uma parte importante da proposta de conjuntos primários é garantir que a política nos navegadores impede abuso ou uso indevido. Por exemplo, os conjuntos primários não podem permitir a troca de informações do usuário entre sites não relacionados ou o agrupamento de sites que não pertencem à mesma entidade. A ideia é garantir que O conjunto primário mapeia para algo que uma pessoa entende como primário e é não é usado como uma forma de compartilhar identidade entre partes diferentes.
Uma maneira possível de um site registrar um conjunto primário para enviar o grupo de domínios proposto a um rastreador público (como um repositório dedicado do GitHub), junto com as informações necessárias para atender às necessidades política.
Depois que a declaração do conjunto primário for verificada de acordo com a política, os navegadores poderão e depois buscar listas de conjuntos em um processo de atualização.
O teste de origem tem uma política definida que não é final, mas os princípios são provavelmente permanecerão os mesmos:
- Os domínios em um conjunto primário precisam pertencer e ser operados pela mesma organização.
- Os domínios devem ser reconhecíveis pelos usuários como um grupo.
- Os domínios precisam compartilhar uma Política de Privacidade em comum.
Como definir um conjunto primário
Depois de identificar os participantes e o proprietário da conta primária da sua organização, definido, uma etapa crucial será enviar o conjunto proposto para aprovação. O exato processo ainda está em discussão.
Para declarar um conjunto próprio, recursos JSON estáticos que listam membros e proprietários
deve ser hospedado em /.well-known/first-party-set
no nível superior de cada
domínio incluído.
No exemplo do conjunto primário brandx
, o domínio-proprietário hospeda o
seguindo em
https://brandx.site/.well-known/first-party-set
:
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
Cada membro do conjunto também hospeda um recurso JSON estático que aponta de volta para o
proprietário do conjunto.
Na https://fly-brandx.site/.well-known/first-party-set
, temos:
{ "owner": "brandx.site" }
E em https://drive-brandx.site/.well-known/first-party-set
:
{ "owner": "brandx.site" }
Há algumas restrições para conjuntos próprios:
- Um conjunto só pode ter um proprietário.
- Um membro só pode pertencer a um conjunto, sem sobreposição ou mistura.
- A lista de membros deve permanecer relativamente legível e não excessivamente grande.
Como os conjuntos primários afetam os cookies?
O ingrediente correspondente para os biscoitos é o SameParty
proposto
Atributo. Como especificar SameParty
informa ao navegador para incluir o cookie quando seu contexto faz parte do mesmo
definido como o contexto de nível superior.
Isso significa que, se brandx.site
definir esse cookie:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
Então, quando o visitante estiver em fly-brandx.site
e uma solicitação for para
brandx.site
, o cookie session
será incluído na solicitação.
Se algum outro site que não faz parte do conjunto primário, por exemplo,
hotel.xyz
, envia uma solicitação para brandx.site
, e o cookie não é incluído.

Até que o SameParty
seja amplamente aceito, use o atributo SameSite
com ele para
definir o comportamento substituto para cookies. Pense no SameParty
como fornecer uma configuração entre SameSite=Lax
e
SameSite=None
SameSite=Lax; SameParty
vai expandir a funcionalidadeLax
para incluir contextos da mesma parte, quando compatível, mas recorre aoLax
. restrições.SameSite=None; SameParty
vai restringir a funcionalidadeNone
a contextos da mesma parte quando há suporte, mas volta para uma abordagem Caso contrário,None
.
Há alguns requisitos adicionais:
- Os cookies
SameParty
precisam incluirSecure
. - Os cookies
SameParty
não podem incluirSameSite=Strict
.
Secure
é obrigatório porque ainda ocorre entre sites, e você deve mitigá-los
de segurança ao garantir conexões (HTTPS) seguras. Da mesma forma, como este é um
relacionamento entre sites, SameSite=Strict
é inválido, pois ainda permite
proteção CSRF com base no site em um conjunto.
Quais casos de uso são adequados para conjuntos primários?
Os conjuntos primários são uma boa opção para casos em que uma organização precisa de uma forma de identidade compartilhada entre diferentes sites de nível superior. Identidade compartilhada neste caso significa qualquer coisa, desde uma solução completa de logon único até a necessidade de apenas preferência entre os sites.
Sua organização pode ter diferentes domínios de nível superior para:
- Domínios de aplicativos:
office.com
,live.com
,microsoft.com
- Domínios de marca:
amazon.com
,audible.com
/disney.com
,pixar.com
- Domínios específicos de países para ativar a localização:
google.co.in
,google.co.uk
- Domínios de serviço com os quais os usuários nunca interagem diretamente, mas que fornecem
serviços nos sites da mesma organização:
gstatic.com
,githubassets.com
,fbcdn.net
- Domínios de sandbox com os quais os usuários nunca interagem diretamente, mas existem para
motivos de segurança:
googleusercontent.com
,githubusercontent.com
Como participar?
Se você tem um conjunto de sites que corresponde aos critérios acima, há um várias opções para participar. O menor investimento é ler e participar a discussão sobre as duas propostas:
- Discussão no grupo da comunidade sobre privacidade de conjuntos próprios
- Discussão sobre o atributo de cookies SameParty
Durante a fase de testes, você pode testar a funcionalidade usando o
Sinalização de linha de comando --use-first-party-set
e fornecer uma lista separada por vírgulas
de sites.
Você pode testar isso no site de demonstração em https://fps-member1.glitch.me/ (link em inglês) depois de começar Chrome com a seguinte sinalização:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
Isso é útil se você quiser testar em seu ambiente de desenvolvimento ou se quiser
tente adicionar o atributo SameParty
em um ambiente ativo para ver como uma
conjunto primário afeta os cookies.
Se você tiver largura de banda para experimentação e feedback, inscreva-se no Teste de origem para conjuntos primários e SameParty que está disponível nas versões 89 a 93 do Chrome.
Como atualizar cookies para o teste de origem
Se você estiver participando do teste de origem e testando o atributo SameParty
em
seus cookies, aqui estão dois padrões a serem considerados.
Opção 1
Primeiro, quando há cookies rotulados como SameSite=None
, mas
quiser restringir a contextos próprios, adicione o SameParty
a eles. Nos navegadores com o teste de origem ativo, o cookie
não podem ser enviadas em contextos entre sites fora do conjunto.
No entanto, para a maioria em navegadores fora do teste de origem, o cookie continuará sendo enviado entre sites, como de costume. Considere isso como uma abordagem de aprimoramento progressivo.
Antes:
set-cookie: cname=cval; SameSite=None; Secure
Depois:
set-cookie: cname=cval; SameSite=None; Secure; SameParty
Opção 2
A segunda opção é mais trabalhosa, mas permite separar completamente a origem
da funcionalidade existente e permite, especificamente, o teste da
SameSite=Lax; SameParty
.
Antes:
set-cookie: cname=cval; SameSite=None; Secure
Depois:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
Ao verificar o cookie nas solicitações recebidas, espere ver apenas
o cookie cname-fps
em uma solicitação entre sites se os sites envolvidos estiverem no
definido e o navegador está no teste de origem. Considere essa abordagem como um
lançamento simultâneo de um recurso atualizado antes de desativar o anterior
para a versão anterior.
Por que você não precisa de um conjunto primário?
Para a maioria dos locais, os limites do local são um lugar aceitável para definir
a partição ou o limite de privacidade. Esse é o trajeto proposto com
CHIPS (Cookies com Particionamento Independente)
State), que dá aos sites a opção de ativar o recurso.
usando o atributo Partitioned
para manter os dados críticos entre sites
incorporações, recursos, APIs e serviços, evitando o vazamento de informações
informações nos sites.
Alguns outros aspectos a serem considerados que significam que seu site pode funcionar bem sem a necessidade um conjunto:
- Você hospeda em origens diferentes, não em sites diferentes. No exemplo acima,
se
brandx.site
tivessefly.brandx.site
edrive.brandx.site
, então esses são subdomínios diferentes todos dentro do mesmo site. Os cookies podem usarSameSite=Lax
, e nenhum conjunto é necessário. - Você fornece incorporações de terceiros a outros sites. Na introdução, o exemplo
um vídeo do
video.site
incorporado emmy-blog.site
é um vídeo de terceiros evidente dividir. Os sites são operados por diferentes organizações e os usuários os veem como entidades separadas. Esses dois sites não devem estar juntos. - Você fornece serviços de login social de terceiros. Provedores de identidade que usam coisas como OAuth ou OpenID Connect geralmente dependem de cookies de terceiros para uma uma experiência de login mais tranquila para os usuários. É um caso de uso válido, mas não é adequados para conjuntos primários, porque há uma diferença clara nas organizações. As primeiras propostas, como WebID, são e conferir maneiras de viabilizar esses casos de uso.