Chrome 115 signe le lancement de la Privacy Sandbox, qui débutera le 24 juillet

Cookies sans sucre

Chrome 115 signe le lancement de la Privacy Sandbox, qui débutera le 24 juillet

Chrome 115 signe le lancement de la Privacy Sandbox, qui débutera le 24 juillet

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

La dernière révision stable de Chrome, estampillée 115, comporte une nouveauté qui entrera en vigueur la semaine prochaine pour un premier lot d’utilisateurs : Privacy Sandbox. L’occasion de rappeler comment fonctionne ce mécanisme censé améliorer la vie privée autour de la publicité ciblée.

Chrome 115 vient tout juste de sortir. Sous le capot, essentiellement des corrections de bugs et de failles de sécurité, ainsi que des améliorations pour les développeurs. Mais son vrai intérêt réside dans la Privacy Sandbox, prête pour le grand saut après des années de préparation.

Le mécanisme a été annoncé pour la première fois en 2019. Il était présenté comme une alternative à FLoC, qui avait rencontré – c’est peu de le dire – une intense vague de scepticisme. Google, dont plus de 90 % du chiffre d’affaires proviennent de la publicité ciblée, mettrait en place un processus permettant de limiter le pistage, donc le nombre d’informations personnelles captées au cours de la navigation ?

La nouvelle mouture du navigateur marque le réel coup d’envoi de cette technologie, sur laquelle nous allons revenir. Le déploiement va être progressif, mais relativement rapide. Le 24 juillet, date du début du déploiement, 35 % des utilisateurs auront la Privacy Sandbox active. Entre début et mi-août, le chiffre passera à 60 %. Durant la deuxième moitié d’août, 99 % des utilisateurs devraient avoir le mécanisme actif. Google précise que ce déploiement se poursuivra à travers les versions 116 et 117, l’effort se concentrant ensuite sur les « groupes isolés ».

Chrome Privacy Sandbox

En ligne de mire, ce n’est rien de moins que la fin programmée des cookies tiers. Début 2024, ces cookies seront désactivés pour 1 % des utilisateurs de Chrome. Une petite proportion qui va rapidement grandir, puisque la totalité des internautes concernés verront cette coupure se produire durant le premier semestre. Dans la foulée, l’identifiant publicitaire sera, lui aussi, supprimé.

Quels changements pour l’utilisateur ? Visuellement aucun, la bascule sera transparente. En revanche, l’arrivée de la Privacy Sandbox s’accompagnera de plusieurs réglages possibles dans les paramètres de Chrome.

« Avec les essais Privacy Sandbox, les sites peuvent offrir la même expérience de navigation en utilisant moins de vos infos. Cela signifie plus de confidentialité pour vous et moins de suivi intersites », vante Google

Privacy Sandbox, c’est quoi ?

Le grand objectif de ce mécanisme est de parvenir à envoyer des données aux annonceurs, sans qu’elles permettent de reconstituer l’identité d’une personne. Plutôt qu’un suivi individuel, les utilisateurs sont répartis au sein de grands groupes constitués selon des centres d’intérêts, eux-mêmes déterminés en fonction de l’historique. Dans le processus, la quantité de données partagées est moindre. Elles ne permettent, en théorie, d’identifier les personnes. Enfin, dernier grand principe, les informations sont stockées sur les appareils, et non collectées par les serveurs.

Dans ce modèle, le code lié aux publicités est séparé du reste du site ou de l’application (dans le cas d’Android, où plus de 90 % des applications sont gratuites). Cette exécution séparée se fait avec des droits moindres et des accès contrôlés.

Les développeurs vont avoir le temps de se préparer, car le fonctionnement classique par cookies va rester accessible tant que leur accessibilité sera garantie par Google dans Chrome. Dans l’interlude qui va commencer le 24 juillet, ils devront cependant se pencher sur les nouvelles API, notamment les trois principales :

  • Topics : catégorisation des intérêts des internautes en fonction de l’historique de navigation
  • Attribution Reporting : API capable de mesurer quand les clics et vues d’une publicité mènent à une conversion, c’est-à-dire une action d’achat ou d’engagement autre
  • Protected Audience (précédemment FLEDGE) : permet l’affichage de publicités pertinentes en fonction des interactions passées avec l’annonceur

