This content is outdated and no longer accurate.

Cette page a été traduite par l'API Cloud Translation.

[OBSOLÈTE] Ensembles internes et attribut SameParty

De nombreuses organisations ont des sites connexes avec des noms de domaine différents, tels que brandx.site et fly-brandx.site) ou des domaines pour différents pays, tels que example.com, example.rs, example.co.uk, etc.

Les navigateurs se tournent progressivement vers la création de cookies tiers obsolète pour améliorer la confidentialité sur le Web. Or, ce type de site utilise souvent des cookies qui nécessitent de maintenir l'état et d'y accéder sur plusieurs domaines (authentification unique et gestion du consentement, par exemple).

Les ensembles internes peuvent autoriser des noms de domaine associés détenus et gérés par la même entité soit traitée comme propriétaire dans les cas où les données first party et tiers sont traités différemment. Les noms de domaine d'une sont considérés comme des tiers et peuvent identifier les cookies destinés à être définis ou envoyés dans un contexte de la même partie. L'objectif est de trouver trouver un juste équilibre entre la prévention du suivi intersites par des tiers, et conserver un chemin qui ne casse pas les cas d'utilisation valides.

La proposition d'ensembles internes est actuellement en phase de test , poursuivez votre lecture pour découvrir son fonctionnement. et comment l'essayer.

Quelle est la différence entre les cookies propriétaires et les cookies tiers ?

Les cookies ne sont pas intrinsèquement des propriétaires ou des tiers : cela dépend le contexte dans lequel le cookie est inclus. Pour cela, il suffit d'envoyer une demande cookie ou via document.cookie en JavaScript.

Par exemple, si video.site a un cookie theme=dark, lorsque vous naviguez video.site et une requête est envoyée à video.site, qui est un même site le contexte et qui est inclus est un cookie propriétaire.

Cependant, si vous utilisez my-blog.site qui intègre un lecteur iFrame pour video.site, lorsque la requête est envoyée de my-blog.site à video.site il s'agit d'un contexte intersites et le cookie theme est tiers.

Schéma illustrant un cookie de video.site dans deux contextes. Le cookie est SameSite lorsque le contexte de premier niveau est aussi video.site. Le cookie est intersite lorsque le contexte de premier niveau est mon-blog.site avec video.site dans un iFrame.

L'inclusion d'un cookie est déterminée par l'attribut SameSite du cookie:

Même site le contexte avec Avec SameSite=Lax, Strict ou None, le cookie devient propriétaire.
Le contexte intersites avec SameSite=None rend le cookie tiers.

Cependant, ce n’est pas toujours aussi évident. Imaginez que brandx.site est un voyage site de réservation. Elle utilise aussi fly-brandx.site et drive-brandx.site pour vols et location de voitures distincts. Au cours d'une réservation, les visiteurs passent d'un site à l'autre pour sélectionner leurs options. Ils s'attendent à "panier" de sélections pour conserver l'ensemble de ces sites. brandx.site gère la session de l'utilisateur avec un cookie SameSite=None pour l'autoriser intersites. L'inconvénient, cependant, est que les cookies Demande de protection contre la falsification (CSRF) Si evil.site inclut une demande à brandx.site, ce cookie sera inclus !

Le cookie est intersite, mais tous ces sites sont détenus et gérés par le même organisation. Les visiteurs comprennent aussi qu'il s'agit de la même organisation et veulent que même session, en d'autres termes, une identité partagée entre eux.

Diagramme illustrant comment un cookie peut toujours être inclus dans un contexte intersites si les sites font partie du même ensemble interne, mais qu'il serait refusé en cas de contextes intersites en dehors de l'ensemble.

Règlement sur les ensembles internes

Les ensembles internes proposent permettant de définir explicitement cette relation entre plusieurs sites sont détenues et gérées par la même partie. Cela permettrait à brandx.site de définir sa relation propriétaire avec fly-brandx.site ; drive-brandx.site, etc.

Le modèle de confidentialité à l'origine les différentes propositions de la Privacy Sandbox s'appuient sur le concept de partitionnement pour empêcher le suivi intersites, en dessinant une limite entre les sites limite l'accès à toute information permettant d'identifier les utilisateurs.

Schéma illustrant l'état non partitionné où le même cookie tiers est accessible dans plusieurs contextes intersites, par opposition à un modèle partitionné où chaque contexte de niveau supérieur possède une instance distincte du cookie intersites empêchant l'activité d'association sur ces sites.

L'option par défaut consiste à partitionner les données par site, ce qui résout de nombreux des cas d'utilisation, l'exemple brandx.site montre qu'une propriété qu'un seul site.

Diagramme illustrant comment la même instance de cookie pour un ensemble peut être incluse dans des contextes intersites lorsque tous ces sites font partie du même ensemble.

Une partie importante de la proposition concernant les ensembles internes consiste à s'assurer que les règles entre les navigateurs empêche toute utilisation abusive. Par exemple, les ensembles internes ne doivent pas permettent l'échange d'informations sur les utilisateurs entre des sites sans rapport de sites n'appartenant pas à la même entité. L'idée est de s'assurer qu'un L'ensemble interne correspond à un élément qu'une personne comprend comme étant propriétaire et non comme un moyen de partager l'identité entre différentes parties.

Pour un site, il est possible d'enregistrer un ensemble propriétaire : de soumettre le groupe de domaines proposé à un outil de suivi public (tel qu'un dépôt GitHub dédié), ainsi que les informations nécessaires pour satisfaire aux exigences du navigateur .

Une fois que l'assertion de l'ensemble propriétaire a été validée conformément à la stratégie, les navigateurs peuvent puis récupérer des listes d'ensembles via un processus de mise à jour.

La phase d'évaluation est assortie d'une règle définie qui n'est pas définitive, mais les principes sont est susceptible de rester la même:

Les domaines d'un ensemble propriétaire doivent être détenus et gérés par le même organisation.
Les domaines doivent être reconnaissables par l'ensemble des utilisateurs.
Les domaines doivent partager des règles de confidentialité communes.

Définir un ensemble propriétaire

Une fois que vous avez identifié les membres et le propriétaire il est crucial de soumettre votre proposition pour approbation. Le mot clé exact est encore en cours de discussion.

Pour déclarer un ensemble propriétaire, des ressources JSON statiques répertoriant les membres et les propriétaires doit être hébergé sur /.well-known/first-party-set au premier niveau de chaque domaine inclus.

Dans l'exemple d'ensemble propriétaire brandx, "owner-domain" héberge le suivi sur https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Chaque membre de l'ensemble héberge également une ressource JSON statique pointant vers le propriétaire de l'ensemble. Voici ce que propose https://fly-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Et sur https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Quelques contraintes s'appliquent aux ensembles propriétaires:

Un ensemble ne peut avoir qu'un seul propriétaire.
Un membre ne peut appartenir qu'à un seul ensemble, sans chevauchement ni combinaison.
La liste des membres est destinée à rester lisible par l'humain et ne doit pas trop volumineux.

Comment les ensembles internes affectent-ils les cookies ?

L'ingrédient correspondant pour les cookies est le SameParty . Spécifier SameParty indique au navigateur d'inclure le cookie lorsque son contexte fait partie du même comme contexte de premier niveau.

Cela signifie que si brandx.site définit ce cookie:

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

Ensuite, lorsque le visiteur est sur fly-brandx.site et qu'une requête est transmise à brandx.site, le cookie session sera inclus dans cette requête. Si un autre site ne fait pas partie de l'ensemble propriétaire, par exemple hotel.xyz envoie une requête à brandx.site, le cookie n'est pas inclus.

Schéma illustrant le cookie brandx.site autorisé ou bloqué dans des contextes intersites, comme décrit dans la description

En attendant que SameParty soit largement pris en charge, utilisez l'attribut SameSite avec lui pour définir le comportement de remplacement pour les cookies. Vous pouvez penser à SameParty comme une valeur comprise entre SameSite=Lax et SameSite=None

SameSite=Lax; SameParty étendra la fonctionnalité Lax à incluent des contextes tiers lorsqu'ils sont pris en charge, mais en recourant à la Lax si ce n'est pas le cas.
SameSite=None; SameParty limitera la fonctionnalité None aux uniquement avec des contextes tiers lorsqu'ils sont pris en charge, None si ce n'est pas le cas.

Des conditions supplémentaires s'appliquent:

Les cookies SameParty doivent inclure Secure.
Les cookies SameParty ne doivent pas inclure SameSite=Strict.

Secure est obligatoire, car il s'agit toujours d'un site intersites. Vous devez limiter ces risques en assurant des connexions (HTTPS) sécurisées. De même, comme il s'agit relation intersite, SameSite=Strict n'est pas valide car il autorise toujours une protection CSRF étroitement basée sur le site dans un ensemble.

Important:L'attribut SameParty n'affecte que les contextes dans lesquels un élément peut être envoyé, mais ne crée pas de "jardin de cookies partagé". Un cookie provenant de brandx.site est uniquement disponible sur les demandes ou les documents pour brandx.site, le cookie n'est jamais directement disponible pour fly-brandx.site Cela peut être déroutant, car vous pouvez voir qu’il s’agit une identité partagée, mais cela signifie que la limite assouplie entre les sites leur permet de définir ou d'envoyer des cookies dans des contextes intersites ou tiers, et non que les cookies sont partagés directement.

Quels cas d'utilisation sont appropriés pour les ensembles internes ?

Les ensembles internes conviennent aux cas où une entreprise a besoin une identité partagée entre différents sites de premier niveau. Identité partagée dans ce cas qu'il s'agisse d'une solution complète d'authentification unique ou d'un simple accès la préférence sur tous les sites.

Remarque:Vous pouvez identifier des candidats potentiels pour ces cas d'utilisation, car ils que vous ayez déjà marqué un cookie comme SameSite=None bien qu'elle ne soit destinée qu'aux contextes intersites où vous êtes propriétaire de l'ensemble des sites concernés.

Votre organisation peut disposer de différents domaines de premier niveau pour:

Domaines d'application: office.com,live.com, microsoft.com
Domaines associés à une marque: amazon.com, audible.com / disney.com, pixar.com
Domaines propres à un pays où activer la localisation: google.co.in, google.co.uk
Domaines de service avec lesquels les utilisateurs n'interagissent jamais directement, mais qui sont fournis sur les sites de la même organisation: gstatic.com, githubassets.com fbcdn.net
Des domaines de bac à sable avec lesquels les utilisateurs n'interagissent jamais directement, mais pour lesquels ils existent raisons de sécurité: googleusercontent.com, githubusercontent.com

Comment participer ?

Si vous disposez d'un ensemble de sites qui correspond aux critères ci-dessus, il existe un un certain nombre d'options pour s'impliquer. L'investissement le plus simple consiste à lire et rejoindre la discussion sur les deux propositions:

Pendant la phase de test, vous pouvez tester la fonctionnalité à l'aide de la l'option de ligne de commande --use-first-party-set et en fournissant une liste de valeurs séparées par des virgules ; de sites.

Vous pouvez l'essayer sur le site de démonstration à l'adresse https://fps-member1.glitch.me/ après le Chrome avec l'indicateur suivant:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Cette fonctionnalité est utile si vous souhaitez effectuer des tests dans votre environnement de développement ou essayez d'ajouter l'attribut SameParty dans un environnement en ligne pour voir l'ensemble propriétaire aurait une incidence sur les cookies.

Si vous avez assez de temps pour effectuer des tests et obtenir des retours, vous pouvez également vous inscrire de la phase d'évaluation pour les ensembles internes SameParty disponible dans Chrome de la version 89 à la version 93.

Mettre à jour les cookies pour la phase d'évaluation

Si vous participez à la phase d'évaluation et que vous testez l'attribut SameParty sur vos cookies, voici deux modèles à prendre en compte.

Option 1

Tout d'abord, il y a des cookies que vous avez étiquetés SameSite=None, si vous souhaitez vous limiter aux contextes propriétaires, vous pouvez ajouter SameParty leur attribuer. Dans les navigateurs où la phase d'évaluation est active, le cookie ne pas être envoyées dans des contextes intersites en dehors de l'ensemble.

Cependant, pour la majorité des en dehors de la phase d'évaluation, le cookie continuera d'être envoyé intersites comme d'habitude. Considérez cela comme une approche d'amélioration progressive.

Avant: set-cookie: cname=cval; SameSite=None; Secure

Après: set-cookie: cname=cval; SameSite=None; Secure; SameParty

Option 2

La deuxième option est plus fastidieuse, mais vous permet de séparer complètement l'origine à partir de fonctionnalités existantes et permet spécifiquement de tester SameSite=Lax; SameParty.

Avant: set-cookie: cname=cval; SameSite=None; Secure

Après :

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Lorsque vous vérifiez le cookie dans les requêtes entrantes, attendez-vous à voir le cookie cname-fps dans une requête intersites si les sites concernés sont inclus dans le et que le navigateur est en phase d'évaluation. Considérez cette approche comme une une fonctionnalité mise à jour simultanément avant de désactiver version.

Pourquoi n'avez-vous pas besoin d'un ensemble propriétaire ?

Pour la plupart des sites, les limites constituent un endroit acceptable pour de partition ou de confidentialité. Il s'agit de l'itinéraire proposé Les cookies ayant une partition indépendante (CHIPS) l'état), ce qui donnerait aux sites la possibilité d'activer via l'attribut Partitioned pour conserver ces images critiques les intégrations, les ressources, les API et les services, tout en évitant les fuites d'identification des informations sur les sites.

Voici d'autres éléments à prendre en compte : votre site peut fonctionner correctement sans nécessiter un ensemble:

Vous hébergez des sites d'origines différentes, et non des sites différents. Dans l'exemple ci-dessus, si brandx.site avait fly.brandx.site et drive.brandx.site, alors ces sont des sous-domaines différents sur le même site. Les cookies peuvent utiliser SameSite=Lax et aucun ensemble n'est nécessaire.
Vous fournissez des intégrations tierces sur d'autres sites. Dans l'introduction, l'exemple de une vidéo de video.site intégrée à my-blog.site est clairement un tiers diviser. Les sites sont gérés par différentes organisations et les utilisateurs les voient en tant qu'entités distinctes. Ces deux sites ne doivent pas faire partie d'un ensemble.
Vous fournissez des services de connexion aux réseaux sociaux tiers. Les fournisseurs d'identité utilisant des outils comme OAuth ou OpenId Connect s'appuient souvent sur des cookies tiers une expérience de connexion plus fluide pour les utilisateurs. C'est un cas d'utilisation valide, pour les ensembles internes, car il existe des différences nettes entre les organisations. Les premières propositions, telles que WebID, sont et examiner les moyens d'activer ces cas d'utilisation.