iOS erlaubt in Japan erstmals alternative Browser-Engines

• Apps für Nutzer in Japan können unter iOS 26.2 und höher andere Browser-Engines als WebKit verwenden; erlaubt sind zwei Arten: vollständige Browser-Apps und Apps mit eingebetteter Browser-Engine
• Apple gewährt genehmigten Entwicklern Zugriff auf Systemtechnologien für die Implementierung leistungsfähiger Browser-Engines, darunter JIT-Kompilierung und Multiprozess-Unterstützung
• Wegen der Sicherheitsrisiken erteilt Apple diese Berechtigung nur Entwicklern, die strenge Sicherheits- und Datenschutzanforderungen erfüllen und fortlaufende Sicherheitsupdates zusagen
• Sowohl Browser-Apps als auch In-App-Browsing-Apps müssen detaillierte Kriterien wie Test-Erfolgsquote, Speichersicherheit, Reaktion auf Schwachstellen und Richtlinien zum Blockieren von Cookies erfüllen
• Die Maßnahme wird als politische Änderung bewertet, die im japanischen Markt die Auswahl bei Browser-Engines erweitert und zugleich die Sicherheit der Nutzer wahren soll

---

Überblick über die Zulassung alternativer Browser-Engines in iOS 26.2

• In Versionen ab iOS 26.2 ist für Nutzer in Japan die Verwendung anderer Browser-Engines als WebKit zulässig
  • Zugelassen sind zwei App-Typen:
    1. Dedizierte Browser-App (bietet ein vollständiges Web-Browsing-Erlebnis)
    2. In-App-Browsing-App eines browser engine steward (verwendet eine eingebettete Engine)
• Apple gewährt genehmigten Entwicklern Zugriff auf zentrale Systemtechnologien wie JIT-Kompilierung und Multiprozess-Unterstützung
• Da Browser-Engines schädlichen Inhalten und sensiblen Nutzerdaten ausgesetzt sind, genehmigt Apple nur Entwickler, die bestimmte Kriterien erfüllen und laufende Sicherheitsanforderungen einhalten

Web Browser Engine Entitlement (für dedizierte Browser-Apps)

• Mit dieser Berechtigung können Browser-Apps entwickelt werden, die alternative Browser-Engines verwenden
  • Vor der Beantragung müssen die Voraussetzungen geprüft und anschließend ein Antrag bei Apple eingereicht werden
  • Als technische Referenzen werden BrowserEngineKit, BrowserEngineCore und der Leitfaden zur Konfiguration des Standardbrowsers bereitgestellt

Zulassungsvoraussetzungen

• Die App darf nur für iOS in Japan vertrieben werden und muss als separate Binärdatei von anderen Apps aufgebaut sein, die eine vom System bereitgestellte Engine verwenden
• Die App muss über das Default Browser Entitlement verfügen
• Funktionsanforderungen:
  • mindestens 90 % bei Web Platform Tests, mindestens 80 % bei Test262
  • Dieselben Anforderungen müssen auch bei deaktiviertem JIT (z. B. im Lockdown Mode) erfüllt werden

Sicherheitsanforderungen

• Einführung eines sicheren Entwicklungsprozesses und Überwachung von Schwachstellen in der Lieferkette
• Bereitstellung einer URL für die Richtlinie zur Offenlegung von Schwachstellen sowie eines Meldekanals für Dritte
• Pflicht zu schneller Reaktion, darunter Maßnahmen zur Eindämmung von Schwachstellen innerhalb von 30 Tagen
• Betrieb einer Seite zur Offenlegung behobener Schwachstellen
• Veröffentlichung der Richtlinie für Root-Zertifikate und Teilnahme am CA/Browser Forum
• Unterstützung aktueller TLS-Protokolle ist verpflichtend

Anforderungen an die Programmsicherheit

• Verwendung einer speichersicheren Sprache oder von Sicherheitsfunktionen
• Einsatz aktueller Schutzmechanismen wie Pointer Authentication Codes (PAC) und Memory Integrity Enforcement (MIE)
• Prozesstrennung und Verifikation von IPC, vorrangige Behebung von Schwachstellen
• Keine Verwendung von Bibliotheken, deren Sicherheitsupdates eingestellt wurden

Datenschutzanforderungen

