- Android WebView Media Integrity API sera testée dans le cadre d’un pilote expérimental avec certains fournisseurs de médias au début de l’an prochain, afin de permettre aux fournisseurs de médias intégrés de vérifier l’environnement de lecture
- Il existe déjà des services d’attestation comme Play Integrity API ou Firebase App Check, mais transmettre ces informations aux fournisseurs de contenu intégré n’est ni simple ni très évolutif
- L’équipe Chrome n’examine plus la proposition Web Environment Integrity, et la nouvelle API se limite aux WebView dans les applications Android et aux médias intégrés comme la vidéo et l’audio en streaming
- La flexibilité de WebView est utile pour l’intégration dans les applications, mais comme les développeurs peuvent accéder aux contenus web et aux interactions des utilisateurs, voire les modifier, cela ouvre aussi la voie à la fraude et aux abus
- Les réponses d’intégrité n’incluent que des verdicts sur l’appareil et l’application, sans identifiants utilisateur ou appareil, et l’application peut, si elle le souhaite, exclure le nom du package de l’évaluation
Une nouvelle API WebView pour vérifier les médias intégrés
- Android WebView est une API puissante et flexible qui permet aux développeurs Android d’intégrer des médias dans leurs applications
- Les fournisseurs de médias intégrés doivent pouvoir vérifier que leurs contenus sont lus dans un environnement fiable et sûr
- Les développeurs d’applications Android et les fournisseurs de SDK peuvent déjà utiliser des services d’attestation pour vérifier les requêtes serveur de leurs applications tout en préservant la confidentialité des utilisateurs
- Aujourd’hui encore, les développeurs peuvent transmettre aux fournisseurs de contenu intégré les informations issues de ces services d’attestation, mais ce processus n’est ni simple ni évolutif
- Pour réduire cette limite, un pilote expérimental d’Android WebView Media Integrity API sera mené au début de l’an prochain avec certains fournisseurs de médias intégrés
Une portée limitée, différente de Web Environment Integrity
- L’équipe Chrome n’examine plus la proposition Web Environment Integrity
- Android WebView Media Integrity API cible un périmètre plus restreint
- uniquement les Android WebView intégrés dans des applications
- une extension de fonctionnalités existantes sur les appareils Android dotés de Google Mobile Services (GMS)
- aucune intention de l’étendre au-delà des médias intégrés comme la vidéo et l’audio en streaming
- aucune intention non plus de l’étendre au-delà d’Android WebView
La flexibilité de WebView et les possibilités d’abus
- L’API Android WebView permet aux développeurs d’afficher des pages web et d’intégrer des médias, avec des contrôles d’interface et des options de configuration avancées pour une intégration fluide dans l’application
- Cette flexibilité est utile lorsque l’application intègre son propre contenu web, mais elle permet aussi aux développeurs d’accéder aux contenus web et aux interactions utilisateur, voire de les intercepter et de les modifier
- Il peut en résulter des risques comme la modification de contenu ou la confusion sur l’origine
Réponses d’intégrité et conditions de protection de la vie privée
- La nouvelle API fournit aux fournisseurs de médias intégrés des réponses d’intégrité personnalisées
- les réponses incluent un verdict d’intégrité de l’appareil et un verdict d’intégrité de l’application
- elles permettent de vérifier si le flux s’exécute dans un environnement sûr et fiable, quel que soit l’app store depuis lequel l’application intégrée a été installée
- les verdicts sont des métadonnées simples, à faible entropie, concernant l’application et l’appareil
- ils n’incluent ni identifiant utilisateur ni identifiant d’appareil
- contrairement aux applications et jeux qui utilisent Play Integrity API, les fournisseurs de médias n’obtiennent pas l’état de licence Play de l’application
- l’application peut, si elle le souhaite, exclure son propre nom de package de l’évaluation
- L’équipe Android vise à préserver la diversité de l’écosystème des contenus médias sur Android et recueille les manifestations d’intérêt des fournisseurs de contenus médias intéressés par le programme d’accès anticipé au début de l’an prochain
1 commentaires
Commentaires sur Hacker News
WEI lui-même a déjà été traité dans plusieurs fils, et il y a beaucoup de discussions qui valent la lecture
(juillet 2023, 456 commentaires) https://news.ycombinator.com/item?id=36854114 - "Google's nightmare Web Integrity API wants a DRM gatekeeper for the web"
(juillet 2023, 431 commentaires) https://news.ycombinator.com/item?id=36817305 - "Web Environment Integrity API Proposal"
(juillet 2023, 434 commentaires) https://news.ycombinator.com/item?id=36875940 - "Unpacking Google’s Web Environment Integrity specification"
(juillet 2023, 111 commentaires) https://news.ycombinator.com/item?id=36857676 - "So, you don't like a web platform proposal" - point de vue d’un employé de Google sur la manière dont les gens auraient dû réagir à la proposition
(août 2023, 100 commentaires) https://news.ycombinator.com/item?id=36960882 - "Web Environment Integrity: Locking Down the Web"
les ingénieurs sont arrivés avec des arguments de bonne foi, mais en face c’était une bataille d’image menée de mauvaise foi, et ils se sont fait avoir
la nouvelle selon laquelle Google n’allait pas poursuivre la Web Integrity API est très positive pour la neutralité du web ouvert
cela dit, Google a souvent agi d’abord selon ses propres intérêts plutôt que dans l’intérêt général du web, donc il faudra voir par quoi cela sera remplacé, et cela ne devrait pas tarder
on peut soupçonner qu’ils préparent, comme avec FLoC et Topics, une spécification qui paraît moins choquante en surface mais qui reste tout aussi nuisible pour les utilisateurs, et le fait que cela coïncide avec leur récente annonce de faire évoluer la facturation publicitaire du coût par clic vers le coût par impression est aussi suspect
Google ne s’est pas montré comme un gestionnaire fiable du web, et il ne faut pas se reposer sur cette victoire apparente
à l’avenir, la diversité des navigateurs et des moteurs de navigateur sera essentielle pour empêcher qu’un seul acteur ne domine l’avenir du web
Il faut cesser de voir un courtier mondial en données qui alimente les annonceurs du monde entier comme un gestionnaire légitime et bien intentionné des technologies du web
D’abord, cela viole la séparation des préoccupations entre serveur et client
Le client est un agent utilisateur, c’est-à-dire qu’il doit faire ce que veut l’utilisateur, pas ce que veut le serveur
Ce malentendu fondamental et cette déformation du point de vue font partie du problème
Si l’on veut conserver HTTP(S) et les technologies associées comme des protocoles libres et ouverts pour tous, il faut exclure Google du processus de décision
Google était déjà derrière Encrypted Media Extensions, Manifest v3, et maintenant WEI
Le web n’appartient pas à Google, et Google devrait s’occuper de QUIC et laisser HTTP tranquille
On nous dit que l’“Android WebView Media Integrity API a un périmètre limité”, mais je n’y vois aucun bénéfice pour l’utilisateur
Si une application veut embarquer un WebView, ne peut-elle pas simplement connecter à ce WebView une API qui utilise déjà l’API d’intégrité Android existante via du code natif ?
Pour moi, cela ressemble par exemple à une voie détournée pour empêcher des applications “modifiées” de lire YouTube sans publicité, et cette API ne profite pas à l’utilisateur
cela ne fait que rendre cela plus simple dans les applications basées sur WebView
les attaques de l’homme du milieu via un client interposé constituent une menace réelle en dehors des jardins clos d’Apple et de Google, et elles existent aussi un peu à l’intérieur
WEI était une tentative de résoudre un vrai problème
bien sûr, ses effets de bord ont pu être jugés inacceptables, ou ses inconvénients supérieurs à ses avantages, et c’est désormais une proposition morte
mais ici, au milieu d’une polémique exagérée, le problème de fond a été complètement enterré, et les gens ont lancé de partout des accusations d’intentions cachées et de malveillance générale
ce n’a pas été l’un des meilleurs moments de notre communauté
il est d’ailleurs ironique qu’une bonne partie de ces commentaires aient été écrits depuis des appareils Apple, objectivement encore moins favorables aux clients non standards
Je ne comprends pas comment c’est censé fonctionner
Il est dit que la “nouvelle Android WebView Media Integrity API permet aux fournisseurs de médias intégrés d’accéder à des réponses d’intégrité personnalisées contenant des évaluations de l’intégrité de l’appareil et de l’application, afin qu’ils puissent vérifier si le flux s’exécute dans un environnement sûr et de confiance, quelle que soit la boutique d’applications depuis laquelle l’application embarquante a été installée”
Mais cela ne s’applique qu’à l’API Android WebView, pas à un navigateur autonome comme Google Chrome
Ou alors cela revient simplement à la proposition initiale de Web Environment Integrity
Pourtant, personne n’est obligé d’utiliser l’API WebView, et Chromium est open source
Je ne vois pas ce qui empêcherait Bob, développeur Android malveillant, de compiler lui-même Chromium, de l’embarquer dans son application et de faire toutes les manigances sur les sites web que son esprit sournois désire
Autrement dit, si cela n’est intégré qu’à une API WebView spécialisée, un développeur malveillant ne peut-il pas simplement éviter cette API ?
Étape 2 : interdire les alternatives
Étape 3 : monétiser
Le titre est trompeur
La proposition destinée à Chrome a été abandonnée, mais elle continue en pratique d’être poussée pour l’API Android WebView, qui est en fait un wrapper autour de Chrome.
notamment parce qu’il est parfois utilisé pour des connexions intégrées dans des applications tierces douteuses
il existe un point de vue selon lequel cela peut se défendre
personnellement, je pense qu’on ne devrait pas autoriser les capacités de navigation générale dans une WebView intégrée, sauf si elle fait partie d’un navigateur autonome
en général, c’est utilisé comme une ruse pour intercepter du trafic qui devrait normalement aller vers le web ouvert
Une confirmation officielle a été publiée dans le fil de discussion public sur WEI : https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
Jusqu’à la prochaine tentative, il faut continuer à résister pour défendre l’internet ouvert
c’est épuisant
une grande entreprise peut simplement attendre que les gens se fatiguent
Le dépôt a été archivé et indique : “NOTE: This proposal is no longer pursued.”
https://github.com/RupertBenWiser/Web-Environment-Integrity
Il est très probable qu’ils aient déjà commencé à travailler sur une solution encore plus obscure
en lisant l’article, ce que je cherchais avant tout, c’était la preuve que Google, comme il le fait parfois, n’abandonnait pas vraiment l’orientation de l’idée, mais déployait plutôt une preuve de concept sur une autre infrastructure moins controversée pour la ressortir quand le moment serait plus favorable
par exemple après un gros incident de cybersécurité, donc c’est à garder en mémoire
c’est exactement ce qu’ils ont fait : ils l’ont renvoyée du côté de l’équipe Android et ont simplement promis de l’améliorer dans un petit sandbox moins controversé
publiquement, ils disent seulement qu’ils mettent “pour l’instant” en pause l’effort côté web
j’aimerais qu’ils redeviennent le Google qui défendait autrefois l’internet ouvert, et qu’ils cessent cette MBA-isation de tout ce qu’ils essaient en permanence
j’ai l’impression que c’est parti dans cette direction dès qu’ils ont abandonné “don’t be evil”, et c’est vraiment épuisant
au lieu de célébrer une victoire, les défenseurs de l’internet ouvert se retrouvent à célébrer seulement l’exécution d’un projet plus réduit et la mise en pause temporaire de sa version pour la plateforme web
de grands acteurs influents finissent par en orienter la direction pour les revenus de quelqu’un
je commence à penser qu’il faut désormais un hard fork du web
il existe déjà deux “zones” sur le web : le web où JavaScript est lourd et où les sites sont des apps, et le web centré sur les documents et les liens
on peut soutenir que le premier est un sur-ensemble du second, mais si ce camp continue à produire des initiatives hostiles aux utilisateurs et poursuit des objectifs finaux à l’opposé d’une plateforme ouverte, je ne vois pas quelle autre option réaliste il reste, à part une scission entre les acteurs principaux
Google avait réellement le pouvoir d’imposer cela
Le titre original était “Increasing trust for embedded media”
il existe une règle disant : « utilisez le titre original s’il n’est ni trompeur ni racoleur, et ne l’éditez pas »
https://news.ycombinator.com/newsguidelines.html