Découvrez deux défis auxquels l'équipe Chrome a été confrontée lors de l'implémentation des CHIPS et comment les retours de la communauté ont joué un rôle clé pour faire évoluer la proposition de conception.
Cookies Having Independent Partitioned State (CHIPS) est une technologie Privacy Sandbox qui permet aux développeurs d'activer le stockage "partitionné" pour un cookie, avec des pots de cookies distincts par site racine.
Les exemples de cas d'utilisation des CHIPS incluent tous les scénarios où les sous-ressources intersites nécessitent une notion de session ou d'état persistant limitée à l'activité d'un utilisateur sur un seul site de niveau supérieur, tels que les widgets de chat tiers, les cartes intégrées, l'équilibrage de charge du CDN des sous-ressources, les fournisseurs de CMS headless, etc.
CHIPS est en cours de développement dans le but de devenir une norme Web ouverte. Il est en cours de discussion dans le PrivacyCG et a fait l'objet d'une phase d'évaluation en phase d'origine pendant sept mois, au cours de laquelle l'équipe Chrome a reçu des commentaires utiles. Au cours du développement, l'équipe a travaillé avec les principales personnes concernées pour examiner ces commentaires. Elle a ainsi abouti à une conception mise à jour qui répond mieux aux besoins de l'écosystème Web.
Découvrons deux défis auxquels l'équipe Chrome a été confrontée lors de l'implémentation des CHIPS et comment les retours de la communauté ont joué un rôle clé pour faire évoluer la proposition de conception.
Suppression du préfixe hôte et aucune exigence Domain
Pour encourager de bonnes pratiques de sécurité, la conception CHIPS exige que les cookies ne soient définis et envoyés que via des protocoles sécurisés, et que les cookies partitionnés doivent être définis avec Secure.
En plus de ces exigences, la proposition initiale interdisait l'attribut Domain sur les cookies partitionnés. L'omission de Domain sur les cookies empêchait leur partage entre différents sous-domaines tiers d'une partition.
Lors de la phase d'évaluation de l'origine, l'équipe Chrome a reçu des commentaires de partenaires et d'autres personnes concernées indiquant que l'absence de domaine rendait l'implémentation de CHIPS difficile pour les sites avec des sous-domaines. Par exemple, il serait plus difficile pour shop.example.com et pay.example.com de partager des pots de biscuits partitionnés. Dans d'autres cas, cela a rendu les flux d'authentification difficiles dans les contextes intégrés.
L'équipe Chrome a évalué ces commentaires et a conclu que la suppression de l'exigence de non-domaine ne poserait pas de problème de confidentialité, mais améliorerait l'usabilité. En réponse, l'équipe produit CHIPS a lancé une discussion sur GitHub, invitant les utilisateurs à envoyer des commentaires sur la suppression de cette exigence. Plusieurs entreprises qui testaient CHIPS ont répondu et commenté publiquement l'importance de ce changement pour leur cas d'utilisation.
Chrome a transmis les commentaires au groupe de la communauté sur la confidentialité du W3C et présenté la proposition mise à jour. Firefox et Edge ont approuvé le changement, et Safari n'a soulevé aucune inquiétude. Le jour suivant, l'équipe Chrome a mis à jour Blink-Dev et présenté le plan de suppression de l'exigence dans le dépôt GitHub CHIPS.
L'équipe CHIPS a initialement proposé cette exigence pour garantir que les sites ne reçoivent pas de cookies intersites provenant de sous-domaines malveillants ou compromis, et pour réduire la possibilité d'utiliser les cookies de domaine comme canal de fuite de données entre les sous-domaines.
Bien que cela présente des avantages supplémentaires en termes de sécurité, Tableau a souligné que cela présentait des difficultés pour l'adoption de CHIPS, car certaines architectures d'applications actuelles reposent sur le partage de cookies entre les sous-domaines.
Après ce changement, Tableau, l'entreprise à l'origine de la plate-forme d'analyse visuelle désormais détenue par Salesforce, a indiqué:
Cette suppression de la modification de dénomination rend l'exigence beaucoup plus conforme aux modifications précédentes visant à ajouter l'attribut "SameSite=None", et donc une quantité plus "connue". Nous sommes reconnaissants à Google d'avoir pris en compte les commentaires, d'avoir examiné les conséquences et d'avoir apporté cette modification pour faciliter la transition. Lee Graber, architecte en ingénierie logicielle, Tableau
Grâce à ce processus, CHIPS a été simplifié pour les personnes concernées, tout en préservant la confidentialité des utilisateurs.
Passer d'une limite de cookies statique à une limite dynamique
L'autre défi de l'implémentation de CHIPS était la limite de cookies statiques.
Pour éviter une empreinte mémoire importante pour les cookies, la conception initiale proposait une limite numérique de 10 cookies par site et par partition.
Akamai a partagé des commentaires publics indiquant que la limite proposée pour les cookies partitionnés pourrait ne pas être suffisante pour des services tels que les CDN qui proposent des domaines de premier niveau pour héberger le contenu de leurs clients (par exemple, customer.cdn.xyz). Par exemple, customer1.cdn.xyz et customer2.cdn.xyz peuvent tous deux diffuser du contenu tiers et chacun peut définir plusieurs de ses propres cookies. Si plusieurs sites client de ce type sont intégrés à un autre site Web, ils peuvent atteindre la limite de 10 cookies par partition.
L'équipe Chrome a reçu des commentaires similaires sur d'autres forums, lors de réunions avec des partenaires et lors de discussions au W3C. Elle a donc réfléchi aux meilleures façons de résoudre le problème posé par la limite de cookies dans ces cas d'utilisation.
Après avoir réfléchi à la manière d'intégrer les commentaires de la communauté, Chrome a présenté une idée mise à jour lors du TPAC 2022, suggérant que CHIPS passe d'une limite de 10 cookies statique à une limite _dynamique_ de 10 ko basée sur la mémoire. L'analyse a montré que ce changement devrait couvrir 99% des cas d'utilisation sur le Web et respecter les principes de confidentialité que Chrome essayait d'atteindre (en limitant les informations partagées sur les utilisateurs entre les sites), tout en conservant les utilisations clés.
D'autres fournisseurs de navigateurs ont donné leur avis, indiquant qu'ils étaient d'accord avec la solution mise à jour, ce qui était important pour s'assurer que CHIPS conservait la compatibilité multinavigateur dans le PrivacyCG.
Par conséquent, Chrome a adopté la nouvelle limite et intégré la solution à la conception CHIPS.
Travailler avec le secteur
Nous avons échangé avec de nombreux partenaires tout au long du développement de CHIPS. Notre collaboration a été essentielle pour améliorer la confidentialité sur le Web.
Akamai entretient une relation de coopération sur plusieurs fronts avec d'autres leaders du secteur, comme Google. Les commentaires que nous avons fournis dans le cas du programme CHIPS peuvent sembler être un détail mineur, mais ce changement permettra de limiter l'impact négatif sur les bons cas d'utilisation, tout en atteignant l'objectif final. Nos organisations respectives s'efforcent de rendre Internet plus rapide et plus sécurisé à leur manière. Nous sommes convaincus que l'ensemble d'Internet est mieux loti lorsque nous collaborons. Martin Meyer, architecte principal chez Akamai Technologies
CHIPS a démontré que les commentaires de l'écosystème sont essentiels pour améliorer les technologies de la Privacy Sandbox. Les conversations ouvertes sur le Web dans GitHub, les réunions du W3C et l'engagement continu avec l'équipe Chrome ont directement contribué aux modifications qui ont maintenant été déployées dans Chrome stable. L'équipe Chrome est impatiente de recevoir ces commentaires sur un large éventail de propositions. Ils ont un impact considérable sur la façon dont les technologies sont développées et déployées sur le Web.