Il y a une semaine, nous nous penchions sur l’API Web Environment Integrity envisagée par Google. Dans notre analyse, nous montrions qu’elle avait la capacité de verrouiller partiellement le web au profit de l’entreprise. Depuis, beaucoup ont réagi, dont Brave, Mozilla et Vivaldi, pour dire tout le mal qu’ils en pensaient.
Des intentions claires, mais…
Les objectifs affichés de cette API n’ont rien de scandaleux a priori. Il s’agit en bonne partie d’établir un lien de confiance entre une machine et un service, la première pouvant prouver au second qu’elle est bien ce qu’elle prétend être.
Ce fonctionnement est largement inspiré de certaines interfaces de programmation que l’on trouve dans les environnements mobiles, tout particulièrement Play Integrity sur Android et App Attest sur iOS. Google s’étant « fait la main » avec Play Integrity, elle propose d’appliquer les mêmes principes à la navigation web.
Les bénéfices seraient importants en théorie. Les techniques utilisées permettraient à un PC, un smartphone, une tablette ou autre de prouver qu’ils sont des appareils classiques contrôlés par un être humain. Dans le cas contraire – par exemple un bot – la connexion serait refusée et le contenu ne serait pas fourni.
Ce fonctionnement est courant sur Android et iOS. Les applications bancaires, Netflix, les jeux mobiles, Google Wallet et autres refusent de fournir le service attendu dans ce cas. Play Integrity est également connue pour empêcher ces applications de tourner sur les appareils « rootés ». La raison invoquée est simple : il n’est plus possible de garantir que le système fonctionne de la manière dont il a été conçu, le rootage permettant aussi d’utiliser des applications modifiées.
Le danger viendrait de cette certification. Dans le modèle exposé par Google, une entité tierce serait chargée de fournir la précieuse attestation au navigateur, qui aurait alors le droit de recevoir le contenu. En pratique, Google pourrait être en mesure de contrôler cette chaine d’authenticité et de déterminer les configurations ayant le droit d’accéder à certains services.
Le mécanisme étant aussi prévu pour vérifier plus finement les impressions publicitaires sur le web, Web Environment Integrity pourrait être utilisée pour refuser la présence de certaines extensions, comme les bloqueurs de publicité. Bloqueurs déjà menacés par le Manifest V3, déjà accusé d’être une charge (à peine) déguisée contre ce type d’extension. WEI a ainsi été rapidement surnommé « DRM du web ».
Défiance généralisée
Il n’a pas fallu attendre pour que les réactions fusent, notamment du côté des éditeurs de navigateurs.
Chez Brave par exemple, Brendan Eich en personne a pris la parole. L’inventeur du JavaScript a répondu initialement à une personne évoquant Brave comme un simple thème pour Chrome, ce qu’Eich a clairement rejeté. Il a rappelé que Brave est un fork doté d’une longue liste de « déviations », c’est-à-dire de différences avec Chrome, notamment des composants que le navigateur ne reprend pas.
Dans cette liste, on peut voir depuis que Web Environment Integrity a été ajoutée il y a quatre jours. La société est claire sur le sujet : l’API de Google n’entrera pas dans Brave. Brendan Eich s’attend à ce qu’Apple – qui ne s’est pas encore exprimée sur le sujet – refuse, elle aussi, l’API dans Safari.
Chez Mozilla, la position de l’éditeur a été demandée sur son dépôt GitHub. L’un des ingénieurs de Mozilla, Brian Grinstead, a répondu très clairement que l’entreprise s’opposait « à cette proposition parce qu'elle est en contradiction avec nos principes et notre vision du Web ». Pour Mozilla, le constat est simple : tout navigateur, serveur ou éditeur implémentant des standards communs devient automatiquement une partie du web. Il cite un passage de la page « Vision du web » de l’éditeur :
« Les normes elles-mêmes visent à éviter les hypothèses sur le matériel ou les logiciels sous-jacents qui pourraient limiter leur déploiement. Cela signifie qu'aucune partie ne décide des facteurs de forme, des appareils, des systèmes d'exploitation et des navigateurs pouvant accéder au web. Cela donne aux gens plus de choix, et donc plus de possibilités de surmonter les obstacles personnels à l'accès. Les choix en matière de technologie d'assistance, de localisation, de facteur de forme et de prix, combinés à une conception réfléchie des normes elles-mêmes, permettent à un groupe très diversifié de personnes d'accéder au même site web »
« Les mécanismes qui tentent de restreindre ces choix nuisent à l'ouverture de l'écosystème du web et ne sont pas favorables aux utilisateurs », poursuit Brian Grinstead. En outre, puisque WEI doit ne laisser passer que le trafic détecté comme « humain », l’API pourrait créer des obstructions dans divers cas tels que les technologies d’assistance, les tests automatiques, l’archivage et autres.
« Une menace majeure »
Chez Vivaldi, la position a été développée dans un billet de blog dédié. Web Environment Integrity y est décrite comme « une menace majeure ». Julien Picalausa, son auteur, y décrit en particulier un problème potentiel dont nous nous étions fait l’écho la semaine dernière : si un navigateur décide de ne pas implémenter WEI, il pourrait ne pas être considéré comme fiable. Dès lors, les services se servant de cette API pourraient ne pas servir leur contenu aux personnes concernées.
Selon Picalausa, Edge et Safari ne seront probablement pas en danger. Car en tenant compte du pouvoir dont jouirait Google, ses deux concurrents auraient des capacités de réplique sur leurs propres plateformes, bien trop présentes pour être ignorées. Quant à tous les autres, la force de frappe de Google permettrait probablement d’entrainer presque tout le monde dans son sillage. Par effet boule de neige, tout navigateur ne montrant pas patte blanche ne serait pas considéré comme fiable et ne pourrait pas faire fonctionner les services utilisant WEI. En reprenant la liste des applications se servant de Play Integrity, on peut se passer de Netflix, mais difficilement d’un accès au site de sa banque.
Il estime cependant qu’il existe un espoir, outre le fait que Google ne s’est pas exprimée officiellement sur la question. Pour Picalausa, l’Union européenne pourrait avoir son mot à dire, son historique – particulièrement avec Google – suggérant fortement qu'elle « ne permettra pas à quelques entreprises de disposer d'un pouvoir énorme pour décider quels navigateurs sont autorisés et lesquels ne le sont pas ».
Reste le cas emblématique des EME (Encrypted Media Extensions), adoubées par le W3C et qui avaient en leur temps permis aux DRM de s'installer pour les flux multimédias. On peut d'ailleurs le constater dans les réponses à Brendan Eich et à Mozilla que beaucoup n'ont pas oublié.
