- Es ist weit verbreitet, die Webplattform als etwas zu sehen, das auf standardisierten APIs überall gleich funktioniert. Tatsächlich gibt es jedoch viele APIs, die von der jeweiligen Infrastruktur der Browser-Anbieter abhängen.
- Geolocation, Speech, Push, Payments, Passkeys usw. wirken oberflächlich wie Webstandards, rufen intern jedoch Dienste von Google, Apple oder Microsoft auf.
- Selbst bei demselben API-Aufruf unterscheiden sich Genauigkeit, Verfügbarkeit, regionale Inkompatibilitäten und Datenschutzrichtlinien je nach Browser erheblich, und Entwickler machen sich davon oft abhängig, ohne es zu bemerken.
- Die auf große Anbieter ausgerichtete Standardisierungsstruktur erhöht die Hürden für kleinere Browser und das Open-Source-Ökosystem und verstärkt faktisch einen Lock-in-Effekt.
- Entwickler sollten solche APIs nicht als reine „Webstandards“, sondern als Abstraktionsschicht für Anbieter-Dienste verstehen und Datenschutzhinweise, alternative Designs und browserübergreifende Tests mit einplanen.
Allgemeine Wahrnehmung der Webplattform und ihre tatsächliche Struktur
- Die Webplattform wird als integriertes System auf Basis standardisierter Spezifikationen wahrgenommen, und bei Browsern mit derselben Engine wird identisches Verhalten erwartet.
- In Wirklichkeit hängen viele APIs von browser-spezifischen Implementierungen sowie von Drittdiensten, proprietärer Infrastruktur und internen Systemen der Anbieter ab.
- Anders als die standardisierte Schnittstelle unterscheiden sich die Implementierungsdetails stark je nach Entscheidungen des Browser-Anbieters.
Geolocation API und die tatsächliche Herkunft von Standortdaten
- Die Geolocation API bietet eine standardisierte Schnittstelle, die eigentlichen Standortdaten werden jedoch über verschiedene Wege ermittelt.
- Nutzung von Standortdiensten des Betriebssystems und GPS
- Standortschätzung auf Basis von Wi-Fi-AP-Informationen
- Abfrage von Standortdatenbanken auf Basis der IP-Adresse
- Chrome verwendet Google Location Services, Safari Apple-Server, Firefox seit 2024 Google-Dienste.
- Bei der Nutzung von Standortdaten können Nutzerdaten an Server bestimmter Anbieter übertragen werden, ohne dass dies in der Browser-Oberfläche ausdrücklich sichtbar ist.
- Wenn der Zugriff auf Anbieter-Dienste in bestimmten Regionen blockiert ist, funktioniert die Funktion möglicherweise nicht korrekt.
Speech Synthesis und Sprachverarbeitungs-Infrastruktur
- Die Sprachsynthese der Web Speech API verwendet je nach Browser, Betriebssystem und Gerät unterschiedliche Engines.
- Die Speech Synthesis API ist zwar eine standardisierte Schnittstelle, die Sprachdaten werden aber von einer TTS-Engine des Betriebssystems oder über Cloud-Server verarbeitet.
- Chrome nutzt lokal und Cloud parallel, Safari verwendet die Sprach-Engine des Betriebssystems.
- Einige hochwertige Stimmen erfordern für Cloud-basierte Verarbeitung eine Online-Übertragung, wodurch Nutzerdaten an Server übertragen werden.
- Es besteht das Risiko, dass persönliche Nachrichten oder sensible Informationen ungewollt an externe Server gesendet werden.
- Außerdem kann eine im Test gewählte Stimme in der Umgebung der Nutzer gar nicht vorhanden sein.
Speech Recognition und Echtzeit-Übertragung von Sprache
- Die Speech Recognition API ist größtenteils von Cloud-Erkennungsdiensten abhängig.
- Chrome nutzt Google, Safari Apple, Edge Dienste aus dem Azure-Umfeld.
- Ab Chrome 139 ist mit der Option
processLocally lokale Verarbeitung möglich, sie ist jedoch nicht der Standard und außerdem auf Chrome beschränkt.
- Genauigkeit und Sprachunterstützung unterscheiden sich je nach Qualität der Modelle des jeweiligen Anbieters.
Passkeys und die tatsächliche Grundlage von WebAuthn: Abhängigkeit vom Browser-Ökosystem
- Die WebAuthn API steht für passwortlose Authentifizierung, ist in der Praxis jedoch an die Infrastruktur der Passwort-Manager des Browsers gebunden.
- Chrome verwendet Google Password Manager, Safari iCloud Keychain, Edge das Microsoft-Konto.
- Polypane und andere unterstützen wegen Einschränkungen von Electron keine Passkeys; Erweiterungen wie 1Password sind erforderlich.
- Wie Anmeldedaten gespeichert, synchronisiert und wiederhergestellt werden, hängt vollständig von der Implementierung des jeweiligen Anbieters ab.
Payment Request API und Abhängigkeit von Zahlungsanbietern
- Die Payment Request API wirkt wie ein Standard, tatsächlich hängt ihre Funktionsfähigkeit jedoch von den Partnern des jeweiligen Anbieters ab.
- Chrome setzt auf Google Pay, Safari auf Apple Pay, Edge auf Microsoft-Integration, Firefox unterstützt sie nicht.
- Regionale Unterstützung, UX und zusätzliche Anforderungen an Benutzereinstellungen unterscheiden sich je nach Browser.
- Dadurch sind für jede Zahlungsmethode separate Verträge und eigene Logik erforderlich.
Push API und anbieterspezifische Benachrichtigungsnetzwerke
- Die Push API ist standardisiert, aber die tatsächliche Benachrichtigungszustellung nutzt je nach Browser unterschiedliche Server-Infrastruktur.
- Chrome/Edge verwenden FCM, Safari APNs, Firefox den Mozilla Push Service.
- Übertragungsbeschränkungen, Nachrichtengröße, Offline-Verarbeitung und Datenschutzrichtlinien unterscheiden sich je nach Dienst.
- Fällt die Infrastruktur eines Anbieters aus, kann die Push-Funktion des betreffenden Browsers insgesamt beeinträchtigt werden.
Medien-APIs, Codecs und DRM-Probleme
- Media Source Extensions (MSE) und Encrypted Media Extensions (EME) sind Standards, die tatsächliche Unterstützung unterscheidet sich jedoch je nach Codec- und DRM-Lizenzen.
- Chrome, Edge und Firefox verwenden Widevine, Safari FairPlay und sind damit von vollständig proprietären Technologien abhängig.
- Die bevorzugten Codecs und Strategien unterscheiden sich je nach Browser-Anbieter.
- Aufgrund von DRM-Lizenzkosten und technischen Einschränkungen ist Unterstützung für kleinere Browser schwer umzusetzen.
Das Auftreten browserinterner AI-APIs: eine neue proprietäre Struktur
- Chrome experimentiert mit AI-APIs auf Basis von Gemini Nano (Zusammenfassung, Übersetzung, Korrektur usw.).
- Die Ausführung erfolgt lokal, daher werden keine Daten übertragen; allerdings sind Modellgröße (ca. 4 GB) und GPU-Anforderungen hoch, und es handelt sich um ein proprietäres Google-Modell.
- Andere Browser müssten eigene Modelle entwickeln; kleinere Browser oder Open-Source-Projekte können ein gleichwertiges Modell weder beschaffen noch pflegen und sind dadurch nicht konkurrenzfähig.
- Das schafft eine neue Form von Anbieterabhängigkeit auf AI-Basis.
Warum das wichtig ist
- Portabilitätsproblem: Selbst derselbe Code kann je nach Browser, Region und Umgebung unterschiedlich gut funktionieren.
- Datenschutzrisiko: Sprach-, Standort- und Push-Daten können ungewollt an Server von Anbietern übertragen werden.
- Ungleichgewicht in der Standardisierung: Große Unternehmen treiben Spezifikation und Implementierung voran und machen ihre eigene Infrastruktur faktisch zur Voraussetzung, wodurch kleinere Browser ausgeschlossen werden.
- Auswirkungen auf Entwickler: Die Funktionen sind nützlich, aber man muss erkennen, dass es sich um Abhängigkeiten von Diensten statt um reine Standards handelt.
Welchen Ansatz Entwickler wählen sollten
- APIs als Abstraktionsschicht für Anbieter-Dienste verstehen und Tests, Dokumentation sowie Alternativen vorbereiten.
- Mit graceful degradation planen, um Unterschiede in der Funktionalität aufzufangen.
- Datenschutz-Transparenz sicherstellen: klar angeben, dass Daten an Server Dritter übertragen werden könnten.
- Anbieterabhängigkeiten managen: Es braucht Reaktionspläne für Dienstabschaltungen oder Richtlinienänderungen.
- Mit Tests nach Browser und Region Qualitätsunterschiede überprüfen.
- Durch strategische Entscheidungen die Abhängigkeit von einzelnen Anbietern minimieren.
Das Web, wie wir es uns vorstellen, vs. das Web, das es tatsächlich ist
- Standardisierte API-Aufrufe sind zwar gleich, aber Datenfluss, Genauigkeit, regionale Unterstützung, Datenschutz und Kostenstruktur unterscheiden sich je nach Browser.
- Ein Aufruf von
navigator.geolocation.getCurrentPosition() ist faktisch ein Aufruf von Standortdiensten von Google oder Apple.
- Die Standardspezifikation definiert nur die Schnittstelle, das tatsächliche Verhalten hängt von Infrastruktur und Richtlinien der Anbieter ab.
- Ein API-Aufruf bedeutet damit auch, Server, Richtlinien und Geschäftsmodell eines bestimmten Anbieters zu nutzen.
- Die Webplattform ist leistungsfähig, in der Realität jedoch stärker fragmentiert und stärker von Anbietern geprägt.
- Entwickler müssen die Grenze zwischen Standard und Implementierung klar verstehen und entsprechend entwerfen.
Noch keine Kommentare.