Google tue le DRM « Web Integrity » pour le Web, veut toujours une version Android

Google abandonne sa proposition d’« API d’intégrité de l’environnement Web » en tant que nouveau standard Web, même si les téléphones Android devront peut-être encore y faire face. Selon le document de proposition de Google, l’objectif principal du projet était de « permettre aux serveurs Web d’évaluer l’authenticité de l’appareil et la représentation honnête de la pile logicielle » : Google souhaitait essentiellement un contrôleur DRM pour le Web. Le projet a bénéficié d’une large couverture médiatique en juillet et a été largement critiqué .

Le plan sinistrement vague était de permettre aux navigateurs Web de détecter si votre ordinateur était « modifié » d’une manière que la page Web n’aimait pas. Vraisemblablement, cela peut aller d’un téléphone rooté/jailbreaké à l’installation d’un plug-in indésirable (lire : bloqueurs de publicités). Lorsque vous tentiez d’accéder à un contenu protégé, un navigateur prenant en charge l’API Web Integrity contactait d’abord un serveur « d’attestation d’environnement » tiers, et votre ordinateur devait passer une sorte de test. Après avoir fait scanner votre environnement local, euh… ? Les environnements de passage reçoivent un « IntegrityToken » signé qui pointe vers le contenu que vous souhaitez débloquer. Vous ramèneriez cela au serveur Web et obtiendriez enfin le contenu déverrouillé.

La proposition de Google n’a pas été bien accueillie. L’explicateur était plein d’informations contradictoires sur le degré d’invasion qu’il voulait et quels étaient ses objectifs. Google a promis qu’il n’était pas destiné à « appliquer ou interférer avec les fonctionnalités du navigateur, y compris les plugins et les extensions » (il s’agit d’une vague référence aux bloqueurs de publicités), mais le tout premier exemple de la proposition concernait également une mesure plus précise des impressions publicitaires. Ce qui est encore plus alarmant, c’est qu’il ne s’agissait pas d’une discussion : Google n’a jamais rendu public la fonctionnalité pour aucun type de retour, et la société était déjà activement en train de prototyper la fonctionnalité dans Chrome avant qu’Internet ne le découvre réellement.

Sur le blog des développeurs Android , curieusement, Google a officiellement annoncé la mort du standard Web proposé. La société déclare : « Nous avons entendu vos commentaires et la proposition d’intégrité de l’environnement Web n’est plus prise en compte par l’équipe Chrome. » Je pense que c’est la première fois que l’intégrité du Web est mentionnée dans un article de blog de Google, mais hourra. ! C’est mort. Passons au problème suivant :

Passer à Android pour garantir que YouTube Vanced ne sorte pas de sa tombe ?

Le projet n’est cependant pas totalement mort. Google s’est désormais tourné vers « une API expérimentale Android WebView Media Integrity [c’est nous qui soulignons]. » Contrairement à la version Web, qui aurait été un grand pas en avant pour les solutions DRM invasives, Android dispose déjà d’une attestation d’environnement, donc ce n’est pas le cas. on dirait que ça fait autant. Google a déclaré que l’inspiration pour le projet Web Integrity original était l’API Play Integrity d’Android , qui analyse déjà votre téléphone pour les privilèges root et refuse l’accès à des éléments tels que les jeux, les médias et les applications bancaires. Google souhaite désormais pouvoir le faire via des WebViews Android intégrés (contenu Web affiché dans les applications), affirmant que les « fournisseurs de contenu multimédia » seraient intéressés par une telle chose.

Si vous êtes Spotify ou YouTube, vous pouvez déjà bloquer les appareils modifiés au niveau de l’application avant même le démarrage de la WebView intégrée, via l’ API Play Integrity . Google dispose également d’un DRM Android non amovible préinstallé appelé « Widevine », spécialement conçu pour la lecture multimédia. Netflix exige la préinstallation de Widevine sur les appareils afin d’afficher du contenu HD, et les problèmes avec le DRM sont un problème de support courant .

Google voit évidemment que cette proposition n’est pas appréciée, donc son pivot vers un composant Android WebView suggère qu’il a un besoin interne spécifique de verrouiller les WebViews avec DRM. Google est cependant si étrangement vague à propos de ces projets qu’il est difficile de savoir exactement quelle est l’intention de l’entreprise. Le billet de blog note que même si le système WebView d’Android apporte « beaucoup de flexibilité… il peut être utilisé comme moyen de fraude et d’abus, car il permet aux développeurs d’applications d’accéder au contenu Web et d’intercepter ou de modifier les interactions des utilisateurs avec celui-ci. Même si cela présente des avantages lorsque les applications intègrent leur propre contenu Web, cela n’interdit pas aux mauvais acteurs de modifier le contenu et, par procuration, de déformer sa source.

Outre les croque-mitaines de logiciels malveillants habituels, cela ressemble beaucoup au cas d’utilisation de YouTube Vanced, une application YouTube Android modifiée ( maintenant morte ). Vanced a utilisé WebView et a incité YouTube à lire des vidéos sans publicité et à débloquer des fonctionnalités YouTube Premium telles que la lecture en arrière-plan. Étant donné que Vanced n’était qu’une application, elle ne nécessitait pas de root et n’était pas arrêtée par l’API Play Integrity. Permettre à YouTube d’accéder à votre téléphone via WebView semble cependant être quelque chose qui pourrait arrêter ces clients « alternatifs ». Google est devenu de plus en plus hostile envers les bloqueurs de publicités ces dernières années, et bien que le service juridique de Google ait déjà tué YouTube Vanced avec une lettre de cessation en 2022, demander au service technique de mettre un enjeu au cœur des clients modifiés semble être la prochaine étape. étape plausible.