La Privacy Sandbox est officiellement entrée en action hier. Tandis que d’un côté Google vante un meilleur respect de la vie privée, elle prépare de l’autre une nouvelle API déjà entourée d’une aura sulfureuse. Nommée Web Environment Integrity, elle aurait la capacité de mettre en échec les bloqueurs de publicité.
Web Environment Integrity est un projet mené par une équipe de quatre développeurs de Google, dont l’un de ceux derrière la Privacy Sandbox. Il s’agit d’une API (Application Programming Interface) qui a essentiellement pour mission de signaler à un serveur qu’un client est ce qu’il prétend être. En somme, elle a une mission de preuve d’authenticité, avec un fonctionnement qui n’est pas sans rappeler celui des DRM.
Objectifs et inspiration
« Les utilisateurs dépendent souvent de sites web faisant confiance à l'environnement client dans lequel ils fonctionnent. Cette confiance peut supposer que l'environnement client est honnête sur certains aspects de lui-même, qu'il sécurise les données des utilisateurs et la propriété intellectuelle, et qu'il est transparent sur le fait qu'un être humain l'utilise ou non », expliquent les ingénieurs sur le dépôt GitHub où réside actuellement le projet.
L’objectif principal de Web Environment Integrity est de mieux connaître le terminal demandant un contenu, à travers le navigateur. L’API doit pouvoir déterminer par exemple qu’il ne s’agit pas d’un bot, auquel cas les données réclamées ne seront pas communiquées. À sa charge également de vérifier que le navigateur n’a pas été modifié intentionnellement ou par le truchement d’un malware.
Ce type de fonctionnement existe depuis plusieurs années sur Android et iOS, respectivement avec Play Integrity et App Attest. Dans les deux cas, ces mécanismes sont chargés de caractériser l’appareil sur lequel fonctionne une application. Ils permettent aux éditeurs de refuser que leur application fonctionne quand les conditions ne sont pas remplies, par exemple si l’application a été modifiée d’une manière imprévue.
Sur Android, l’API Play Integrity peut également bloquer une application si l’appareil a été rooté. Sur la page Google de l’interface, on peut lire qu’elle doit « vérifier que les actions et les requêtes des utilisateurs proviennent du binaire d'application non modifié, installé par Google Play, et exécuté sur un appareil Android authentique. Le serveur backend de votre application peut décider de la procédure à suivre pour éviter les abus, les accès non autorisés et les attaques ».
En pratique, Play Integrity joue un grand rôle dans le fonctionnement quotidien des applications Android. En cas d’appareil rooté, de nombreuses applications refuseront en effet de s’exécuter, comme celles des banques, Netflix, Snapchat, la plupart des jeux en ligne, Google Wallet et d’autres, comme le note ArsTechnica. Il s’agit d’une réponse directe à une problématique très pragmatique : s’assurer que l’environnement n’a pas été modifié pour en tirer un avantage quelconque. Dans le cadre des jeux en ligne, une forme de triche par exemple.
Du côté des utilisateurs, la conséquence est que le bébé part avec l’eau du bain. Dans le cas d’un rootage effectué volontairement et dans la sphère privée pour débloquer de nouvelles capacités sur son téléphone, le résultat est le même : les applications ne fonctionneront pas. L’API ne fait pas la différence (et ne le peut pas).
C’est le même type de mécanisme que prévoit Google avec ce projet. Il ne s’agit d’ailleurs pas d’une simple réflexion, puisque l’API est en cours de prototypage en vue d’une inclusion dans Chrome.
Comment ?
Ce type de technologie, dans son approche, n’a rien de nouveau. Le processus est semblable à tout mécanisme de fingerprinting, en collectant des signaux peu susceptibles d’évoluer. Ils sont alors brassés pour composer un identifiant unique. Les ingénieurs se défendent pourtant de tout fingerprinting, indiquant même que la conception de l’API ne doit jamais s’en approcher.
Avec Web Environment Integrity, une page web pourrait demander une vérification d’authenticité avant de fournir un certain contenu. Durant la transaction web, le serveur émettrait alors une telle demande. Le navigateur contacterait à son tour un serveur d’attestation tiers, qui lui ferait passer un test.
Si le test échoue, un message est émis pour avertir l’internaute et l’affichage du contenu est refusé. Si le test réussit, le navigateur obtient un jeton d’intégrité (IntegrityToken), témoignant d’un environnement « sain » (comprendre « non modifié »). Après communication du jeton au serveur web initial, le contenu visé est débloqué et affiché. Comme pour Play Integrity sur Android, il peut aussi bien s’agir d’un contenu vidéo que d’un service bancaire, entre autres exemples.
Quel intérêt pour Google ?
Toujours sur le dépôt GitHub du projet, les auteurs indiquent que Web Environment Integrity aurait de multiples intérêts, comme empêcher la triche sur les jeux web, s’assurer du respect des droits sur les contenus ayant un copyright, freiner les bots sévissant sur les réseaux sociaux, apporter une nouvelle couche de sécurité aux transactions financières ou encore mieux compter les impressions publicitaires. Ce dernier point est bien sûr capital.
Plus de 90 % du chiffre d’affaires de Google provient de la publicité. Les outils de Google dans ce domaine sont omniprésents, au point que Margrethe Vestager, vice-présidente de la Commission européenne, a agité le mois dernier le spectre d’un démantèlement partiel de l’entreprise, si elle ne mettait pas bon ordre dans ses pratiques. En outre, Chrome est le navigateur le plus utilisé au monde, avec une part de marché d’environ 60 %.
Techniquement, Google pourrait se servir de ce mécanisme pour n’autoriser les connexions à ses propres services que dans les conditions qui l’intéressent. Pour de nombreux observateurs, le Manifest V3 était déjà une charge déguisée contre les bloqueurs de publicité. Avec Web Environment Integrity, Google serait en mesure de définir précisément les conditions d’accès à ses services, qui comptent parmi les plus utilisés au monde.
Début de polémique
Le dépôt GitHub n’est pas tout neuf. Les premières modifications y ont pris place en avril 2022. Il a cependant fallu attendre le 21 juillet dernier pour que le projet gagne en visibilité. À la suite en effet d’un ajout nommé « Une collection d’idées intéressantes », le sujet apparaît chez HackerNews, déclenchant immédiatement une vague d’hostilités.
Les avis sont nombreux et la plupart des éléments de langage vont dans le même sens : « l’inévitable fin du web », le contrôle absolu par Google, Firefox comme solution de secours, ou encore l’avènement de Chrome en tant qu’Internet Explorer. Ce n’est pas la première fois que ce type d’opinion surgit autour de Chrome, mais il est clair que le projet de Google déclenche des réactions nettement plus vives qu’habituellement.
Sur la page GitHub du projet, de nombreuses personnes ont déboulé pour signaler des « issues » (problèmes), dans un langage plus ou moins fleuri. Le numéro 127 demande par exemple : « Vous êtes-vous déjà arrêtés pour vous demander si vous n’étiez pas les méchants ? ». Un autre qualifie le projet de « absolument contraire à l'éthique et à l'ouverture du web ». Un autre encore a publié un message en hexadécimal, qui commence par « Mort aux fascistes, mangez les riches » et souhaite une « diarrhée explosive » aux concepteurs de Web Environment Integrity.
Google a pourtant tenté de mettre des formes à sa proposition. Dans son « explainer », les quatre ingénieurs évoquent les buts et non-buts de la technologie. Par exemple, la technologie est conçue pour ne pas autoriser de nouvelles capacités de suivi cross-site grâce aux attestations reçues, ce qui nierait d’ailleurs la raison d’être de la Privacy Sandbox. Surtout, l’API n’est pas censée « renforcer ou interférer avec les fonctionnalités du navigateur, y compris les plugins et les extensions ».
Un danger de fragmentation
Cette mention des extensions est importante, puisqu’elle concerne directement les capacités de blocage publicitaire recherchées par bon nombre d’internautes. À ce sujet, les explications sont imprécises : l’API « atteste la légitimité de la pile matérielle et logicielle sous-jacente, elle ne restreint pas les fonctions de l'application. Par exemple, si le navigateur autorise les extensions, l'utilisateur peut les utiliser ; si un navigateur est modifié, le navigateur modifié peut toujours demander l'attestation de l'intégrité de l'environnement web ». C’est tout.
Dans l’optique où Google aurait pour projet de verrouiller les accès à ses services en imposant ses conditions, rien ne serait gagné pour autant. Chrome a beau être le navigateur le plus utilisé au monde, rejeter radicalement les bloqueurs de publicité aurait tôt fait de lancer une partie des internautes à la recherche de nouvelles solutions pour un web « plus propre ». Mais là encore, aucune garantie, car Google dit ne pas souhaiter que son mécanisme soit exclusif à Chrome. Les autres navigateurs pourraient ainsi l'adopter. On imagine mal cela dit des éditeurs comme Mozilla l'adopter, quand sa position sur le Manifest v3 est déjà très claire.
Si, au contraire, Google prévoit de proposer cette API comme simple équivalent de Play Integrity pour le web, le danger ne sera pas moins grand. Web Environment Integrity fonctionnerait alors comme un DRM pour le web, fractionnant les services entre ceux qui l’utiliseraient et les autres. Il n’y a pas de raison en effet pour que des sociétés comme Netflix ou les banques, qui se servent de ces mécanismes sur Android et iOS, fassent l’impasse sur cette solution qui garantirait les conditions d’exécution prévues.
