This content is outdated and no longer accurate.

Esta página foi traduzida pela API Cloud Translation.

[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 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.

Diagrama mostrando um cookie de 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 de cookies é determinada pelo atributo SameSite do cookie:

Mesmo site contexto com SameSite=Lax, Strict ou None 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.

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 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.

Diagrama mostrando o estado não particionado em que o mesmo cookie de terceiros pode ser acessado 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 que impede a atividade de vinculação entre esses sites.

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.

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

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.

Diagrama mostrando que 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. Pense no SameParty como fornecer 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, mas recorre ao Lax. restrições.
SameSite=None; SameParty vai restringir a funcionalidade None 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 incluir Secure.
Os cookies SameParty não podem incluir SameSite=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.

Importante:o atributo SameParty afeta apenas os contextos em que um cookie possa ser enviado, ele não cria um cookie jar compartilhado. Um cookie de brandx.site está disponível apenas em solicitações ou documentos de brandx.site, o cookie nunca estará disponível diretamente para fly-brandx.site. Isso pode ser confuso, porque você pode ver isso referenciado como identidade compartilhada, mas isso significa que o limite flexível entre os locais permite definir ou enviar cookies em contextos entre sites e da mesma parte, sem incluir que os cookies sejam compartilhados diretamente.

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.

Observação:você pode identificar possíveis candidatos para esses casos de uso porque eles ser instâncias em que você já marcou um cookie como SameSite=None, mesmo que embora seja apenas para contextos entre sites em que você tem todos os sites envolvidos.

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:

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