À propos de Web Environment Integrity

  1. Description
  2. Analyse détaillée
    1. Motivations
    2. Exemple
    3. Termes clés
    4. Infrastructure
  3. Observations
  4. Interprétation

Alors que le 20 juillet j'ai déversé ma colère, ma haine et ma frustration dans ce billet, et alors qu'aujourd'hui je me suis levé de moins mauvaise humeur, voilà qu'apparait un article étrange dans mes flux RSS, intitulé "Web Environment Integrity". En tant que développeur web, ce titre m'a interpelé, alors j'ai regardé de quoi il s'agissait plus en détail.

Je vais essayer de ne pas trop rentrer dans les détails techniques dans cet article, afin de faciliter sa compréhension par le plus grand nombre. L'important ici est d'interpréter les enjeux. Je ne peux pas être totalement objectif ; veuillez me pardonner, par avance, les coups de sang que vous lirez ici.

Description

Ben Wiser (littéralement, "Wiser" = "le plus sage") de chez Google introduit Web Environment Integrity en ces termes :

An API used to integrity check the environment a web page runs on. This check is performed by trusted attesters.

Traduction personnelle :

Une API pour vérifier l'intégrité de l'environnement dans lequel une page web s'exécute. Cette vérification est réalisée par des attestateurs de confiance.

Autrement dit, une application (la doc parle de "user agents", ce qui englobe les navigateurs web mais sans se limiter à cette définition) exploitant WEI peut collecter des données sur la machine qui l'exécute, envoyer ces données à des "partenaires" de Google (ou Google elle-même) pour déterminer si cette machine "mérite" d'exécuter l'application en question.

On apprend dans la spec que plusieurs de ces entités peuvent être contactées, chacune délivrant un verdict. Si le verdict est positif, la machine est autorisée à exécuter l'application.

Analyse détaillée

Pour commencer, je note le sous-titre du document : "A Collection of Interesting Ideas", datant du 21 juillet 2023. Notez l'ironie.

Le document est publié à la fois dans le domaine public et sous l'Open Web Foundation Agreement Version 1.0. Ça, c'est pour dire "c'est nous les gentils, on est pour un web ouvert". Mon cul.

Motivations

L'auteur évoque le manque de coopération des agents utilisateurs (les navigateurs, en substance, mais comme je viens de le dire, user agent englobe virtuellement toute application) dans le cadre de l'établissement d'une relation de confiance entre un client et un serveur.

Jusqu'aujourd'hui, on a cherché à "résoudre" le problème du point de vue du client. En tant qu'Internaute, est-ce que les serveurs auxquels je me connecte sont dignes de confiance ?

WEI semble opter pour le point de vue opposé : en tant que serveur web, est-ce que ces clients qui essayent de se connecter à moi sont dignes de confiance ?

Deux cas de figure sont mentionnés :

When users are playing online games for instance, they are trusting that other users are not cheating.

when they are browsing social media websites, they are trusting that other users are not faking engagement to make posts popular.

Traduction approximative : dans un jeu vidéo on doit faire confiance aux autres joueurs pour ne pas tricher, et sur les réseaux sociaux, on doit faire confiance aux autres personnes pour ne pas propager des informations fausses.

Ces deux exemples me confortent dans une idée directrice de toutes mes publications, à commencer par L'Humain, cette espèce primitive : on cherche des solutions techniques pour résoudre des problèmes sociaux. La triche et la propagation de fausses informations sont des problèmes sociaux, mais ici, on cherche à les résoudre par l'intermédiaire d'attestateurs de confiance.

De ce que j'en comprends, cela peut potentiellement signifier respectivement que :

  1. Un jeu vidéo implémentant WEI acheté par une personne qui n'est pas reconnue comme étant "de confiance" par Google ou ses partenaires ne se lancera pas
  2. Une personne qui n'est pas reconnue comme étant "de confiance" par Google ou ses partenaires ne pourra plus communiquer sur les réseaux sociaux qui implémentent WEI

Déjà là de nombreuses questions éthiques sont à souligner. Principalement parce que cela revient à affecter aux gens une note de popularité, mais aussi parce qu'on ignore qui va le faire, sur quels critères, et dans "quelle case" iront les gens qui n'ont jamais été "évalués". Ces sous-questions constituent par elles-mêmes des signaux forts, devant alerter sur un danger critique et qu'il n'est pas possible d'ignorer.

L'auteur déplore ensuite qu'à l'heure actuelle, les sites web ne peuvent bénéficier de la coopération des agents utilisateurs, forçant ces derniers à collecter des données utilisateurs.

Plusieurs pistes de réflexions peuvent être choisies pour interpréter cette remarque.

  1. L'auteur sous-entend que les sites web collectent des données utilisateurs - personnelles - par obligation et non par choix
  2. Les agents utilisateurs (navigateur, jeu vidéo, plateforme de réseau social, etc.) ne facilitent pas la détermination d'un indice de confiance propre à chaque utilisateur
  3. Le fingerprinting (le recoupage de données plus ou moins personnelles pour identifier de façon unique un utilisateur sur Internet) est une mauvaise pratique que WEI vise à supprimer ; autrement dit, comme d'habitude, Google se présente en tant que sauveur de l'humanité, protégeant à la fois la vie privée des utilisateurs et des tricheurs et des menteurs

Exemple

L'auteur montre alors un exemple d'implémentation que je recopie ici afin de l'expliquer. Je note qu'évidemment, c'est en javascript...