• Drittanbieter-Cookies standardmäßig blockieren, nur mit Zustimmung des Nutzers zulassen
• Speicherisolierung pro Website und Blockierung von websiteübergreifendem Zugriff
• Keine Synchronisierung des Status zwischen Apps, nur mit ausdrücklicher Zustimmung des Nutzers erlaubt
• Keine Weitergabe von Gerätekennungen, Kennzeichnung im App Privacy Report ist verpflichtend
• APIs für den Zugriff auf PII erfordern Nutzeraktivierung und Zustimmung

Embedded Browser Engine Entitlement (für In-App-Browsing)

• Eine alternative Browser-Engine kann in eine App eingebettet werden, um Webinhalte anzuzeigen
  • In-App-Browsing ist auf die Anzeige von Inhalten beschränkt, die auch in einem Webbrowser zugänglich sind
  • Die UI muss den Großteil des Bildschirms einnehmen und einen Button zum Öffnen im Standardbrowser sowie die Anzeige von Domain/URL enthalten

Zulassungsvoraussetzungen

• Der Antragsteller muss ein browser engine steward sein
  • eine Organisation, die direkt die Verantwortung für Betrieb und Sicherheitsreaktionen der Engine trägt
  • es muss sich um eine separate Engine mit unabhängiger Architektur und Unterstützung für Web APIs handeln

App-Anforderungen

• Nur für iOS in Japan vertrieben, ohne Berechtigung als Standardbrowser
• mindestens 90 % bei Web Platform Tests, mindestens 80 % bei Test262
• Dieselben Anforderungen müssen auch bei deaktiviertem JIT erfüllt werden

Sicherheits- und Programmanforderungen

• Sicherer Entwicklungsprozess, Richtlinie zur Offenlegung von Schwachstellen, Reaktion innerhalb von 30 Tagen, TLS-Unterstützung usw. wie bei dedizierten Browser-Apps
• Pflicht zur Verwendung speichersicherer Sprachen, zum Einsatz aktueller Sicherheitsmechanismen und zur vorrangigen Behebung von Schwachstellen
• Keine Verwendung von Bibliotheken, deren Sicherheitsupdates eingestellt wurden

Datenschutzanforderungen

• Blockierung von Drittanbieter-Cookies, Speicherisolierung pro Website, keine Weitergabe von Gerätekennungen
• Kennzeichnung im App Privacy Report sowie Nutzerzustimmung beim Zugriff auf PII erforderlich

Zusätzliche Anforderungen

• Bei der Einreichung der App müssen Name und Versionsnummer der eingebetteten Engine angegeben werden
• Nach Veröffentlichung einer neuen Engine-Version muss innerhalb von 15 Tagen ein App-Update eingereicht werden

Referenzmaterial für Entwickler und Sicherheitsleitfäden

• Secure SDLC: sicherheitsorientierte Entwicklung mit Bedrohungsmodellierung, Code-Audits, Fuzzing-Tests usw. empfohlen
• Memory Safety: Nutzung der standardmäßigen Speichersicherheit von Swift sowie von std::span und der Option -fbounds-safety in C/C++
• Vulnerability Management: Verwaltung veröffentlichter Schwachstellen auf Basis von CVE-ID und schnelle Bereitstellung von Patches erforderlich
• Network Security: Verwendung des Network framework und der SecTrust API des iOS SDK empfohlen
  • Unterstützung für TLS 1.2 und 1.3 ist verpflichtend; bei Verwendung älterer Protokolle ist eine Nutzerwarnung erforderlich

Relevante Dokumente und Vertragszusätze

• Embedded Browser Engine Entitlement Addendum for Apps in Japan
• Web Browser Engine Entitlement Addendum for Apps in Japan

[wedding]

Nicht spöttisch gemeint, aber Safari hält diese unzähligen Anforderungen doch hoffentlich ordentlich ein, oder?

[kimjoin2]

Wow, erstaunlich, dass es ausgerechnet in Japan begonnen hat. Ich hätte gedacht, dass so etwas zuerst in Europa oder den USA kommen würde.

[GN⁺]

Hacker-News-Kommentare