D’autres API font également partie de la Sandbox, notamment Fenced Frames. Elle a été rendue nécessaire par l’impossibilité de faire fonctionner le contenu embarqué de manière classique avec le contenu agrégé. Une fenced frame est un élément HTML, similaire à une iframe. À la différence de cette dernière cependant, elle limite la communication avec le contexte d’intégration. La frame peut accéder ainsi aux données intersites, sans les partager avec le contexte d’intégration. La reconstitution du contenu se fait depuis plusieurs partitions différentes de stockage (via l’API Shared Storage).

Privacy Sandbox

Les développeurs invités à se lancer dès maintenant

En pratique, les pourcentages de déploiement vus précédemment correspondent à la disponibilité de ces API chez les internautes. Et c’est là que réside un point important : ce n’est pas parce que les API seront activées que le processus va fonctionner pour l’ensemble des sites et applications.

Pour profiter de la Privacy Sandbox, il faut que les réseaux publicitaires soient prévus pour en tirer parti. Cela ne va donc se faire que progressivement, avec sans doute un vrai décollage à partir du 20 septembre, date à laquelle la quasi-totalité des utilisateurs auront le mécanisme et signant la fin de la phase d’expérimentation (origin trial). Rien n’empêche les entreprises concernées de se lancer, avec un système double, capable de servir des publicités traditionnelles, sauf quand la Privacy Sandbox est détectée.

Les développeurs devront cependant passer par le processus d’inscription et d’attestation. Google prévient d’ailleurs qu’elle sera « bientôt » obligatoire et recommande de se lancer dès maintenant. Cet accès est obligatoire pour accéder notamment aux API de pertinence et de mesure. Dans le billet de blog, L’entreprise fournit d’ailleurs des moyens simples aux développeurs d’outrepasser les limites de déploiement pour réaliser des tests en local.

Privacy Sandbox, un réel progrès ?

L’initiative de Google aura demandé des années de travail, avec des dates de lancement plusieurs fois repoussées. La CMA anglaise (Competition and Markets Authority) s’était ainsi penchée sur la Privacy Sandbox, exprimant des craintes sur de possibles abus de position dominante. Après enquête, Google s’est engagée à respecter certaines règles, la CMA s’estimant satisfaite.

Maintenant que le mécanisme est sur le point de commencer officiellement sa carrière, il faut rappeler un point central : la Privacy Sandbox n’a pas pour objectif d’en finir avec le partage des informations personnelles, seulement de les limiter.

Pour la société de Mountain View, c’est la meilleure solution entre intérêt pour la vie privée et nécessité de laisser un écosystème « florissant » fonctionner à plein régime. Comprendre la publicité ciblée. Le résultat serait atteint sans pouvoir relier une personne aux traces laissées, tout du moins dans le cadre de la publicité.

Aujourd’hui, la Privacy Sandbox ne semble faire l’objet d’autant de critiques que l’ancien FLoC, mais il est encore trop tôt pour juger de sa réelle efficacité. En attendant, à partir du 24 juillet, vous verrez peut-être de nouveaux contrôles disponibles dans les paramètres de Chrome, section Confidentialité et sécurité. On connait déjà les liens pour accéder aux trois rubriques liées aux API principales :

  • Topics : chrome://settings/adPrivacy/interests
  • Protected Audience : chrome://settings/adPrivacy/sites
  • Attribution Reporting : chrome://settings/adPrivacy/measurement

Commentaires (22)


Vivaldi a bloqué “Topics” sur le Chromium qui le motorise, désactivé aussi ce “Privacy Sandbox” par défaut, gageons qu’ils réserveront le même sort au “Web Environment Integrity” dont on cause aujourd’hui :chinois: :
https://github.com/RupertBenWiser/Web-Environment-Integrity


Le browser web, ce logiciel manifestement destiné à faire de la publicité ciblée.



(soupir)


