Experimentelle Android WebView Media Integrity API Anfang nächsten Jahres
(android-developers.googleblog.com)- Die Android WebView Media Integrity API wird Anfang nächsten Jahres experimentell mit ausgewählten Medienanbietern pilotiert, damit in Apps eingebettete Medienanbieter die Wiedergabeumgebung verifizieren können
- Attestation-Dienste wie die Play Integrity API oder Firebase App Check gibt es bereits, aber die Weitergabe dieser Informationen an Anbieter eingebetteter Inhalte ist weder einfach noch gut skalierbar
- Das Chrome-Team prüft den Vorschlag zu Web Environment Integrity nicht weiter; die neue API ist auf WebView innerhalb von Android-Apps und eingebettete Medien wie Streaming-Video und -Audio beschränkt
- Die Flexibilität von WebView ist für die App-Integration nützlich, ermöglicht App-Entwicklern aber auch Zugriff auf Webinhalte und Nutzerinteraktionen oder deren Veränderung, wodurch Potenzial für Betrug und Missbrauch entsteht
- Die Integritätsantwort enthält nur Geräte- und App-Bewertungen und keine Nutzer- oder Gerätekennungen; Apps können auf Wunsch den Paketnamen aus der Bewertung ausschließen
Neue WebView-API zur Verifizierung eingebetteter Medien
- Android WebView ist eine leistungsfähige und flexible API, mit der Android-Entwickler Medien in ihre Apps einbetten können
- Anbieter eingebetteter Medien müssen sicherstellen können, dass ihre Medien in einer vertrauenswürdigen und sicheren Umgebung wiedergegeben werden
- Android-App-Entwickler und SDK-Anbieter können bereits Attestation-Dienste nutzen, die Serveranfragen einer App verifizieren und dabei die Privatsphäre der Nutzer wahren
- App-Entwickler können Informationen aus solchen Attestation-Diensten auch heute schon an Anbieter eingebetteter Inhalte weitergeben, doch dieser Prozess ist nicht einfach und nicht skalierbar
- Um diese Einschränkung zu verringern, wird Anfang nächsten Jahres mit ausgewählten Anbietern eingebetteter Medien ein Pilot der experimentellen Android WebView Media Integrity API durchgeführt
Begrenzterer Umfang als Web Environment Integrity
- Das Chrome-Team prüft den Web Environment Integrity proposal nicht weiter
- Die Android WebView Media Integrity API zielt auf einen engeren Umfang ab
- Sie gilt nur für in Apps eingebettete Android WebViews
- Sie erweitert bestehende Funktionen auf Android-Geräten mit Google Mobile Services (GMS)
- Es gibt keine Pläne, sie außerhalb eingebetteter Medien wie Streaming-Video und -Audio bereitzustellen
- Es gibt auch keine Pläne, sie außerhalb von Android WebView bereitzustellen
Flexibilität von WebView und Missbrauchspotenzial
- Die Android WebView API ermöglicht App-Entwicklern, Webseiten anzuzeigen und Medien einzubetten, und lässt sich dank UI-Steuerung und erweiterten Konfigurationsoptionen nahtlos in Apps integrieren
- Diese Flexibilität ist nützlich, wenn Apps eigene Webinhalte einbetten, sie kann App-Entwicklern aber auch erlauben, auf Webinhalte und Nutzerinteraktionen zuzugreifen, sie abzufangen oder zu verändern
- Daraus können Risiken wie Veränderung von Inhalten oder eine falsche Zuordnung der Herkunft entstehen
Integritätsantwort und Datenschutzbedingungen
- Die neue API stellt Anbietern eingebetteter Medien eine angepasste Integritätsantwort bereit
- Die Antwort enthält eine Bewertung der Geräteintegrität und eine Bewertung der App-Integrität
- Sie kann bestätigen, ob ein Stream in einer sicheren und vertrauenswürdigen Umgebung läuft, unabhängig davon, aus welchem App Store die einbettende App installiert wurde
- Die Bewertung besteht aus einfachen Metadaten mit geringer Entropie über App und Gerät
- Sie enthält keine Nutzerkennungen oder Gerätekennungen
- Anders als Apps und Spiele, die die Play Integrity API verwenden, erhalten Medienanbieter keinen Play-Lizenzstatus der App
- Apps können auf Wunsch ihren eigenen Paketnamen aus der Bewertung ausschließen
- Das Android-Team möchte das vielfältige Ökosystem für Medieninhalte in Android-Apps erhalten und nimmt von Medieninhalteanbietern, die am Early-Access-Programm Anfang nächsten Jahres interessiert sind, Interessensbekundungen entgegen
1 Kommentare
Hacker-News-Meinungen
WEI selbst wurde bereits in mehreren Threads behandelt, und es gibt viele lesenswerte Diskussionen
(Juli 2023, 456 Kommentare) https://news.ycombinator.com/item?id=36854114 - "Google's nightmare Web Integrity API wants a DRM gatekeeper for the web"
(Juli 2023, 431 Kommentare) https://news.ycombinator.com/item?id=36817305 - "Web Environment Integrity API Proposal"
(Juli 2023, 434 Kommentare) https://news.ycombinator.com/item?id=36875940 - "Unpacking Google’s Web Environment Integrity specification"
(Juli 2023, 111 Kommentare) https://news.ycombinator.com/item?id=36857676 - "So, you don't like a web platform proposal" - die Sicht eines Google-Mitarbeiters darauf, wie die Leute auf den Vorschlag hätten reagieren sollen
(August 2023, 100 Kommentare) https://news.ycombinator.com/item?id=36960882 - "Web Environment Integrity: Locking Down the Web"
Die Techniker kamen mit Argumenten in gutem Glauben, aber die Gegenseite führte einen böswilligen Kampf um das Image, und sie liefen genau hinein
Die Nachricht, dass Google die Web Integrity API nicht weiterverfolgen will, ist für die Neutralität des offenen Webs sehr positiv
Allerdings hat Google sich bislang stark von eigenen Interessen statt vom Nutzen des gesamten Webs leiten lassen; daher muss man abwarten, wodurch es ersetzt wird, und das dürfte nicht lange dauern
Wie bei FLoC und Topics liegt der Verdacht nahe, dass eine Spezifikation vorbereitet wird, die oberflächlich weniger störend wirkt, tatsächlich aber für Nutzer genauso schädlich ist; verdächtig ist auch, dass der Zeitpunkt mit der jüngsten Ankündigung zusammenfällt, die Abrechnung von Werbung von Klicks auf Impressionen umzustellen
Google wirkte nicht wie ein vertrauenswürdiger Verwalter des Webs, und auf diesem apparent victory sollte man sich nicht ausruhen
Auch künftig ist Vielfalt bei Browsern und Browser-Engines wichtig, wenn verhindert werden soll, dass eine einzelne Instanz die Zukunft des Webs kontrolliert
Wir müssen aufhören, einen globalen Datenbroker, der Werbetreibende auf der ganzen Welt mit Daten versorgt, als legitimen und gutwilligen Verwalter von Web-Technologien zu sehen
Zunächst einmal verletzt das die Trennung der Belange von Server und Client
Der Client ist ein User Agent, er soll also tun, was der Nutzer will, nicht was der Server will
Dieses grundlegende Missverständnis und die Verzerrung der Perspektive sind Teil des Problems
Um HTTP(S) und verwandte Technologien als freie und offene Protokolle für alle zu erhalten, muss Google aus dem Entscheidungsprozess ausgeschlossen werden
Hinter Encrypted Media Extensions, Manifest v3 und nun WEI stand jeweils Google
Das Web gehört nicht Google; Google soll sich um QUIC kümmern und HTTP in Ruhe lassen
Es heißt, die „Android WebView Media Integrity API sei eng begrenzt“, aber ich sehe keinen Nutzen für die Nutzer
Wenn eine App WebView einbetten will, könnte sie doch per nativem Code eine API an diese WebView hängen, die die bestehende Android Integrity API nutzt
Für mich wirkt das wie ein Umweg, um zum Beispiel „gehackte“ Apps zu blockieren, die YouTube ohne Werbung abspielen, und diese API nützt den Nutzern nicht
Das hier macht es für WebView-basierte Apps nur einfacher
Man-in-the-Middle-Angriffe über eingeschleuste Clients sind außerhalb der Walled Gardens von Apple und Google eine reale Bedrohung, und selbst innerhalb davon gibt es sie in gewissem Umfang
WEI war ein Versuch, ein reales Problem zu lösen
Natürlich könnten die Nebenwirkungen unakzeptabel gewesen sein, und der Schaden könnte den Nutzen überwogen haben; inzwischen ist der Vorschlag tot
Aber hier wurde das zugrunde liegende Problem in einer überhitzten Debatte völlig begraben, und die Leute warfen mit versteckten Motiven und allgemeiner Böswilligkeit nur so um sich
Das war nicht der beste Moment unserer Community
Ironisch ist auch, dass viele dieser Kommentare auf Apple-Geräten verfasst wurden, die gegenüber nicht standardmäßigen Clients objektiv noch unfreundlicher sind
Ich verstehe nicht, wie das funktionieren soll
Es heißt: „Die neue Android WebView Media Integrity API gibt eingebetteten Medienanbietern Zugriff auf eine angepasste Integritätsantwort mit Geräte- und App-Integritätsurteilen, sodass sie feststellen können, ob ein Stream in einer sicheren und vertrauenswürdigen Umgebung läuft, unabhängig davon, aus welchem App Store die einbettende App installiert wurde“
Aber das gilt nur für die Android WebView API, nicht für eigenständige Browser wie Google Chrome
Andernfalls wäre man wieder beim ursprünglichen Web-Environment-Integrity-Vorschlag
Allerdings muss niemand zwingend die WebView API verwenden, und Chromium ist Open Source
Ich sehe nicht, was den böswilligen Android-Entwickler Bob davon abhalten soll, Chromium selbst zu kompilieren, in seine App zu bundlen und damit alle möglichen Website-Spielchen zu treiben, nach denen seinem finsteren Herzen der Sinn steht
Anders gesagt: Wenn das nur in eine spezielle WebView API eingebaut wird, kann ein böswilliger Entwickler diese API doch einfach meiden, oder?
Schritt 2: Alternativen verbieten
Schritt 3: monetarisieren
Der Titel ist missverständlich
Der Vorschlag für Chrome wurde zwar verworfen, aber für die Android WebView API, die im Grunde ein Wrapper um Chrome ist, wird er weiterhin vorangetrieben.
Weil es manchmal für eingebettete Logins in fragwürdigen Drittanbieter-Apps verwendet wird.
Es gibt durchaus eine Perspektive, aus der man das als vernünftig ansehen kann.
Persönlich finde ich: Solange es nicht Teil eines unabhängigen Browsers ist, sollte ein eingebettetes WebView keine allgemeinen Browsing-Funktionen erlauben.
Meist wird es als Trick genutzt, um Traffic abzufangen, der eigentlich ins offene Web gehen sollte.
Im öffentlichen WEI-Diskussionsthread gab es eine offizielle Bestätigung: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
Bis zum nächsten Mal müssen wir weiter für das offene Internet dagegenhalten
Das ist ermüdend.
Als großes Unternehmen kann man einfach warten, bis die Leute müde werden.
Das Repository wurde archiviert und enthält den Hinweis „NOTE: This proposal is no longer pursued.“
https://github.com/RupertBenWiser/Web-Environment-Integrity
Sehr wahrscheinlich haben sie bereits mit der Arbeit an einer noch schwerer durchschaubaren Lösung begonnen.
Beim Lesen des Artikels habe ich zuerst nach Belegen dafür gesucht, dass Google nicht die grundsätzliche Richtung der Idee aufgibt, wie sie es gelegentlich tun, sondern einen Proof of Concept in einer weniger kontroversen Infrastruktur ausrollt und ihn wieder hervorholt, wenn das Timing günstiger ist.
Zum Beispiel könnte man auf die Zeit nach einem großen Cybersicherheitsvorfall abzielen; das sollte man im Hinterkopf behalten.
Genau das haben sie tatsächlich getan: Sie haben es an das Android-Team zurückgegeben und lediglich versprochen, es in einer kleineren, weniger kontroversen Sandbox zu verbessern.
Öffentlich sagen sie nur, dass sie die Bemühungen fürs Web „vorerst“ einstellen.
Ich wünschte, Google würde zu dem Vorkämpfer für das offene Internet zurückkehren, den ich früher kannte, und von der MBA-isierung all dessen abrücken, was sie ständig versuchen.
Seit dem Moment, in dem sie „don’t be evil“ abgelegt haben, fühlt es sich an, als sei es in diese Richtung gegangen, und es ist wirklich ermüdend.
Statt einen Sieg zu feiern, können die Leute aufseiten des offenen Internets nur die Umsetzung eines kleineren Projekts und die vorübergehende Pause der Web-Plattform-Version feiern.
Große, einflussreiche Akteure lenken die Richtung am Ende zugunsten irgendwelcher Erlöse.
Langsam denke ich, dass wir einen Hard Fork des Webs brauchen.
Schon jetzt gibt es im Web zwei „Zonen“: ein JavaScript-lastiges Web, in dem Websites Apps sind, und ein Web, das sich um Dokumente und Links dreht.
Man kann behaupten, Ersteres sei eine Obermenge des Letzteren, aber wenn aus diesem Lager immer wieder nutzerfeindliche Versuche kommen und das Endziel dem einer offenen Plattform diametral entgegensteht, weiß ich nicht, welche realistische Alternative es dazu gibt, dass sich die wichtigsten Akteure trennen.
Google hatte die Macht, das tatsächlich durchzudrücken.
Der ursprüngliche Titel lautet „Increasing trust for embedded media“.
Es gibt eine Guideline: „Wenn der Originaltitel nicht irreführend oder Clickbait ist, verwenden Sie ihn und bearbeiten Sie ihn nicht.“
https://news.ycombinator.com/newsguidelines.html