• Ich glaube nicht, dass Apple konkurrierende Browser blockieren wird, aber ich weiß, dass genau das passieren wird
  Das iPhone ist meiner Meinung nach faktisch die letzte Bastion gegen ein Chrome/Chromium-Monopol
  Google wird es nicht so schleifen lassen wie Microsoft, aber am Ende trotzdem ähnlich viel Einfluss bekommen
  Ich will wirklich nicht, dass die meisten Websites nur noch in Chrome richtig funktionieren
  Letztlich ist es Apples Sturheit, die diesen Trend – wenn auch unbeabsichtigt – aufhält

  • Ich hoffe, dass die Regulierungsbehörden Apples diktatorische Kontrolle umfassend einschränken
    Die Sorge, dass Chrome das Web beherrscht, halte ich für übertrieben. Nur weil eine neue API hinzugefügt wird, heißt das nicht, dass jede Website sie sofort nutzt
    Firefox hat das Web schon in der Zeit gerettet, als IE 95 % Marktanteil hatte – warum sollten wir heute von Apple allein abhängen?
    Das wirkt wie eine Art erlernte Hilflosigkeit
  • Solange Safari als Standard-App gesetzt ist, sehe ich in Chrome auf iOS keine große Bedrohung
    Außerdem schrumpft das mobile Web selbst immer mehr zugunsten eines app-zentrierten Modells
    Dazu kommt der Trend, dass AI-Suche die Websuche ersetzen soll, wodurch der Einfluss des Webs weiter sinken dürfte
  • Dieses Schiff ist bereits abgefahren. Apple ist selbst Teil des Problems
    Zum Beispiel unterstützte FaceTime Firefox nicht, sodass ich Edge benutzt habe, und am Ende musste ich zu Google Meet wechseln
  • Als IE früher mit neuen Funktionen den Markt dominierte, fanden die Leute das sogar gut
    Das Problem begann erst, als sie aufhörten zu innovieren
    Technologien wie ActiveX, Flash und Silverlight verursachten Sicherheitsprobleme und ruinierten das Web, und am Ende wurde IE zur Hölle für Entwickler und Nutzer gleichermaßen
    Ich denke, dass Mobile Safari heute diese Rolle übernommen hat
    Ich nutze Firefox auf PC und Android, aber auf Mobilgeräten halte ich einen Chromium-basierten Browser für die bessere Wahl
  • Safari ist so schlecht, dass ich auf iOS ein echtes Chrome-Erlebnis haben möchte

• Interessant fand ich bei den neuen japanischen Vorgaben die Anforderung „Verwendung speichersicherer Sprachen“
  Erfüllt Apple das selbst überhaupt? WebKit ist in C++ geschrieben
  Auch was genau mit „Funktionen zur Verbesserung der Speichersicherheit“ gemeint ist, bleibt unklar

  • Man kann das Dokument Safer C++ Guidelines von WebKit dazu heranziehen
  • Ich frage mich, ob Apple WebKit irgendwann durch eine Swift-basierte Engine ersetzen oder schrittweise dahin migrieren wird

• Es überrascht mich, dass Apple das noch nicht weltweit geöffnet hat
  Ein System aufrechtzuerhalten, das in einem Land offen ist und in einem anderen gesperrt bleibt, führt am Ende nur zu Verwirrung und Kosten

  • Aber Apple wird an diesem Ansatz festhalten, solange die Einnahmen stabil bleiben
    Für multinationale Unternehmen ist der Umgang mit solch komplexer Regulierung Alltag
  • Technisch ist das möglich, aber die mentalen und operativen Kosten für die Verwaltung regionaler Regeln sowie die Schulung von Mitarbeitern und Kunden dürften hoch sein
    Die Kontrolle über Browser-Engines wirkt eher wie eine Frage der Aufrechterhaltung von Kontrolle als des Umsatzes
  • Hoffentlich können wir so bald wie möglich Firefox und uBlock Origin richtig nutzen
  • „FeatureToggles.swift“ – das klingt wie ein Witz, aber auch wie eine treffende Satire auf Apples Politik
  • Apple hasst es zutiefst, Anweisungen zu bekommen
    Die Verhandlungen mit Japan liefen zwar besser als mit der EU, aber Apple ist trotzdem sehr unzufrieden
    Deshalb werden sie sich wohl nicht so leicht weltweit beugen

• Es sieht so aus, als würde Apple die in der EU geschaffenen Regeln zur Zulassung von Browser-Engines Dritter in Japan einfach unverändert anwenden
  Die Bedingungen sind aber so streng, dass selbst in der EU noch nie ein Browser mit alternativer Engine veröffentlicht wurde
  Die App muss als vollständig getrennte Binärdatei gebaut werden, was für große Browser wie Chrome einen Umstieg erschwert

  • Dazu kommt in der EU noch die zusätzliche Einschränkung, dass der Entwickler in der EU ansässig sein muss

