Instructions pour le test des ensembles internes

La dernière version des ensembles internes est prête à être testée pour les flags de fonctionnalités des développeurs à partir de Chrome 108. Nous travaillons activement sur les ensembles internes dans le but de passer à la livraison. C'est pourquoi nous tenons compte de vos commentaires sur cette phase de test des développeurs jusqu'à la sortie de Chrome 111 au début du mois de mars (7 mars 2023).

Les commentaires sur les écosystèmes ont mis en évidence des cas d'utilisation intersites qui seront affectés lorsque les cookies tiers ne seront plus acceptés dans Chrome. La proposition d'ensembles internes examine et traite une catégorie de cas d'utilisation intersites dans lesquels les sites interdépendants partagent une relation qui peut être exprimée avec le navigateur, de sorte que celui-ci puisse prendre les mesures appropriées pour le compte de l'utilisateur et/ou présenter efficacement ces informations à l'utilisateur.

La proposition mise à jour utilise deux API (l'API Storage Access et une nouvelle API nommée provisoirement requestStorageAccessForOrigin) pour fournir aux sites une méthode active de demande d'accès intersites pour leurs cookies dans un ensemble interne. Les instructions ci-dessous devraient vous permettre de tester et de valider les ensembles que vous pourriez vouloir créer pour vos sites, ainsi que les points d'accès appropriés pour appeler les deux API différentes.

Présentation des ensembles internes

Les ensembles internes (FPS) sont un mécanisme de plate-forme Web permettant aux développeurs de déclarer des relations entre les sites, afin que les navigateurs puissent utiliser ces informations pour limiter l'accès des cookies intersites à des fins spécifiques et visibles par l'utilisateur. Chrome utilisera ces relations déclarées pour décider quand autoriser ou refuser un site à accéder à ses cookies dans un contexte tiers.

De manière générale, un ensemble interne est un ensemble de domaines, pour lesquels il existe un seul "ensemble principal" et potentiellement plusieurs "membres de l'ensemble". Seuls les auteurs de sites peuvent soumettre leurs domaines à un ensemble, et ils devront déclarer la relation entre chaque "membre de l'ensemble" et son "ensemble principal". Les membres des ensembles peuvent inclure différents types de domaines avec des sous-ensembles basés sur les cas d'utilisation.

Pour faciliter le traitement par le navigateur de chaque sous-ensemble en fonction de ses implications sur la confidentialité, nous vous proposons d'exploiter l'API Storage Access (SAA) et requestStorageAccessForOrigin pour autoriser l'accès aux cookies au sein d'un FPS.

Dans le cadre de ce programme, les sites peuvent demander activement l'accès aux cookies intersites. Chrome accepte automatiquement la demande si le site à l'origine de la demande et le site Web de premier niveau sont dans le même FPS. Veuillez consulter la documentation de l'API Storage Access (SAA) pour savoir comment les appels à cette API sont traités par d'autres navigateurs.

Actuellement, SAA exige que le document obtienne l'activation de l'utilisateur avant d'appeler les méthodes de l'API.

Cela peut compliquer l'adoption du lecteur d'empreinte digitale pour les sites de premier niveau qui utilisent des images intersites ou des tags de script nécessitant des cookies. Pour relever certains de ces défis, nous avons proposé une nouvelle API, requestStorageAccessForOrigin, afin de permettre aux développeurs d'adopter plus facilement ce changement. Cette API est également disponible à des fins de test.

Définir l'envoi

La liste canonique de FPS sera accessible au public au format JSON, hébergée dans un nouveau dépôt GitHub FPS, qui servira de source de référence pour tous les ensembles. Chrome utilisera ce fichier pour appliquer son comportement.

Pour en savoir plus sur la procédure proposée et les exigences liées à l'envoi d'ensembles, consultez les consignes d'envoi. Vous pouvez également essayer de soumettre un ensemble pour tester les différents contrôles techniques qui valideront les envois. Notez que tous les envois seront supprimés avant que le lecteur d'empreinte digitale ne soit disponible dans les versions stables de Chrome.

Le processus d'envoi des ensembles étant toujours en cours de développement, vous ne pouvez créer des ensembles que via la ligne de commande pour les tests en local, puis les transmettre directement au navigateur. Pour les tests en local, il n'est pas nécessaire d'envoyer un ensemble au dépôt GitHub pour effectuer des tests avec des flags de fonctionnalité.

Tester en local

Prérequis

Pour tester le FPS en local, utilisez Chrome 108 ou une version ultérieure, lancé à partir de la ligne de commande.

Pour avoir un aperçu des futures fonctionnalités de Chrome avant leur sortie, téléchargez la version bêta ou Canary de Chrome.

Exemple

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Découvrez comment exécuter Chromium avec des indicateurs.

Étapes

Pour activer le FPS en local, vous devez utiliser l'option --enable-features de Chrome avec une liste d'indicateurs séparés par une virgule expliqués dans cette section, et déclarer un ensemble de sites associés en tant qu'objet JSON à transmettre à --use-first-party-set.

Activer le lecteur d'empreinte digitale

FirstPartySets active le FPS dans Chrome.

FirstPartySets

Activer l'API Storage Access

StorageAccessAPI

Active l'API Storage Access (SAA) dans Chrome, qui permet aux iFrames intégrés d'utiliser requestStorageAccess() pour demander l'accès aux cookies dans un contexte intersites, même lorsque les cookies tiers sont bloqués par le navigateur.

Notez que lorsqu'elle est appelée, requestStorageAccess() nécessite un geste de l'utilisateur pour être résolu. Les futures versions de Chrome peuvent imposer différents ensembles d'exigences, car la spécification SAA est encore en pleine évolution. Cliquez ici pour obtenir la liste des améliorations prévues pour l'implémentation de l'application SAA dans Chrome.

StorageAccessAPIForOriginExtension

Permet aux sites de premier niveau d'utiliser requestStorageAccessForOrigin() pour demander l'accès à l'espace de stockage au nom d'origines spécifiques. Cette fonctionnalité est utile pour les sites de premier niveau qui utilisent des images intersites ou des tags de script nécessitant des cookies, et qui répond à certains des défis liés à l'adoption de l'approche SAA.

Déclarer un ensemble localement

Un ensemble interne est un ensemble de domaines, pour lesquels il n'y a qu'un seul "ensemble principal" et potentiellement plusieurs "membres de l'ensemble". Les membres des ensembles peuvent inclure différents types de domaines avec des sous-ensembles basés sur les cas d'utilisation.

Créez un objet JSON contenant des URL membres d'un ensemble et transmettez-le à --use-first-party-set.

Dans l'exemple ci-dessous, primary liste le domaine principal et associatedSites répertorie les domaines qui répondent aux exigences du sous-ensemble associé.

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Exemple :

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

Pour les tests en local, vous ne pouvez créer des ensembles que sur la ligne de commande et les transmettre directement au navigateur. Pour les tests en local, il n'y aura pas de validation définie. Toutefois, lorsque le lecteur d'empreinte digitale est fourni dans des versions stables, tous les ensembles doivent être envoyés au dépôt GitHub du lecteur d'empreinte digitale et être soumis aux critères de validation.

Activer l'UI du lecteur d'empreinte digitale

PageInfoCookiesSubpage

Active l'affichage des FPS dans la section "PageInfo" accessible depuis la barre d'adresse.

PrivacySandboxFirstPartySetsUI

Active l'option "Autoriser les sites associés à voir votre activité dans le groupe" dans les paramètres de Chrome, sous Confidentialité et sécurité → Cookies et autres données des sites (chrome://settings/cookies).

Vérifier que les cookies tiers sont bloqués

  1. Dans les paramètres Chrome, accédez à Confidentialité et sécurité → Cookies et autres données des sites ou chrome://settings/cookies.
  2. Sous "Paramètres généraux", vérifiez que l'option "Bloquer les cookies tiers" est activée.
  3. Vérifiez que la sous-option "Autoriser les sites associés à voir votre activité dans le groupe" est également activée.

Points à noter concernant la sécurité

Étant donné que l'API Storage Access permet aux sites Web de récupérer l'accès aux cookies tiers dans certains cas, les applications Web peuvent être sujettes aux attaques intersites et aux fuites d'informations. Les sites qui s'appuient sur des cookies dans des contextes intersites doivent être conscients des risques liés aux attaques CSRF et à d'autres attaques.

Améliorations prévues

Pour améliorer cela, les futures versions de Chrome nécessiteront des contrôles de sécurité supplémentaires. L'objectif est de garantir une activation explicite de l'intégration. Les améliorations proposées devraient: n'accorder l'accès qu'au niveau de chaque frame, exiger le CORS pour les requêtes avec identifiant et conserver le champ d'application de l'accès à l'origine uniquement. Pour en savoir plus, consultez l'analyse de sécurité récente.

Consultez la liste des améliorations prévues pour l'implémentation de l'application SAA dans Chrome.

Notez que Chrome n'envoie des cookies marqués SameSite=None que dans des contextes intégrés intersites. C'est là que l'API Storage Access est pertinente. Toutefois, tant que tous les navigateurs n'ont pas abandonné l'accès par défaut à ces cookies, il est impossible de savoir où les cookies pourraient être utilisés. Il n'est pas prudent de supposer que l'accès ne serait autorisé qu'avec un FPS et que les sites doivent continuer à appliquer les bonnes pratiques de sécurité standards.

Interagir et donner votre avis

Les tests en local vous permettent de tester le mécanisme de l'API Storage Access pour activer les FPS, et de partager vos commentaires ou les problèmes que vous rencontrez. De plus, tester le processus d'envoi de set sur GitHub est l'occasion de partager votre expérience du processus et des étapes de validation. Pour discuter de la proposition modifiée et donner votre avis: