Instructions pour le test des ensembles internes

La dernière version des ensembles internes est prête pour les tests des flags de fonctionnalités pour les développeurs depuis Chrome 108. Nous travaillons activement sur les ensembles internes dans le but de passer à la livraison. Nous tiendrons donc compte des commentaires pour cette phase de test pour les développeurs jusqu'à la sortie de Chrome 111 début mars (7 mars 2023).

Les commentaires sur l'écosystème mettent en évidence les 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 effectuer l'action appropriée pour le compte de l'utilisateur et/ou lui présenter efficacement cette information.

La nouvelle proposition utilise deux API (l'API Storage Access et une nouvelle API (provisoirement nommée requestStorageAccessForOrigin)) pour fournir aux sites une méthode active de demande d'accès intersites pour leurs cookies au sein d'un ensemble interne. Les instructions ci-dessous devraient vous permettre de tester et valider les ensembles que vous souhaitez créer pour vos sites, ainsi que les points 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. Les navigateurs peuvent ainsi utiliser ces informations pour autoriser un accès limité aux cookies intersites à des fins spécifiques et visibles par les utilisateurs. Chrome utilisera ces relations déclarées pour décider quand autoriser ou refuser l'accès des cookies à un site dans un contexte tiers.

De manière générale, un ensemble interne est un ensemble de domaines, pour lesquels il n'existe qu'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". sur "Définir comme principal". Les membres d'un ensemble peuvent inclure différents types de domaines avec des sous-ensembles en fonction des cas d'utilisation.

Pour faciliter le traitement de chaque sous-ensemble par le navigateur en fonction des implications de chacun en termes de confidentialité, nous proposons d'utiliser l'API Storage Access (SAA) et requestStorageAccessForOrigin pour activer l'accès aux cookies dans un FPS.

Avec cette fonctionnalité, les sites peuvent demander activement l'accès aux cookies intersites. Chrome accepte automatiquement la requête si le site à l'origine de la demande et le site Web de premier niveau se trouvent dans le même FPS. Veuillez consulter la documentation de l'API Storage Access (SAA) pour en savoir plus sur le traitement des appels à SAA 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 FPS pour les sites de premier niveau qui utilisent des images intersites ou des tags de script nécessitant des cookies. Pour répondre à 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 de FPS canonique est une liste consultable publiquement au format de fichier 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 pour l'envoi d'ensembles, consultez les consignes d'envoi. Vous pouvez également essayer d'envoyer un ensemble pour tester les différentes vérifications techniques qui valideront les envois. Notez que toutes les données envoyées seront effacées avant que le FPS ne soit disponible dans les versions stables de Chrome.

Le processus d'envoi des ensembles étant toujours en cours de développement, pour les tests en local, vous ne pouvez créer des ensembles que via la ligne de commande et 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 afin d'effectuer des tests avec les flags de fonctionnalité.

Effectuer un test en local

Prérequis

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

Pour avoir un aperçu des fonctionnalités à venir 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, comme expliqué dans cette section, et déclarer un ensemble de sites associés en tant qu'objet JSON à transmettre à --use-first-party-set.

Activer le FPS

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'il est appelé, 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 continue d'évoluer. Consultez cette page pour obtenir la liste des améliorations que nous prévoyons d'apporter à l'implémentation de la loi sur les services numériques dans Chrome.

StorageAccessAPIForOriginExtension

Permet aux sites de premier niveau d'utiliser requestStorageAccessForOrigin() pour demander l'accès à l'espace de stockage pour le compte d'origines spécifiques. Cette fonctionnalité est utile pour les sites de premier niveau qui utilisent des images intersites ou des balises de script nécessitant des cookies. Elle répond à certains des problèmes inhérents à l'adoption de l'approche SAA.

Déclarer un ensemble localement

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

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

Dans l'exemple ci-dessous, primary répertorie 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 pouvez uniquement créer des ensembles via la ligne de commande et les transmettre directement au navigateur. À des fins de tests en local, il n'y aura pas de validation définie, mais lorsque le FPS sera disponible en version stable, tous les ensembles devront être envoyés au dépôt GitHub du FPS et être soumis aux critères de validation.

Activer l'interface utilisateur du lecteur d'empreinte digitale

PageInfoCookiesSubpage

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

PrivacySandboxFirstPartySetsUI

Active l'interface utilisateur FPS "Autoriser les sites associés à voir votre activité dans le groupe" dans les paramètres 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 de 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é.
  3. Vérifiez que la sous-option "Autoriser les sites associés à voir votre activité dans le groupe" est également activé.

Considérations de 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, elle peut exposer les applications Web à des attaques intersites et à des fuites d'informations. Les sites qui s'appuient sur des cookies dans des contextes intersites doivent être conscients des risques liés à 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, afin de garantir une activation explicite de l'intégration. Les améliorations proposées voudraient: n'accorder l'accès qu'au cadre par image, exiger le CORS pour les requêtes authentifiées et conserver le champ d'application de l'accès uniquement à l'origine. 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'activité sur le Web et les applications dans Chrome.

Notez que Chrome n'envoie les cookies marqués SameSite=None que dans les 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, aucune hypothèse ne peut être faite quant à l'endroit où les cookies pourraient être utilisés. Il n'est pas prudent de supposer que l'accès ne serait autorisé qu'au sein d'un FPS, et les sites doivent continuer à appliquer les bonnes pratiques de sécurité standards.

Interagir et partager des commentaires

Les tests en local vous permettent d'essayer le mécanisme de l'API Storage Access permettant d'activer le FPS, et de nous faire part de vos commentaires ou des problèmes que vous rencontrez. En outre, en testant le processus d'envoi de l'ensemble sur GitHub, vous pouvez partager votre expérience concernant les étapes du processus et de validation. Pour répondre à la proposition mise à jour et nous faire part de vos commentaires: