Muitas organizações têm sites relacionados com diferentes nomes de domínio, como
brandx.site
e fly-brandx.site
, ou domínios para diferentes países, como
example.com
, example.rs
, example.co.uk
e assim por diante.
Os navegadores estão se movendo para tornar os cookies de terceiros obsoletos (link em inglês) a fim de melhorar a privacidade na Web, mas sites como esses geralmente dependem de cookies para funcionalidades que exigem manutenção e acesso ao estado em vários domínios, como Logon único e gerenciamento de consentimento.
Os conjuntos primários podem permitir que nomes de domínio relacionados pertencentes e operados pela mesma entidade sejam tratados como primários em situações em que os próprios e de terceiros são tratados de maneira diferente. Os nomes de domínio em um conjunto primário são considerados da mesma parte e podem rotular quais cookies devem ser definidos ou enviados no mesmo contexto. O objetivo é encontrar um equilíbrio entre evitar o rastreamento entre sites por terceiros e ainda manter um caminho que não corrompa os casos de uso válidos.
A proposta de conjuntos primários está atualmente na fase de teste. Continue lendo para descobrir como ela funciona e como é possível testá-la.
Qual é a diferença entre cookies primários e de terceiros?
Os cookies não são primários ou de terceiros inerentemente. Eles dependem do contexto atual em que o cookie está incluído. Isso pode ser feito em 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 na
video.site
e uma solicitação for feita para video.site
, esse vai ser um contexto de
mesmo site, e o
cookie incluído será próprio.
No entanto, se você estiver em my-blog.site
, que incorpora um player de iframe para
video.site
, quando a solicitação for feita de my-blog.site
para video.site
,
isso é de contexto entre sites, e o cookie theme
será de terceiros.
A inclusão do cookie é determinada pelo atributo SameSite
dele:
- O contexto do mesmo site com
SameSite=Lax
,Strict
ouNone
torna 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
é um site de reservas de viagens que também usa fly-brandx.site
e drive-brandx.site
para separar voos e aluguel de carros. Durante a reserva de uma jornada, os visitantes acessam esses sites para selecionar as diferentes opções. Eles esperam que o "carrinho de compras" de seleções persista nesses sites. brandx.site
gerencia a sessão do usuário com um cookie SameSite=None
para permitir o acesso em
contextos entre sites. A desvantagem é que agora o cookie não tem proteção contra falsificação de solicitações entre sites (CSRF, na sigla em inglês). Se evil.site
incluir uma solicitação para
brandx.site
, ele incluirá esse cookie.
O cookie é usado entre sites, mas todos esses sites são pertencentes e operados pela mesma organização. Os visitantes também entendem que se trata da mesma organização e querem a mesma sessão, ou seja, uma identidade compartilhada entre eles.
Política de conjuntos primários
Os conjuntos primários propõem um
método para definir explicitamente essa relação em vários sites
que pertencem e são operados pela mesma parte. Isso permite que brandx.site
defina a relação primária 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 é baseado no conceito de identidade de particionamento para evitar o rastreamento entre sites, desenhando um limite entre sites que limita o acesso a qualquer informação que possa ser usada para identificar usuários.
Embora a opção padrão seja particionar por site, o que resolve muitos casos de uso
próprios, o exemplo de brandx.site
mostra que um primário pode ser maior
do que apenas um site.
Uma parte importante da proposta de conjuntos primários é garantir que a política em todos os navegadores evite abuso ou uso indevido. Por exemplo, conjuntos primários não podem permitir a troca de informações do usuário em sites não relacionados ou o agrupamento de sites que não pertencem à mesma entidade. A ideia é garantir que um conjunto primário seja mapeado para algo que uma pessoa entenda como primário e não seja usado como uma maneira de compartilhar a identidade entre partes diferentes.
Uma maneira possível de um site registrar um conjunto primário é enviar o grupo de domínios propostos para um rastreador público (como um repositório dedicado do GitHub) com as informações necessárias para atender à política do navegador.
Depois que a declaração do conjunto próprio é verificada de acordo com a política, os navegadores podem buscar listas de conjuntos usando um processo de atualização.
O teste de origem tem uma política definida que não é definitiva, mas os princípios 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 reconhecidos pelos usuários como um grupo.
- Os domínios precisam compartilhar uma Política de Privacidade comum.
Como definir um conjunto primário
Depois de identificar os membros e o proprietário do conjunto primário da sua organização, uma etapa crucial será enviar o conjunto proposto para aprovação. O processo exato ainda está em discussão.
Para declarar um conjunto próprio, os recursos JSON estáticos que listam membros e proprietários
precisam ser hospedados em /.well-known/first-party-set
no nível superior de cada
domínio incluído.
No exemplo do conjunto primário de brandx
, o proprietário-domínio hospeda o
seguinte 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.
Em https://fly-brandx.site/.well-known/first-party-set
, temos:
{ "owner": "brandx.site" }
Em https://drive-brandx.site/.well-known/first-party-set
:
{ "owner": "brandx.site" }
Existem algumas restrições para conjuntos primários:
- Um conjunto só pode ter um proprietário.
- Um membro só pode pertencer a um conjunto, sem sobreposição ou combinação.
- O objetivo da lista de membros é permanecer relativamente legível por humanos e não excessivamente grande.
Como os conjuntos primários afetam os cookies?
O ingrediente correspondente para os cookies é o atributo SameParty
proposto. A especificação de SameParty
informa ao navegador para incluir o cookie quando o contexto fizer parte do mesmo
conjunto primário do 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 nessa solicitação.
Se algum outro site que não faz parte do conjunto primário (por exemplo, hotel.xyz
) enviar uma solicitação para brandx.site
, o cookie não será incluído.
Até que o SameParty
seja amplamente aceito, use o atributo SameSite
com ele para definir o comportamento substituto para cookies. Você pode considerar o atributo SameParty
como 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. Caso contrário, recorre às restriçõesLax
.SameSite=None; SameParty
restringe a funcionalidadeNone
para contextos da mesma parte, quando compatível. Caso contrário, recorrerá às permissõesNone
mais amplas.
Existem alguns requisitos adicionais:
- Os cookies
SameParty
precisam incluirSecure
. - Os cookies
SameParty
não podem incluirSameSite=Strict
.
O uso do Secure
é obrigatório porque ele ainda ocorre entre sites. Reduza esses
riscos, garantindo conexões (HTTPS) seguras. Da mesma forma, como essa é uma
relação entre sites, SameSite=Strict
é inválido, porque ainda permite
uma proteção CSRF estrita com base no site dentro de um conjunto.
Quais casos de uso são adequados para conjuntos primários?
Os conjuntos primários são uma boa opção para os casos em que uma organização precisa de uma forma de identidade compartilhada em diferentes sites de nível superior. Nesse caso, identidade compartilhada significa tudo, desde uma solução completa de Logon único até a necessidade de uma preferência compartilhada entre sites.
Sua organização pode ter diferentes domínios de nível superior para:
- Domínios do aplicativo:
office.com
,live.com
emicrosoft.com
- Domínios com marca:
amazon.com
,audible.com
/disney.com
,pixar.com
- Domínios específicos do país para ativar a localização:
google.co.in
,google.co.uk
- Domínios de serviço com que os usuários nunca interagem diretamente, mas oferecem
serviços nos mesmos sites da organização:
gstatic.com
,githubassets.com
,fbcdn.net
- Domínios de sandbox com que os usuários nunca interagem diretamente, mas existem por
motivos de segurança:
googleusercontent.com
,githubusercontent.com
Como você pode se envolver?
Se você tem um conjunto de sites que corresponde aos critérios acima, há várias opções para participar. O menor investimento é ler e participar da discussão sobre as duas propostas:
- Discussão do grupo da comunidade de privacidade de conjuntos primários
- Discussão sobre o atributo de cookie SameParty
Durante a fase de teste, é possível testar a funcionalidade usando a
flag de linha de comando --use-first-party-set
e fornecendo uma lista de sites
separados por vírgulas.
Teste isso no site de demonstração em https://fps-member1.glitch.me/ (link em inglês) depois de iniciar o 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 no ambiente de desenvolvimento ou tentar
adicionar o atributo SameParty
em um ambiente ativo para ver como um
conjunto próprio afetaria os cookies.
Se você tiver largura de banda para testes e feedback, também poderá se inscrever no teste de origem para conjuntos primários e SameParty, disponível no Chrome da versão 89 a 93.
Como atualizar cookies para o teste de origem
Se você estiver participando do teste de origem e testando o atributo SameParty
nos
cookies, considere estes dois padrões.
Opção 1
Primeiro, quando você tem cookies rotulados como SameSite=None
, mas que gostaria de restringir a contextos próprios, adicione o atributo SameParty
a eles. Nos navegadores em que o teste de origem está ativo, o cookie não será enviado em contextos entre sites fora do conjunto.
No entanto, para a maioria dos navegadores fora do teste de origem, o cookie continuará sendo enviado entre sites normalmente. 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 totalmente o teste
de origem da funcionalidade existente e, especificamente, permite testar a
combinação 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, você só verá o cookie cname-fps
em uma solicitação entre sites se os sites envolvidos estiverem no conjunto e o navegador estiver no teste de origem. Considere essa abordagem como um
lançamento simultâneo de um recurso atualizado antes de desativar a versão
anterior.
Por que um conjunto primário não é necessário?
Para a maioria dos sites, o limite do site é aceitável para definir o limite de privacidade ou partição. Essa é a rota proposta pelo
CHIPS (Cookies com estado particionado independente), que dá aos sites uma rota de
permissão usando o atributo Partitioned
para manter essas incorporações, recursos, APIs e serviços essenciais entre sites, evitando o vazamento de informações
de identificação nos sites.
Alguns outros fatores a serem considerados significam que seu site pode estar bem sem precisar de um conjunto:
- você hospeda em origens diferentes, não em sites diferentes; No exemplo acima, se
brandx.site
tivessefly.brandx.site
edrive.brandx.site
, esses são subdomínios diferentes, todos no mesmo site. Os cookies podem usarSameSite=Lax
e não é necessário configurar nada. - Você fornece incorporações de terceiros a outros sites. Na introdução, o exemplo de
um vídeo de
video.site
incorporado emmy-blog.site
é uma divisão clara de terceiros. Os sites são operados por organizações diferentes, e os usuários os veem como entidades separadas. Esses dois locais não devem estar em um conjunto. - Você fornece serviços de login social de terceiros. Os provedores de identidade que usam recursos como OAuth ou OpenId Connect geralmente dependem de cookies de terceiros para uma experiência de login mais tranquila para os usuários. É um caso de uso válido, mas não é adequado para conjuntos primários, porque há uma diferença clara nas organizações. Propostas iniciais, como o WebID, estão explorando maneiras de ativar esses casos de uso.