Instructions pour le test des ensembles internes

La dernière itération des ensembles propriétaires est prête à être testée avec le flag de fonctionnalité pour les développeurs à partir de Chrome 108. Nous travaillons activement sur les ensembles propriétaires dans le but de les déployer. Nous tiendrons donc compte des commentaires pour cette phase de test destinée aux développeurs jusqu'à la sortie de Chrome 111 début mars (7 mars 2023).

Les commentaires de l'écosystème ont mis en évidence les cas d'utilisation intersites qui seront affectés lorsque les cookies tiers ne seront plus compatibles avec Chrome. La proposition d'ensembles propriétaires examine et traite une classe de cas d'utilisation intersites dans lesquels les sites interdépendants partagent une relation qui peut être exprimée auprès du navigateur afin que celui-ci puisse prendre les mesures appropriées au nom 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 provisoirement appelée requestStorageAccessForOrigin) pour fournir aux sites une méthode active de demande d'accès intersites pour leurs cookies dans un ensemble first party. Les instructions ci-dessous devraient vous permettre de tester et de 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 propriétaires

Les ensembles internes (FPS) sont un mécanisme de plate-forme Web permettant aux développeurs de déclarer des relations entre des sites. Les navigateurs peuvent ainsi utiliser ces informations pour activer un accès limité aux cookies intersites à des fins spécifiques destinées aux utilisateurs. Chrome utilisera ces relations déclarées pour décider quand autoriser ou refuser l'accès d'un site à ses cookies dans un contexte tiers.

De manière générale, un ensemble propriétaire 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 ajouter leurs domaines à un ensemble. Ils doivent déclarer la relation entre chaque "membre de l'ensemble" et son "principal de l'ensemble". Les membres d'un ensemble peuvent inclure différents types de domaines avec des sous-ensembles basés sur des cas d'utilisation.

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

Avec le SAA, les sites peuvent demander activement l'accès aux cookies intersites. Chrome accorde automatiquement la demande si le site à l'origine de la demande et le site Web racine se trouvent dans le même FPS. Pour en savoir plus sur le traitement des appels à l'API SAA par d'autres navigateurs, consultez la documentation de l'API Storage Access (SAA).

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

Cela peut rendre l'adoption du FPS difficile pour les sites de premier niveau qui utilisent des images intersites ou des balises de script nécessitant des cookies. Pour faire face à certains de ces défis, nous avons proposé une nouvelle API, requestStorageAccessForOrigin, afin de faciliter l'adoption de ce changement par les développeurs. Cette API est également disponible à des fins de test.

Définir l'envoi

La liste canonique des FPS sera une liste publique au format de fichier JSON hébergée dans un nouveau dépôt GitHub sur les FPS, qui servira de source de vérité 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 concernant 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 soumissions seront effacées avant que les FPS ne soient disponibles dans les versions stables de Chrome.

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

Tester en local

Prérequis

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

Pour tester les 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 les FPS localement, vous devez utiliser l'option --enable-features de Chrome avec une liste de paramètres 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 les FPS

FirstPartySets active les FPS dans Chrome.

FirstPartySets

Activer l'API Storage Access

StorageAccessAPI

Active l'API Storage Access (SAA) dans Chrome, qui permet aux iFrames intégrées 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 est encore en cours d'évolution. Consultez cette page pour obtenir la liste des améliorations prévues pour l'implémentation de la SAA dans Chrome.

StorageAccessAPIForOriginExtension

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

Déclarer un ensemble localement

Un ensemble interne est un ensemble de domaines pour lesquels il existe un seul "ensemble principal" et potentiellement plusieurs "ensembles membres". Les membres d'un ensemble peuvent inclure différents types de domaines avec des sous-ensembles basés sur des 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 liste 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. À des fins de test local, aucune validation de jeu de données ne sera effectuée. Toutefois, lorsque FPS sera disponible en versions stables, tous les jeux de données devront être envoyés au dépôt GitHub de FPS et être soumis à des critères de validation.

Activer l'UI FPS

PageInfoCookiesSubpage

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

PrivacySandboxFirstPartySetsUI

Active l'option "Autoriser les sites associés à voir votre activité dans le groupe" dans l'interface utilisateur FPS, 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", assurez-vous que l'option "Bloquer les cookies tiers" est activée.
  3. Vérifiez que l'option "Autoriser les sites associés à voir votre activité dans le groupe" est également activée.

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, les applications Web peuvent être exposées à 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 de CSRF et d'autres attaques.

Améliorations prévues

Pour améliorer ce point, les futures versions de Chrome nécessiteront des contrôles de sécurité supplémentaires, dans le but de garantir l'acceptation explicite de l'intégration. Les améliorations proposées consistent à n'accorder l'accès que par frame, à exiger CORS pour les requêtes authentifiées et à limiter l'étendue de l'accès à l'origine uniquement. Pour en savoir plus, consultez la dernière analyse de sécurité.

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

Notez que Chrome n'envoie des cookies marqués SameSite=None que dans les contextes intégrés intersites, ce qui est le cas pour l'API Storage Access. Toutefois, tant que tous les navigateurs n'auront pas abandonné l'accès par défaut à ces cookies, aucune hypothèse ne pourra être faite sur l'endroit où le cookie pourra être utilisé. Il n'est pas sûr de supposer que l'accès ne sera autorisé que dans un FPS. Les sites doivent continuer à suivre les bonnes pratiques de sécurité standards.

Interagir et envoyer des commentaires

Les tests locaux 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 défini sur GitHub vous permet de partager votre expérience du processus et des étapes de validation. Pour interagir et donner votre avis sur la proposition mise à jour: