[OUTDATED] Conjuntos primários e o atributo SameParty

Muitas organizações têm sites relacionados com nomes de domínio diferentes, 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 desativando os cookies de terceiros para melhorar a privacidade na Web, mas sites como esses geralmente dependem de cookies para funções que exigem a manutenção e o acesso ao estado em vários domínios, como o gerenciamento de consentimento e de login único.

Os conjuntos próprios podem permitir que nomes de domínio relacionados que são de propriedade e operados pela mesma entidade sejam tratados como próprios em situações em que próprios e terceiros são tratados de maneira diferente. Os nomes de domínio em um conjunto próprio são considerados próprios e podem rotular quais cookies devem ser definidos ou enviados no contexto próprio. O objetivo é encontrar um equilíbrio entre impedir o rastreamento entre sites por terceiros e manter um caminho que não quebre casos de uso válidos.

A proposta de conjuntos próprios está na fase de testes. Leia mais para saber como ela funciona e como você pode testá-la.

Qual é a diferença entre cookies próprios e de terceiros?

Os cookies não são inerentemente próprios ou de terceiros. Isso depende do contexto atual em que o cookie está incluído. Isso pode ser em uma solicitação no cabeçalho cookie ou pelo document.cookie no JavaScript.

Se, por exemplo, video.site tiver um cookie theme=dark, quando você estiver navegando em video.site e uma solicitação for feita para video.site, será um contexto do 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, esse é o contexto de vários sites, e o cookie theme é de terceiros.

Diagrama mostrando um cookie do video.site em dois contextos. O cookie é de mesmo site quando o contexto de nível superior também é video.site. O cookie é 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:

  • 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, nem sempre é assim. Imagine que brandx.site é um site de reservas de viagens e também usa fly-brandx.site e drive-brandx.site para separar voos e aluguel de carros. Durante o processo de reserva, os visitantes vão de um site para outro para selecionar as diferentes opções. Eles esperam que o "carrinho de compras" de seleções seja mantido nesses sites. brandx.site gerencia a sessão do usuário com um cookie SameSite=None para permitir que ela seja usada em contextos entre sites. A desvantagem é que 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 vai incluir esse cookie.

O cookie é entre sites, mas todos esses sites são de propriedade e operados pela mesma organização. Os visitantes também entendem que é a 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 ele seria rejeitado para contextos entre sites fora do conjunto.

Política de conjuntos primários

Os conjuntos próprios propõem um método para definir explicitamente essa relação em vários sites que são de propriedade e operados pela mesma parte. Isso permitiria que brandx.site definisse a relação própria com fly-brandx.site, drive-brandx.site e assim por diante.

O Modelo de privacidade que orienta as várias propostas do Sandbox de privacidade é baseado no conceito de particionamento de identidade para evitar o rastreamento entre sites, criando 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 é acessível em vários contextos entre sites, em contraste com um modelo particionado em que cada contexto de nível superior tem uma instância separada do cookie entre sites que impede a atividade de vinculação entre esses sites.

Embora a opção padrão seja particionar por site, o que resolve muitos casos de uso próprios, o exemplo 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, os conjuntos próprios 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 são de propriedade da mesma entidade. A ideia é garantir que um conjunto próprio seja mapeado para algo que uma pessoa entenda como próprio e não seja usado como uma forma de compartilhar a identidade entre diferentes partes.

Uma maneira possível de um site registrar um conjunto próprio é enviar o grupo proposto de domínios a 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 de conjunto próprio for verificada de acordo com a política, os navegadores poderão buscar listas de conjuntos por meio de um processo de atualização.

O teste de origem tem uma política definida que não é final, mas os princípios provavelmente vão permanecer os mesmos:

  • Os domínios em um conjunto próprio precisam ser de propriedade e operados pela mesma organização.
  • Os domínios precisam ser reconhecidos pelos usuários como um grupo.
  • Os domínios precisam compartilhar uma Política de Privacidade comum.

Como definir um conjunto próprio

Depois de identificar os membros e o proprietário do conjunto próprio 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 próprio brandx, o domínio do proprietário 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" }

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 para humanos e não ser excessivamente grande.

Como os conjuntos primários afetam os cookies?

