[OUTDATED] Conjuntos primários e o atributo SameParty

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.

Diagrama mostrando um cookie do video.site em dois contextos. O cookie é o mesmo site quando o contexto de nível superior também é video.site. O cookie é usado entre sites quando o contexto de nível superior é my-blog.site com video.site em um iframe.

A inclusão do cookie é determinada pelo atributo SameSite dele:

  • O contexto do mesmo site com SameSite=Lax, Strict ou None 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.

Diagrama mostrando como um cookie ainda pode ser incluído em um contexto entre sites se os sites fizerem parte do mesmo conjunto primário, mas que seria rejeitado para contextos entre sites fora desse conjunto.

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.

Diagrama mostrando o estado não particionado em que o mesmo cookie de terceiros está acessível em vários contextos entre sites, em comparação com um modelo particionado em que cada contexto de nível superior tem uma instância separada do cookie entre sites, impedindo a vinculação de atividades entre esses sites.

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.

Diagrama mostrando como a mesma instância de um cookie para um conjunto pode ser incluída em contextos entre sites quando todos esses sites fazem parte do mesmo conjunto.

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.

Diagrama mostrando o cookie brandx.site permitido ou bloqueado em contextos entre sites, conforme descrito.

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 funcionalidade Lax para incluir contextos da mesma parte quando compatível. Caso contrário, recorre às restrições Lax.
  • SameSite=None; SameParty restringe a funcionalidade None para contextos da mesma parte, quando compatível. Caso contrário, recorrerá às permissões None mais amplas.

Existem alguns requisitos adicionais:

  • Os cookies SameParty precisam incluir Secure.
  • Os cookies SameParty não podem incluir SameSite=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 e microsoft.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:

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 tivesse fly.brandx.site e drive.brandx.site, esses são subdomínios diferentes, todos no mesmo site. Os cookies podem usar SameSite=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 em my-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.