Japan: Apple muss Browser-Engine-Verbot bis Dezember aufheben
(open-web-advocacy.org)- Die japanische Regierung hat kürzlich das Smartphone-Gesetz verabschiedet und damit das Verbot von Browser-Engines Dritter auf Apples iOS ausdrücklich untersagt
- Durch die bisherige Erzwingung der WebKit-Engine wurde der Browser-Wettbewerb auf iOS faktisch blockiert und die Wettbewerbsfähigkeit von Web-Apps geschwächt
- Die neuen Leitlinien stellen klar, dass Apple auch technisch oder wirtschaftlich unrealistische Behinderungen nicht zulassen darf
- Zudem muss der Zugang zu OS-APIs für Browser funktional gleichwertig gewährleistet sein, und diskriminierende Leistungseinbußen sind unzulässig
- Mit dem Inkrafttreten des japanischen Gesetzes entsteht zusammen mit der EU und dem Vereinigten Königreich ein regulatorisches Umfeld zur Wiederherstellung des Browser-Wettbewerbs; 2026 könnte zum Wendepunkt werden
Japan verlangt die Aufhebung von Apples Browser-Engine-Verbot
Japan hat kürzlich offiziell das „Gesetz zur Förderung des Wettbewerbs bei Smartphone-Software“ verabschiedet und damit Maßnahmen in Kraft gesetzt, die Apples langjährige Politik, Browser-Engines Dritter auf iOS zu verbieten, ausdrücklich untersagen
Stand des Browser-Engine-Verbots
- Bisher erlaubte Apple ausschließlich die WebKit-Engine, wodurch Firefox, Chrome, Edge, Opera, Brave, Vivaldi und alle anderen wichtigen Browser-Engines auf iOS faktisch ausgeschlossen wurden
- Dadurch wurde der Browser-Wettbewerb praktisch blockiert, und Web-Apps konnten APIs oder Leistung nicht nutzen, die nötig wären, um mit nativen Apps auf Augenhöhe zu konkurrieren
Japans Gesetzgebung und Leitlinien
- Das Gesetz wurde auf Grundlage eines Berichts des Hauptquartiers für Wettbewerb auf digitalen Märkten konzipiert; auch die Beratung von Open Web Advocacy floss ein
- Kürzlich wurden die Leitlinien zum Mobile Software Competition Act (MSCA) veröffentlicht, die die praktische Auslegung und Durchsetzung des Gesetzes klarer darlegen
Verbot der Behinderung alternativer Browser-Engines
- Die Leitlinien verbieten ausdrücklich jede Handlung, die die Einführung von Browser-Engines Dritter behindert oder beeinträchtigt
- Dazu zählen etwa übermäßige technische Beschränkungen für App-Anbieter, zusätzliche Kostenlasten oder Maßnahmen, die Nutzer von alternativen Browsern fernhalten
- Bei der Bewertung einer Behinderung zählt nicht nur ein ausdrücklich ausgesprochenes Verbot durch den Anbieter, sondern auch ein Fall, in dem die reale Einführungswahrscheinlichkeit deutlich sinkt
- Diese Bestimmung bedeutet, dass Apple selbst bei nur nomineller Zulassung keine Situation schaffen darf, in der die Nutzung faktisch unmöglich oder wirtschaftlich bedeutungslos ist
Funktionale Gleichwertigkeit beim Zugang zu OS-APIs
- Der MSCA schreibt vor, beim Zugang zu OS-APIs funktional gleichwertigen Zugang zu gewährleisten
- Alternative APIs sind zulässig, gelten jedoch nicht als funktional gleichwertig, wenn sie in der Praxis deutlich schlechtere Leistung bieten
- Das heißt: Auch wenn der technische Ansatz unterschiedlich ist, müssen Browser Dritter denselben Grad an Leistung und Zugänglichkeit erhalten wie Apple oder andere benannte Anbieter
Pflicht zur Browser-Auswahlmaske (Choice Screen)
- Das Gesetz verpflichtet zur Bereitstellung einer Auswahlmaske (Choice Screen) für Browser (und andere Software)
- Die Vorgaben gehen über die der EU hinaus: Die Auswahlmaske muss unmittelbar nach der ersten Aktivierung angezeigt werden
- Bei der ersten Einrichtung des Smartphones oder beim ersten Start der jeweiligen App muss der Nutzer zur Auswahl bestimmter Software aufgefordert werden
Weitere Entwicklung
- Der Mobile Software Competition Act soll im Dezember 2025 in Kraft treten
- Japan reiht sich damit neben der EU und dem Vereinigten Königreich unter die Rechtsräume ein, in denen Apple Browser-Engines Dritter zulassen muss
- Es wird erwartet, dass Japan sich bei der Vorbereitung der Durchsetzung an den Regulierungserfahrungen Europas und des Vereinigten Königreichs orientiert
- Wie die Beispiele aus der EU und dem Vereinigten Königreich zeigen, dürfte die tatsächliche Durchsetzung ein langfristiger und komplexer Prozess werden
Fazit und Implikationen
- Japan, die EU und das Vereinigte Königreich treiben alle die Wiederherstellung echten Browser-Wettbewerbs auf iOS voran, indem sie Apple zur Unterstützung von Browser-Engines Dritter verpflichten
- 2026 könnte ein Wendepunkt für die Struktur des Browser-Markts werden
- Der endgültige Erfolg wird vom Durchsetzungswillen der Regulierungsbehörden und von Apples tatsächlichen Verbesserungsbemühungen abhängen
- Hervorgehoben wird die Rolle der japanischen Regierung und der beteiligten Organisationen, die sich über lange Zeit für bessere Wettbewerbsbedingungen für Browser und Web-Apps eingesetzt haben
7 Kommentare
Hm … Ich finde es zwar schade, aber es ist schon praktisch, wenn alle Browsing-Funktionen über dieselbe zugrunde liegende Bibliothek laufen, weil dann eine konsistente Regelung ohne Umgehungsmöglichkeit besteht, sobald das System eine bestimmte URL blockiert – auch für die internen Browsing-Funktionen aller Apps.
Es wird erwartet, dass AI-Browser stark zulegen.
Aus Entwicklersicht bedeutet das wohl, dass es noch mehr Umgebungen zu berücksichtigen gibt, haha..
Jetzt muss man endlich nach Webstandards entwickeln. Fehlende Funktionen sollte man nicht aktiv einsetzen.
Es sieht zwar nach vielen aus, aber am Ende sind es doch nur Firefox- und Chromium-Engines, oder?
Schon die Liste der in der Beschreibung des Verbots erwähnten Engines ist ziemlich schwindelerregend @_@
Hacker-News-Kommentare
Alle reden über Chrome, aber ich habe auf Android Chrome deaktiviert und nutze Firefox. Mit uBlock Origin auf Firefox Mobile fühlt sich das fast wie das Desktop-Web an. Nicht nur Werbung lässt sich blockieren, sondern mit RegEx-Regeln wie
:has-textauch Elemente, die mich nicht interessieren, sofort ausblenden. Chrome kann so etwas inzwischen nicht einmal mehr auf dem Desktop. Ich überlege schon ernsthaft, komplett auf Android als Hauptgerät umzusteigen. Nur wegen iMessage ist der Komfort, direkt vom MacBook auf Chats zu antworten, so groß, dass ich mich nicht leicht davon lösen kann. Davon abgesehen ist Android insgesamt deutlich besser. Von der iOS-Tastatur oder Siri will ich gar nicht erst anfangenDie Kombination aus FF und uBO ist die Killer-App, wegen der ich bei Android geblieben bin. Wenn Apple das zugelassen hätte, wäre ich schon längst gewechselt. Hast du mal messages.google.com in Betracht gezogen? Dafür braucht man Googles Nachrichten-App, nicht Samsung Messages, und man kann auf dem Desktop SMS und RCS nutzen, also ziemlich genau ein iMessage-Ersatz
Auf Firefox Mobile ist auch die Erweiterung consent-o-matic wirklich nützlich. Sie klickt fast alle Cookie-Banner automatisch weg, sodass man sich mobil nicht jedes Mal selbst darum kümmern muss, was viel angenehmer ist
Ich nutze auch https://messages.google.com, um mir eine Android-basierte Desktop-iMessage-ähnliche Umgebung zu bauen. Vielleicht passt das ja auch für deinen Anwendungsfall? Ich selbst nutze iMessage nicht, daher kann es sein, dass ich da etwas übersehe
Wenn es auch einfach ohne iMessage und nur mit SMS geht, dann ermöglicht KDE Connect hervorragendes Desktop-Messaging mit Android (funktioniert unter Linux, Windows und macOS, auch wenn es je nach Plattform Funktionsunterschiede gibt, SMS wird aber überall unterstützt). https://kdeconnect.kde.org/
Es wirkt, als hätte Japan aus Apples Fallbeispiel der „wortklauberischen Compliance“ in der EU gelernt. Wenn Apple auch hier wieder so auftritt, hoffe ich, dass das Unternehmen in Japan ebenfalls mit einer echten Geldstrafe getroffen wird, die wirklich weh tut. Ich denke eher nicht in „if“, sondern in „when“
Ich stelle mir sogar ein Verkaufs- und Importverbot vor, und frage mich, wie lange Apple seine Apple Stores schließen müsste, bis es in die Knie geht
Ich mag den walled garden, der mich davor bewahrt, selbst Mist zu bauen. Ich bin dankbar, dass Apple meine Standortdaten nicht einfach weitergibt oder irgendein seltsames Monarch mich verfolgt und ich mir weniger Sorgen um Privatsphäre-Lecks machen muss. (+4500 upvotes) Auf Reddit fand ich es immer verdächtig, dass anti-Apple-Schlagzeilen +30.000 Upvotes bekamen, während pro-Apple-Kommentare im Vergleich viel weniger bekamen. Ich habe mich oft gefragt, ob da nicht Marketingteams oder Trollfarmen Reputationsmanagement betrieben haben
Wenn diese globale Gesetzesbewegung zu einem offeneren App-Ökosystem auf iOS führt, wäre das sehr zu begrüßen. BrowserEngineKit ist nur ein dünner Wrapper um XPC und das iOS-Erweiterungssystem. Wenn XPC eine offene API wäre und Apple auch ohne seine Erlaubnis JIT in isolierten Subprozessen zulassen würde, wäre die Entwicklung viel angenehmer. Zum Beispiel könnte eine Messenger-App einen separaten Subprozess für die Verarbeitung nicht vertrauenswürdiger Eingaben nutzen (iMessage macht das bereits), instabile Komponenten einer App isolieren, um Usability und Crash-Recovery zu verbessern, Retro-System-Emulatoren deutlich beschleunigen, WASM auf iOS ermöglichen, und Browser könnten XPC ebenfalls ohne spezielle Zweck-APIs nutzen. Das Problem ist: Wenn so etwas möglich wird, ist es nach der App-Store-Prüfung leicht, Code in eine App zu laden, der mit nativer Geschwindigkeit läuft, und wie wir alle wissen, würde dann angeblich das Unheil über uns hereinbrechen
Wenn dieses „Unheil“ kommt, möchte ich dabei zusehen, wie die Leute auf Seiten wie MacRumors ausrasten. Es fällt schwer, naiv zu glauben, Apple würde keine Seiten unterstützen, die im Interesse des eigenen wirtschaftlichen Vorteils bestimmte Narrative im Internet vorantreiben. Zum Beispiel wird dort praktisch ständig die absurde Behauptung wiederholt, die Freiheit, sein Telefon frei zu nutzen, gefährde die Sicherheit und Privatsphäre aller
Dadurch würde die Last der Malware-Abwehr auf Systemebene sehr stark auf die App-Sandbox verlagert. Tatsächlich war die Sandbox auch bisher nur eine von mehreren Verteidigungsschichten wie Notarisierung, Berechtigungen und App-Review. Ich bin ebenfalls dafür, dass Nutzer die Apps installieren dürfen, die sie wollen, aber man muss dann auch anerkennen, dass ein normales iPhone dadurch stärker dem Risiko ausgesetzt wäre, sich wie Android Malware einzufangen. Hinter Apples Politik steckt neben Machtstreben auch ein reales Sicherheitsproblem, selbst wenn der Hauptantrieb wahrscheinlich Profit ist
Auch der Browser selbst ist eine Art App Store, also führen wir dort faktisch ständig Apps aus, ohne dass Apple sie jeweils prüft. In diesem Kontext verstehe ich nicht wirklich, warum Apple und seine Fans die Sicherheit des App Store so stark betonen
Wenn JIT zugelassen wird, geht es nicht nur um schnellere Emulation. Weil man nicht mehr alles durch einen Interpreter drehen muss, steigt auch die Effizienz, was Akkulaufzeit und Hitzeprobleme des Telefons verbessern kann, etwa wenn man Spiele von 2008 laufen lässt
(Sinnloser Kommentar ausgelassen)
Wenn man „Blockierungspotenzial“ weit auslegt, könnte zum Beispiel auch eine Regionssperre, bei der alternative Browser-Engines nur für japanische Apple-Accounts veröffentlicht werden dürfen, als faktische Verhinderung der realen Existenz alternativer Browser gewertet werden. Für Mozilla wäre die Zielgruppe dann ebenfalls zu klein, um Firefox für iOS zu portieren. Realistisch ist das zwar eher nicht, aber vielleicht ist das hier doch ein kleiner Ausgangspunkt für globale Browserwahlfreiheit
Eine Regionssperre, die alternative Browser-Engines nur für bestimmte Accounts zulässt, ist eines der Dinge, die Apple in der EU macht
Soweit ich weiß, wurde Gecko, also die Firefox-Engine, bereits auf iOS portiert
Der Marktanteil ist ohnehin klein, daher frage ich mich, ob man wirklich portieren würde, nur um noch eine winzige Minderheit zusätzlich zu erreichen
Mozilla ist als Organisation geringe Marktanteile gewohnt. So anders wäre diese Situation also nicht, und eher könnte es sogar eine Gelegenheit sein, vor einer breiteren Marktöffnung eine QA-Version über echte Nutzer zu verteilen
Nach der EU und dem UK setzt nun auch Japan dem Verbot alternativer Browser-Engines auf iOS ein Ende. Alle drei sind große Märkte, daher frage ich mich, ob Chrome oder Firefox jetzt genug Anreiz haben, in iOS-Versionen mit ihren eigenen Engines zu investieren, also in Browser auf Basis von Blink und Gecko. Es gab viele Gerüchte, dass genau dieser Punkt die Entwicklung bisher ausgebremst hat
Auf derselben Seite sehe ich, dass Apple große Browseranbieter offenbar weiterhin mit allen Mitteln daran hindert, ihre eigenen Engines zu veröffentlichen zugehöriger Blog
Beim UK ist mein Kenntnisstand, dass die Regierung relevante Gesetze wie den Digital Markets Act 2024 eher zurückhaltend durchsetzt
Kulturell dürfte man sich in Japan für so eine Veränderung nicht besonders interessieren. Wenn man schon die Nutzung von Linux in Japan betrachtet: Eine kleine, leidenschaftliche Minderheit wird es unter allen Umständen weiter nutzen, aber die breite Masse nimmt einfach das, was bequem ist. Man bastelt dort nicht gern an Systemen oder Einstellungen herum
Es gibt auch die Sichtweise, dass Apple Browserentwicklern das Leben so schwer gemacht hat, dass niemand diese Hürde überwinden konnte
Ich frage mich, ob es nicht realistischer und einfacher wäre, wenn Firefox auf Blink umsteigen und mit Google zusammenarbeiten würde, um eine alternative Engine für iOS zu bauen
Ich frage mich, ob diese Veränderung wirklich gut ist. Fördert sie nicht letztlich nur noch mehr Chromium-Marktanteil?
Safari ist strukturell kein guter Browser. Wegen Apples Eigeninteressen hält Apple die Webplattform absichtlich schwach. Echter Wettbewerb bedeutet nicht, Nutzer zu einem Browser zu zwingen, sondern einen wirklich guten Browser zu bauen, den Nutzer freiwillig wählen
Stimmt schon. Letztlich war Safari auf iOS die letzte Bastion dagegen, dass das gesamte Web zu „All Chrome Everywhere“ wird
Regierungen können Marktmonopole auch lösen Wikipedia zum US-Justizministerium-vs.-Google-Verfahren
Genau deshalb ist es so kompliziert. Einerseits muss Apple iOS unbedingt weiter öffnen, andererseits stärkt das am Ende womöglich nur das Chrome-Monopol
Der Vorteil, echtes Firefox auf iOS nutzen zu können, ist groß. Und das ist eine positive Veränderung. Apples unangebrachter Einfluss darauf, Webstandards im eigenen Interesse zu schwächen, etwa durch das Behindern von SPIR-V-Unterstützung bei WebGPU, würde kleiner werden
(Narrator) Ein Jahr später lag der Chrome-Marktanteil in Japan bei 100 %, und alle Websites wurden nur noch für diesen Browser entworfen
Japan hat ein besonderes Verhältnis zu Apple. Zum Beispiel ist die Ticketfunktion auf Basis von FeliCa, dem japanischen NFC-System, in allen iPhones integriert, sodass iOS-Nutzer aus aller Welt in Japan viel bequemer leben können. Noch erstaunlicher ist, dass man für die tatsächliche Ticketnutzung überhaupt keine App braucht, solange man Apple Pay hat. Diese Entwicklung schränkt die Vorteile nativer Apps zunehmend ein, auch wenn native Apps bisher noch eigene Stärken haben, und gleichzeitig ist es schwer, dem Argument zu widersprechen, Apple verlagere seine Gatekeeper-Rolle am Ende nur in andere Bereiche
Die Unterstützung des FeliCa-Netzwerks liegt vor allem daran, dass mobile Verkehrs- und Bezahlsysteme in Japan schon vor dem iPhone etabliert waren. Es gab bereits Mobile Suica und Osaifu-Keitai, daher musste Apple aktiv nachziehen, um wettbewerbsfähig zu bleiben. Es begann mit Japan-exklusiven iPhone-SKUs und wurde später global ausgerollt. Sogar heute ist der Markt für mobile Zahlungen in Japan noch kein Monopol. Wenn Apple Wettbewerbsdruck spürt, kommt Bewegung auf, etwa durch die Einführung von Express Transit wie bei Suica. Und QR-Code-Bezahl-Apps aus Japan wie PayPay sind weiter verbreitet als Kreditkartenzahlungen
Der iOS-Marktanteil in Japan ist mit 64 % sogar höher als in den USA (59 %), im UK (47 %) oder in Europa (34 %) Quelle: statcounter
Bei FeliCa geht es um Patentlizenzen. Apple scheint sich irgendwo einen günstigen Vertrag gesichert zu haben. Selbst beim Google Pixel sind die Chips überall verbaut, aber bei nicht-japanischen Modellen ist die Funktion softwareseitig gesperrt (mit Root kann man sie freischalten)
Man merkt, wie mächtig die Kraft des „Wir können das“ ist. Wenn ein Land es schafft, ändern andere Länder, die 20 Jahre lang behauptet haben, es sei unmöglich, plötzlich auch ihre Haltung und sagen: „Wir können das auch, wir dürfen nicht zurückfallen“
Ich muss einfach annehmen, dass Google sich schon länger darauf vorbereitet, „echtes“ Chrome für iOS zu veröffentlichen. Wahrscheinlich arbeiten sie schon seit Langem daran, um es direkt zum Zeitpunkt einer Gesetzesänderung auf den Markt zu bringen, oder?
Google arbeitet daran, Blink, also die Chrome-Engine für iOS, zu portieren, und es gibt schrittweise Fortschritte. Im Chromium-Bugtracker gibt es einen Tracking-Eintrag dazu Tracking-Link. Wegen Apples Geofencing-Regeln in der EU und verschiedener Einschränkungen von BrowserEngineKit wurden bislang vermutlich noch nicht genug Ressourcen für einen produktionsreifen Einsatz investiert
Februar 2023: „Google beginnt damit, Chrome auf iOS mit Blink statt Apple WebKit zu betreiben“ zugehöriger Artikel
(Blink ist die Web-Rendering-Engine von Chrome.) In der offiziellen Dokumentation zum Bauen von Chromium/Chrome für iOS steht, dass die „blink web platform“ experimentell ist und nur für Analysezwecke verwendet werden soll. Als nützliche zugehörige Targets werden content_shell und chrome genannt. offizielle Build-Dokumentation