• Ich hatte gehofft, dass die Gesetze in Japan und der EU weltweite Veränderungen anstoßen würden, aber große Konzerne können sich länderspezifische Ineffizienz leisten

  • Bei Hardware gab es mit USB-C eine Vereinheitlichung, Software bleibt aber weiterhin getrennt
    Zum Beispiel beschränkt das iPhone den Zugang zu alternativen App-Stores anhand des Standorts
    Siehe diesen Artikel
  • Was wäre, wenn ein Gesetz die Abschaffung von Funktionen wie Apples Tracking-Transparenz-Popup verlangen würde?
    Apple wurde in zwei Ländern bereits wegen genau dieses Pop-ups mit Geldstrafen belegt
  • Viele von Apples Regeln sind wettbewerbswidrig, aber ich denke, die Beschränkung von Browser-Engines dient eher Sicherheit, Akku und Standardisierung

• Wenn man sich die Anforderungen an einen „Browser-Engine-Manager“ ansieht, scheinen faktisch nur Google und Mozilla infrage zu kommen
  Selbst Microsoft wäre ausgeschlossen, weil es auf Blink basiert
  Kleinere Engines dürften die Grundanforderungen kaum erfüllen, sodass ein Markteintritt praktisch unmöglich wirkt

• Ich frage mich, ob wir auf iOS jetzt echtes Firefox + uBlock Origin nutzen können

  • Apple wird das Gesetz wohl nur buchstabengetreu befolgen und sich weiterhin mit allen Mitteln wehren
    Komplexe Anforderungen, eingeschränkte APIs und ignorierte Bugs werden Entwicklern das Leben schwer machen
    Es dürfte kaum ein Unternehmen geben, das genügend juristische und Entwicklungsressourcen investieren will, um nur für den japanischen Markt eine vollständige Engine zu portieren
  • Auch Mozilla wird sich wegen des Aufwands für die Pflege regional getrennter Apps möglicherweise nicht beteiligen
    Siehe Artikel
  • Bis dahin kann man für Safari uBlock Origin Lite verwenden
    Das ist ziemlich ordentlich
  • In der EU galten dieselben Regeln, aber Browser mit alternativer Engine sind nicht erschienen
    Momentan kann man stattdessen uBlock Origin Lite für Safari oder andere Werbeblocker nutzen
  • Zur Info: iOS Safari unterstützt bereits uBlock Origin Lite
    Firefox hat außerdem eigene Tracking-Schutzfunktionen

• Ich sehe oft Leute, die befürchten, dass Apple sein verbraucherfreundliches Image verliert, wenn es das Ökosystem öffnet
  Aber die Logik „Wenn Apple nicht alles kontrolliert, entsteht Chaos“ ist nur eine falsche Wahl zwischen zwei Extremen
  Wir brauchen einen Mittelweg zwischen totaler Apple-Kontrolle und völliger Vernachlässigung der Nutzer
  Wenn der Markt nicht wettbewerblich funktioniert, sollte Regulierung Nutzer und Entwickler schützen
  Dass Apple die Hardware abschottet, ist ein gefährlicher Präzedenzfall, und ich sorge mich, dass andere Unternehmen das nachahmen

  • Apple kontrolliert Tempo und Richtung der Innovation auf iOS direkt
    Neue Funktionen oder Apps können nicht existieren, wenn Apple sie nicht zulässt
    Dienste wie Dropbox und GDrive haben Funktionen verloren, weil sie sich an Apples fehleranfälliges Backend anpassen mussten
    Diese Struktur ist nicht normal
  • Ist die einzige Alternative am Ende wirklich nur Android?

• Apples Anforderung separater Binärdateien kommt faktisch einem Gesetzesverstoß gleich
  Das Verbot, den Login-Status zu teilen, und die erzwungene Blockierung von Cookies sind nichts, was das OS vorschreiben sollte
  Selbst Apple hält sich zudem nicht an die Regel für Sicherheits-Patches innerhalb von 30 Tagen

• Es überrascht mich, wie extrem weit Apple geht, um Ausnahmen nur für bestimmte Länder zu schaffen