Mouaiiiis… M’kaaaayyyy…. Je sens que - en tout cas de mon côté - ça va finir au même endroit que le web3 : ICI.


Dans le schéma d’illustration, on a l’impression qu’il y aura un changement au niveau du fonctionnement des iframes. Est-ce le cas ?


J’espère vraiment que ca ne va pas pénaliser Firefox.
Certains sites, étatiques par ex (immigration canadienne, juste pour en citer un), exigent les cookies tiers, sinon tu ne vas pas plus loin dans le process. Si c’est remplacé par le truc de Chrome, et si ça lui est exclusif, ca pourrait faire mal… Déjà qu’il domine largement le secteur 😭


Web environement integrity est un DRM abominable, sous couvert d’authentifier des utilisateurs/fakes c’est le boulevard ouvert aux abus.
https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md
Un papier à ce sujet serait nécessaire, j’espère que cela va secouer les acteurs, c’est la fin du Web interopérable sinon.



pierreonthenet a dit:


Dans le schéma d’illustration, on a l’impression qu’il y aura un changement au niveau du fonctionnement des iframes. Est-ce le cas ?




Non les iframes sont déjà bloquées depuis une dizaine d’années : c’est le Cross Site Scripting (XSS)



Ce truc ne va pas empêcher de passer des identifiants publicitaires, il suffit par exemple de simplement passer l’identifiant dans l’URL de l’iFrame, par contre en rajoutant des catégories au profil de navigation, ça va encore accentuer notre unicité sur internet et donc la traçabilité y compris en navigation privée


Comment ça “les iframes sont bloquées” ?
Ça fonctionne très bien les iframes, encore aujourd’hui, et sur tous les navigateurs. Et heureusement, sinon plus d’inclusion de cartes, par exemple !



Le XSS, c’est lorsqu’on fait du JavaScript.



J’ai pas compris la partie sur les catégories.



J’ai comme l’impression qu’il y a un traitement particulier pour les intégrations de pubs via iframes ou autres…


c’est fou comme le Fenced Frames me rappelle un peu le First Party Isolation de Firefox…



je confirme, les iframe ne sont pas bloquées. et le XSS, c’est du code javascript dans les formulaires (les iframe sont en partie isolés depuis longtemps)…



(reply:2143953:ra-mon)




Y’a quoi de mauvais avec ça stp ?


je viens de voir les tickets ouverts, ce truc ajoute un identifiant unique dans le navigateur…




with WEI, the cost of that fingerprinting, even if the data is reduced, now becomes effectively almost 0: make an API call and break your site if the call doesn’t pass! It’s that easy.



Albirew

je viens de voir les tickets ouverts, ce truc ajoute un identifiant unique dans le navigateur…




with WEI, the cost of that fingerprinting, even if the data is reduced, now becomes effectively almost 0: make an API call and break your site if the call doesn’t pass! It’s that easy.



C’est pas le navigateur qui gère cet identifiant, justement ?
Dans ce cas, rien ne l’empêche d’en créer un par site, par exemple. Mais je comprends mieux les craintes. Merci. 😉



pierreonthenet a dit:


Comment ça “les iframes sont bloquées” ? Ça fonctionne très bien les iframes, encore aujourd’hui, et sur tous les navigateurs. Et heureusement, sinon plus d’inclusion de cartes, par exemple !



Le XSS, c’est lorsqu’on fait du JavaScript.



J’ai pas compris la partie sur les catégories.



J’ai comme l’impression qu’il y a un traitement particulier pour les intégrations de pubs via iframes ou autres…




C’est bel et bien bloqué: l’iframe n’a pas accès à la page principale (ni ses cookies,ni son contenu DOM), et elle n’est chargée que si elle autorise explicitement le site principale : https://blog.mozilla.org/security/2013/12/12/on-the-x-frame-options-security-header/


Et suite à ce blocage, il y a déjà une extension pour débloquer appelé “Ignore X-Frame-Options Header” pour Firefox


Kazer2.0

Et suite à ce blocage, il y a déjà une extension pour débloquer appelé “Ignore X-Frame-Options Header” pour Firefox


