First-Party Sets

Permitir que nomes de domínio relacionados pertencentes e operados pela mesma entidade se declarem pertencentes à mesma fonte primária.

Published on Updated on

Translated to: English, Español, 한국어, 中文, Pусский, 日本語

Status de implementação

Por que precisamos de First-Party Sets?

As páginas da Web são compostas por conteúdo de várias origens. Parte do conteúdo é de fonte primária e vem do site de nível superior que o usuário está visitando. Outros conteúdos podem vir de terceiros, como anúncios, mídia incorporada ou recursos compartilhados, como bibliotecas JavaScript de CDNs. Terceiros também podem querer correlacionar a atividade do usuário em diferentes sites usando mecanismos como cookies.

Os navegadores estão propondo modelos de privacidade que restringem o acesso à identidade do usuário num contexto entre sites (cross-site). No entanto, muitas organizações têm sites relacionados com diferentes nomes de domínio, como domínios para diferentes países (example.com e example.co.uk, por exemplo). Deve ser possível permitir que nomes de domínio relacionados com uma relação apropriada, talvez que sejam parte de uma propriedade comum, se declarem como pertencentes à mesma fonte primária, de modo que os navegadores tratem esses domínios como fontes primárias em situações em que fontes primárias e a fontes terceiras sejam tratadas de maneira diferente.

Qualquer solução também precisaria evitar o abuso do sistema. Por exemplo, não deve ser possível declarar organizações que incluem sites não relacionados com proprietários diferentes, a fim de obter privilégios das fontes primárias.

Como funcionam os First-Party Sets?

Um site pode declarar que é membro (ou proprietário) de um conjunto de domínios da web servindo um arquivo de manifesto que define seu relacionamento com os outros domínios: um arquivo JSON em um endereço .well-known/first-party-set

Suponha que a.example , b.example e c.example desejam formar um First-Party Set que seja propriedade de a.example. Os sites serviriam então aos seguintes recursos:

// https://a.example/.well-known/first-party-set
{
"owner": "a.example",
"members": ["b.example", "c.example"],
...
}

// https://b.example/.well-known/first-party-set
{
"owner": "a.example"
}

// https://c.example/.well-known/first-party-set
{
"owner": "a.example"
}

O domínio proprietário hospeda um arquivo de manifesto que lista seus domínios membros. Um navegador pode pedir a um site membro para especificar seu proprietário e, em seguida, verificar o manifesto do proprietário para verificar o relacionamento.

Espera-se que as políticas do navegador evitem abusos ou uso indevido. Por exemplo, os First-Party Sets não devem permitir a troca de informações do usuário em sites não relacionados ou o agrupamento de sites que não sejam de propriedade da mesma entidade. Uma maneira possível de um site se registrar seria enviar seu grupo de domínios proposto a um rastreador público (como um repositório GitHub dedicado) junto com as informações necessárias para atender à política do navegador. A verificação do controle do proprietário sobre os domínios membros também pode exigir que um desafio seja servido numa URL .well-known em cada um dos domínios do conjunto.

A proposta complementar aos First-Party Sets é o atributo de cookie SameParty. Especificar o atributo SameParty num cookie instrui o navegador a incluir o cookie quando seu contexto fizer parte do mesmo First-Party Set que o contexto de nível superior.

Por exemplo, para o First-Party Set descrito acima, a.example pode definir o seguinte cookie:

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

Isso significa que quando um visitante em b.example ou c.example faz uma solicitação para a.example, o cookie session é incluído nessa solicitação.


Envolva-se e compartilhe feedback

Saiba mais

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.