O ingrediente correspondente para cookies é o atributo SameParty proposto. Especificar SameParty diz ao navegador para incluir o cookie quando o contexto dele faz parte do mesmo conjunto próprio que o contexto de nível superior.

Isso significa que, se brandx.site definir esse cookie:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Quando o visitante está em fly-brandx.site e uma solicitação é enviada para brandx.site, o cookie session é incluído nessa solicitação. Se 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 SameParty tenha suporte amplo, use o atributo SameSite com ele para definir o comportamento de fallback para cookies. O atributo SameParty pode ser considerado uma configuração entre SameSite=Lax e SameSite=None.

  • O SameSite=Lax; SameParty expande a funcionalidade Lax para incluir contextos de mesma parte, quando houver suporte, mas volta às restrições Lax se não houver.
  • O SameSite=None; SameParty restringe a funcionalidade None apenas a contextos de mesma parte, quando houver suporte, mas volta às permissões None mais amplas se não houver.

Há alguns requisitos adicionais:

  • Os cookies SameParty precisam incluir Secure.
  • Os cookies SameParty não podem incluir SameSite=Strict.

O Secure é obrigatório, porque ainda é entre sites, e você precisa reduzir esses riscos garantindo conexões seguras (HTTPS). Da mesma forma, como essa é uma relação entre sites, SameSite=Strict é inválido, já que ainda permite proteção CSRF baseada em sites em um conjunto.

Quais são os casos de uso adequados para conjuntos próprios?

Os conjuntos primários 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. Identidade compartilhada, nesse caso, significa desde uma solução completa de login único até apenas precisar de uma preferência compartilhada entre sites.

Sua organização pode ter diferentes domínios de nível superior para:

  • Domínios do app: office.com,live.com, microsoft.com
  • Domínios de marca: amazon.com, audible.com / disney.com, pixar.com
  • Domínios específicos ao país 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 que existem por razões de segurança: googleusercontent.com, githubusercontent.com

Como você participa?

Se você tiver um conjunto de sites que atendam aos critérios acima, há várias opções para se envolver. O investimento mais leve é 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.

Você pode testar isso no site de demonstração em https://fps-member1.glitch.me/ depois de iniciar o Chrome com a seguinte flag:

--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 seu ambiente de desenvolvimento ou adicionar o atributo SameParty em um ambiente ativo para ver como um conjunto de primeira parte afeta os cookies.

Se você tiver a largura de banda para experimentar e dar feedback, também poderá se inscrever no teste de origem para sets próprios e SameParty, que está disponível no Chrome nas versões 89 a 93.

Como atualizar cookies para o teste de origem

Se você está participando do teste de origem e testando o atributo SameParty nos cookies, considere estes dois padrões.

Opção 1

Primeiro, onde você tem cookies rotulados como SameSite=None, mas 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 vai 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 exige mais trabalho, mas permite separar totalmente o teste de origem da funcionalidade atual e, especificamente, permite testar a combinação de 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 em solicitações de entrada, o cookie cname-fps só vai aparecer 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 você pode não precisar de um conjunto próprio?

Para a maioria dos sites, o limite do site é um lugar aceitável para desenhar a partição ou o limite de privacidade. Essa é a rota que está sendo proposta com CHIPS (Cookies Having Independent Partitioned State), que daria aos sites uma rota de ativação pelo atributo Partitioned para ainda ter esses recursos, APIs e serviços de incorporação entre sites, além de evitar o vazamento de informações de identificação entre sites.

Confira outras coisas que podem significar que seu site está funcionando bem sem precisar de um conjunto:

  • Você hospeda em origens diferentes, não em sites diferentes. No exemplo acima, se brandx.site tiver fly.brandx.site e drive.brandx.site, eles serão subdomínios diferentes no mesmo site. Os cookies podem usar SameSite=Lax, e não é necessário definir.
  • Você fornece incorporações de terceiros para outros sites. Na introdução, o exemplo de um vídeo de video.site incorporado em my-blog.site é uma clara divisão de terceiros. Os sites são operados por organizações diferentes, e os usuários os veem como entidades separadas. Esses dois sites não devem estar em um conjunto.
  • Você oferece serviços de login em redes sociais 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 próprios, porque há uma diferença clara nas organizações. Propostas iniciais, como o WebID, estão buscando maneiras de permitir esses casos de uso.