Ya probablement pas besoin d’extension, un simple tour dans about:config devrait être suffisant. Le problème n’est pas là une fois qu’une option est bloquée par défaut dans un navigteur, les sites web ont l’obligation de s’adapter pour ne plus l’utiliser.
La parade sur les sites intranet à l’époque était de dire que ça marche qu’avec Internet Explorer (qui était largement en retard sur ces sujets), sauf que IE est enfin mort et enterré, il n’y a plus de navigateur laxiste par défaut.


OK, je comprends mieux ce que tu as voulu dire.
Pour moi, ce n’est pas bloqué mais limité techniquement par le navigateur, ce qui n’est pas la même chose.
Et encore, ce que tu indique est bloqué si l’iframe n’est pas sur le même nom de domaine que la page l’incluant. 😉



Longue vie aux iframe ! 😜



L’occasion de rappeler comment fonctionne ce mécanisme censé améliorer la vie privée autour de la publicité ciblée.




Ce qui en soit est antinomique.



SebGF a dit:




L’occasion de rappeler comment fonctionne ce mécanisme censé améliorer la vie privée autour de la publicité ciblée.




Ce qui en soit est antinomique.




On peut vouloir le respect de sa vie privée et pour autant avoir des pubs avec du contenu qui suscite un intérêt personnel. Ce que je trouve abusif (intrusif ?) c’est que la publicité cible directement mon profil/historique et pas le profil/historique du site que je visite.



Que j’ai des pubs de CPU quand je visite NXI, ok.
Que j’ai des pubs de croquettes quand je visite Wanimo, ok.



Mais que j’ai des pubs de croquettes quand je visite NXI, au prétexte que mon profil/historique montre que je vais souvent sur Wanimo, ca me parait aller trop loin. D’autant plus que ca me fait l’effet inverse de celui escompté (genre “forcing”).


La raison pour laquelle je considère le respect de la vie privée et le profilage comme incompatibles, c’est parce qu’on ne me demande pas si je souhaite y consentir. Et comme c’est de nos jours intégré en profondeurs aux socles techniques quotidiennement utilisés (OS / navigateurs), c’est de plus en plus irréconciliable de mon point de vue.



Si des personnes veulent y consentir, ça ne me dérange pas outre mesure. Mais perso je n’en ai pas envie et n’ai pas d’objection à payer un service pour ne pas avoir à le payer en données personnelles. Mais malheureusement, je n’ai pas le même point de vue qu’un entreprise qui titre majoritairement profit de cette activité.


«Les développeurs devront cependant passer par le processus d’inscription et d’attestation.»



Hop, c’est anti-web ce truc donc à mon sens, c’est mort né ? Jamais Apple n’acceptera par exemple une attestation obligatoire via Google.


Si le site qui veut afficher de la pub ou traquer les utilisateurs est vraiment motivé, cela ne servira pas à grand chose. La parade au blocage des cookies tiers est déjà connue depuis quelques années : il suffit que le site qui affiche la pub utilise un sous-domaine dédié



Par contre, si ça peut bloquer les cookies de Facebook/Twitter/Google déposés par les embeds ou l’utilisation des Google Fonts par exemple, c’est en effet pas mal.



À voir cependant si cela ne cause pas trop d’effets de bord (comme le site canadien cité plus haut), et en espérant que cela ne permette pas à Google d’être encore plus avantagé sur le marché de la pub, étant donné que c’est un mécanisme “accessible à tous” qui disparaît…


Comment est constitué les groupes de personnes selon le centre d’intéret ?



Est ce Google ?
Ce n’est pas très clair et bien entendu Google ne diffuse pas trop cette info. Si c’est Google, sa solution est un peu pour bien se faire voir.




Ailothaen a dit:


Par contre, si ça peut bloquer les cookies de Facebook/Twitter/Google déposés par les embeds ou l’utilisation des Google Fonts par exemple, c’est en effet pas mal.




Autant il est possible de bloquer les connexions automatique Google et Facebook et cela n’a pas d’incidence sur le site, autant pour les Google Fonts, je pense que malheureusement c’est obligatoire pour l’affichage de site.


Fermer