// getEnvironmentIntegrity expects a "content binding" of the request you are
// about to make. The content binding protects against this information being
// used for a different request.
// The contentBinding will be concatenated with top-level domain name and hashed
// before it is sent to the attester.

const contentBinding = "/someRequestPath?requestID=xxxx" +
    "Any other data needed for a request-specific contentBinding...";

const attestation = await navigator.getEnvironmentIntegrity(contentBinding);

console.log(attestation.encode());
"base-64 encoding of the attestation payload and signature approx 500 bytes; see below for details"

// More on attestation validation below
const response = await fetch(`/someRequest?requestID=xxxx&attested=${attestation.encode()}`);
// Do something with this ...

On peut déjà constater que, en extrapolant, tout agent utilisateur désirant implémenter cette fonctionnalité devra soit être lui-même un navigateur, soit embarquer un navigateur (Google Chrome, par exemple...), parce que, comme expliqué dans le commentaire en haut du code source, c'est spécifiquement l'objet navigator qui demande la vérification de l'intégrité de l'environnement.

Ensuite, c'est une requête API classique : on envoie ces informations (le contentBinding) aux organismes attestateurs pour vérifier si cet environnement est fiable ou non.

Termes clés

À ce stade, il est utile de préciser que le document dont on parle ici n'est pas encore terminé, mais il est intéressant de voir que l'auteur est empressé de définir comment un tel système peut fonctionner et à quoi il peut servir. Il est beaucoup moins important pour l'auteur de définir avec précision les termes clés et les concepts dont on parle.

Par exemple, on ignore encore ce qu'est réellement un environnement web ou le contenu du contentBinding utilisé ci-dessus. On en déduit en revanche que l'objectif d'éviter aux sites web de collecter des informations personnelles sur les utilisateurs n'est évidemment que transposé : effectivement, ce ne sont plus les sites web qui collectent ces informations, mais directement Google et ses partenaires. On supprime les intermédiaires, en quelque sorte.

Infrastructure

On définit un attestateur comme le tiers capable d'émettre un verdict. L'agent utilisateur doit disposer d'une connexion à ce(s) tiers afin d'utiliser WEI. Autrement dit, face à l'impossibilité de contacter un tiers, l'environnement sera par défaut considéré non-fiable, excluant de fait tout usage hors-connexion de toute application implémentant WEI.

Évidemment, cela signifie également que si la connexion à un attestateur est bloquée via différents moyens (par exemple, par un blocage DNS ou même par de simples règles de pare-feu), l'environnement sera aussi considéré non-fiable.

Observations

Le dépôt indique une activité depuis le 25 avril 2023. On peut donc considérer ce "projet" comme étant déjà réfléchi en amont : il n'a pas été rendu public le 23 juillet, c'est juste qu'il est apparu dans mes flux à cette date.

Le nombre de tickets hostiles à cette proposition est intéressant. Certains commentaires sont constructifs (posant la question de qui seront véritablement les attestateurs par exemple), d'autres moins.

Interprétation

Je vais commencer par éculer quelque chose qui me brûle les doigts depuis avant : nazisme.

Ce document propose ni plus ni moins que la suppression (certes, virtuelle) de gens fichés par des autorités supérieures (les attestateurs) pour le compte d'une entité suprême (Google).

Avec l'effet de bord notoire du contrôle de ce que les gens peuvent voir, dire, faire, selon des normes morales définies par ces mêmes instances, sans que les utilisateurs le sachent.

Parce que ce système est de l'or en barre pour tout un tas d'acteurs, pas seulement Google.

L'exemple que j'ai pu lire le plus concerne typiquement les publicités sur Internet. Oubliez les ad-blockers, pi-hole et compagnie, c'est terminé. Vous bloquez les attestateurs, vous n'accéderez pas au contenu (et on peut gager qu'en prime, ça fera baisser votre "note de fiabilité").

Le concept sera facilement étendu à tout site web désireux de "protéger" son contenu contre les malveillants lecteurs qui ne payent pas, sauf que cette fois, il n'y aura pas de solution de contournement.

Il y aura bien ceux pour dire que si vous n'avez rien à vous reprocher, vous n'avez rien à craindre, "argument" fallacieux et dangereux à utiliser, pourtant brandi à tort et à travers dès qu'on parle de serrer la vis sur Internet.

L'important, pour moi, c'est de savoir que c'est dans les tuyaux de Google. Même si ce torchon est archivé et "oublié", la méthode est parfaitement valable et implémentable. Il suffit juste de convaincre les plateformes de s'y mettre, ce qui se fera sans trop de problème à grand renfort de graphiques montrant l'argent que ça va faire brasser.

C'est la solution ultime, à l'heure actuelle, pour s'assurer que les gens font ce qu'ils sont censés faire sur Internet, et pour marginaliser (voir exterminer) ceux qui ne rentrent pas dans les rangs.

On va être obligés de regarder plus de publicités qu'avant, partout et tout le temps. Pas seulement sur Internet, mais aussi à la télévision conventionnelle, en VoD, en replay.

Il est certain que ça va simplifier les choses pour beaucoup de gens : plus besoin d'installer un serveur DNS à la maison pour bloquer les pubs et plus besoin d'installer d'ad-blocker sur chaque navigateur du foyer.

Considérons ce document comme un avertissement : c'est à la portée de Google, et il me semble inévitable que son implémentation soit massive. Ne soyez pas du mauvais côté de l'histoire.