Alternative Browser-Engines in Japan verwenden

    Ab iOS 26.2 können andere Browser-Engines als WebKit in zwei Arten von Apps für Nutzer:innen in Japan verwendet werden: spezielle Browser-Apps, die ein vollständiges Webbrowser-Erlebnis bieten, und Apps von Browser-Engine-Verwaltern, die In-App-Browser-Erlebnisse mit einer eingebetteten Browser-Engine ermöglichen.

    Apple bietet autorisierten Entwickler:innen Zugriff auf Technologien innerhalb des Systems, die kritische Funktionen ermöglichen und sie dabei unterstützen, leistungsstarke moderne Browser-Engines anzubieten. Diese Technologien umfassen Just-in-Time-Kompilierung, Unterstützung für mehrere Prozesse und mehr.

    Da Browser-Engines jedoch ständig nicht vertrauenswürdigen und potenziell schädlichen Inhalten ausgesetzt sind und Zugriff auf vertrauliche Nutzerdaten haben, gehören sie zu den häufigsten Angriffsvektoren für Cyberkriminelle. Um die Sicherheit der Nutzer:innen im Internet zu gewährleisten, autorisiert Apple Entwickler:innen nur dann, alternative Browser-Engines zu implementieren, wenn bestimmte Kriterien erfüllt sind und sie sich zu einer Reihe fortlaufender Datenschutz- und Sicherheitsanforderungen verpflichten, einschließlich zeitnaher Sicherheitsupdates, um aufkommende Bedrohungen und Schwachstellen zu beheben.

    Berechtigung für Web­browser-Engines

    Für Browser-Apps

    Mit der Berechtigung für Webbrowser-Engines können Sie eine alternative Browser-Engine in Ihrer Browser-App verwenden. Wenn Sie an der Verwendung einer alternativen Browser-Engine in Ihrer Browser-App interessiert sind, lesen Sie die folgenden Anforderungen und reichen dann Ihre Anfrage zur Erteilung einer Berechtigung für Webbrowser-Engines ein. Technische Hinweise finden Sie unter:

    Anforderungen

    Um für die Berechtigung qualifiziert zu sein, muss Ihre App folgende Anforderungen erfüllen:

    • Sie darf ausschließlich für iOS in Japan bereitgestellt werden (außer in anderen Gerichtsständen oder auf anderen Apple-Plattformen, die von Apple laut Entwicklervereinbarung – einschließlich etwaiger Anhänge – ausdrücklich genehmigt wurden und für die Sie ebenfalls ein entsprechendes Berechtigungsprofil erhalten haben).
    • Sie muss über die Berechtigung für Standardbrowser verfügen.
    • Sie muss die folgenden funktionalen Anforderungen erfüllen, um sicherzustellen, dass Ihre App eine Webbrowser-Engine verwendet, die eine grundlegende Webfunktionalität bietet:
      • einen Mindestprozentsatz an Tests bestehen, die in branchenüblichen Testpaketen verfügbar sind:
        • 90 % der Webplattformtests
          • als Prozentsatz der höchsten Anzahl von Subtests, die von einem Browser auf der wpt.fyi-Startseite ausgeführt werden, und
          • auf einem Betriebssystem, mit dem das Testpaket kompatibel ist
        • 80 % von Test262 auf einem iOS-Gerät, iPadOS-Gerät oder Mac mit Apple-Chip und
      • die obige Testpaketanforderung erfüllen, wenn die Just-in-Time-Kompilierung (JIT) nicht verfügbar ist (z. B., wenn der Blockierungsmodus von dem:der Nutzer:in aktiviert wurde).
    • Sie und Ihre App müssen die folgenden Sicherheitsanforderungen erfüllen:
      • Sie verpflichten sich, die Entwicklungsprozesse zu sichern, einschließlich der Überwachung der Software-Lieferkette Ihrer App auf Schwachstellen, und befolgen die Best Practices für die sichere Softwareentwicklung (z. B. die Durchführung von Threat Modeling für neue Funktionen, die sich in der Entwicklung befinden).
      • Sie stellen eine URL zu einer veröffentlichten Richtlinie zur Offenlegung von Sicherheitslücken bereit. Diese Richtlinie muss folgende Punkte enthalten: Kontaktinformationen, über die Dritte (darunter auch Apple) Sicherheitslücken und ‑probleme melden können; Angaben dazu, welche Informationen in einer Meldung angegeben werden müssen; und Informationen darüber, wann Statusaktualisierungen zu erwarten sind.
      • Sie verpflichten sich, Schwachstellen in Ihrer App oder der alternativen Webbrowser-Engine, die sie verwendet, zeitnah zu beheben (z. B. innerhalb von 30 Tagen für die einfachsten Arten von Schwachstellen, die aktiv ausgenutzt werden).
      • Sie stellen eine URL zu einer öffentlich verfügbaren Webseite (oder -seiten) bereit, die Informationen darüber enthält, welche gemeldeten Sicherheitslücken in bestimmten Versionen der Browser-Engine und, falls abweichend, der zugehörigen App-Version behoben wurden.
      • Wenn Ihre alternative Webbrowser-Engine einen Root-Zertifikatsspeicher verwendet, auf den nicht über das iOS-SDK zugegriffen wird, müssen Sie die Richtlinie für Root-Zertifikate öffentlich zugänglich machen, und der Eigentümer dieser Richtlinie muss als Browser am Certification Authority/Browser Forum teilnehmen.
      • Sie unterstützen nachweislich moderne TSL-Protokolle (Transport Layer Security) zum Schutz der Datenübertragung bei Verwendung der Browser-Engine.
    Anforderungen an die Programmsicherheit

    Sie müssen die folgenden Anforderungen erfüllen:

    • Sie müssen mindestens für den alternativen Web‑Browser‑Engine‑Code, der Web‑Inhalte verarbeitet, entweder eine speichersichere Programmiersprache einsetzen oder Funktionen nutzen, die die Speichersicherheit in anderen Sprachen erhöhen.
    • Sie führen die neuesten Maßnahmen zur Reduzierung von Sicherheitsrisiken ein (z. B. Pointer Authentication Codes), die Sicherheitslücken beseitigen oder die Entwicklung einer Exploit-Kette erheblich erschweren. Dies umfasst die Einführung von:
      • Pointer Authentication Codes (PAC);
      • Memory Integrity Enforcement (MIE) für (i) vom System bereitgestellte Allokatoren in jeder Inhaltserweiterung und (ii) nutzerdefinierte oder vom System bereitgestellte Allokatoren in allen Prozessen und Erweiterungen Ihrer App, einschließlich Ihrer Netzwerk- und Grafikrendering-Erweiterungen.
    • Sie befolgen Best Practices für sicheres Design und sichere Programmierung.
    • Sie nutzen die Prozesstrennung, um die Auswirkungen der Ausnutzung zu begrenzen und die Interprozesskommunikation (IPC) innerhalb der alternativen Webbrowser-Engine zu validieren.
    • Sie achten auf Schwachstellen bei Abhängigkeiten von Drittanbietersoftware und in der breiteren Software-Lieferkette Ihrer App, und migrieren auf neuere Versionen, wenn sich eine Schwachstelle auf Ihre App auswirkt.
    • Sie verwenden keine Frameworks oder Softwarebibliotheken, die als Reaktion auf Schwachstellen keine Sicherheitsupdates mehr erhalten.
    • Sie geben der schnellen Behebung gemeldeter Schwachstellen Vorrang vor der Entwicklung neuer Funktionen. Wenn die alternative Webbrowser-Engine beispielsweise Funktionen zwischen dem SDK der Plattform und den Webinhalten überbrückt, um Web-APIs zu aktivieren, muss auf Anfrage die Unterstützung einer solchen Web-API entfernt werden, wenn festgestellt wird, dass sie eine Schwachstelle darstellt. Die meisten Schwachstellen sollten innerhalb von 30 Tagen behoben werden, einige können jedoch komplexer sein und länger dauern.
    Anforderungen an den Datenschutz des Programms

    Sie müssen die folgenden Anforderungen erfüllen:

    • Sie blockieren standardmäßig seitenübergreifende Cookies (d. h. Cookies von Drittanbietern), es sei denn, der:die Nutzer:in entscheidet sich ausdrücklich dafür, solche Cookies mit Einwilligung nach Aufklärung zuzulassen, oder wenn dies im Falle von Pop-up-Fenstern, die mit Frames in dem geöffneten Fenster interagieren, aus Kompatibilitätsgründen erforderlich ist.
    • Sie partitionieren von Websites beobachtbare Speicher oder Zustände auf der obersten Website oder blockieren diese Speicher oder Zustände für die seitenübergreifende Nutzung und Beobachtung.
    • Sie synchronisieren keine Zustände (einschließlich Cookies) zwischen Ihrer App und einer anderen App, auch nicht zwischen Apps desselben Entwicklers, es sei denn, der:die Nutzer:in hat ausdrücklich die Erlaubnis zur Synchronisierung erteilt, entweder durch Anmeldung in beiden Apps oder durch eine andere ausdrückliche Zustimmung.
    • Sie geben Gerätekennungen nicht ohne Einwilligung nach Aufklärung und Nutzeraktivierung an Websites weiter.
    • Sie kennzeichnen Netzwerkverbindungen mithilfe der bereitgestellten APIs, um einen App-Datenschutzbericht auf iOS zu generieren (d. h. überall dort, wo Ihre App verteilt wird).
    • Sie halten sich an gängige Webstandards, in denen festgelegt ist, wann eine informierte Nutzeraktivierung und/oder Nutzereinwilligung erforderlich ist, je nach Bedarf für Web-APIs (z. B. Zwischenablage oder Vollbildzugriff), einschließlich solcher, die Zugriff auf personenbezogene Daten bieten.

    Berechtigung für eingebettete Browser-Engines

    Für In-App-Browsing

    Mit der Berechtigung für eingebettete Browser-Engines können Sie eine alternative Browser-Engine in Ihre App einbetten, um In-App-Browsing zu ermöglichen. In-App-Browsing ist die dynamische Anzeige von Inhalten aus dem Internet, auf die zugegriffen werden kann und die in einer Webbrowser-App funktionieren. Dies umfasst keine Inhalte, die in der App eingebettet sind oder nur über die App verfügbar sind.

    Der Schwerpunkt Ihrer App beim In-App-Browsing muss darin bestehen, die Funktionalität zum Surfen im Internet bereitzustellen. Beim Bereitstellen von In-App-Browsing muss die Nutzeroberfläche:

    • den größten Teil des Displays einnehmen, abgesehen von den relevanten Steuerelementen, die es dem:der Endnutzer:in ermöglichen, die Browsersitzung zu steuern;
    • eine Taste oder einen Link zum Standardbrowser des Systems bereitstellen, damit der:die Nutzer:in eine eigene Browser-App öffnen kann, um die aktuell gezeigten Inhalte anzuzeigen, und
    • die Domain oder URL anzeigen, deren Inhalt durch In-App-Browsing gerendert wird.

    Wenn Sie daran interessiert sind, eine alternative Browser-Engine in Ihrer App zu verwenden, um In-App-Browsererlebnisse bereitzustellen, lesen Sie die folgenden Anforderungen, und reichen Sie dann Ihre Anfrage für die Berechtigung für eingebettete Browser-Engines ein. Sie werden Informationen über die einzubettende Engine bereitstellen und unter anderem angeben müssen, wie diese die Anforderungen erfüllt und wie sie in eine App integriert werden kann, um das In-App-Browsererlebnis zu bieten. Technische Anleitungen finden Sie im Abschnitt „Beispiele und Ressourcen“.

    Anforderungen

    Um für diese Berechtigung in Frage zu kommen, muss Ihre Organisation ein Browser-Engine-Verwalter sein. Ein Browser-Engine-Verwalter ist eine Organisation, deren primäre Aufgabe im Betreiben einer eigenständigen Webbrowser-Engine besteht.

    • Primäre Aufgabe bedeutet, dass Sie die operative Kontrolle über die Webbrowser-Engine besitzen und letztendlich dafür verantwortlich sind, Maßnahmen zu koordinieren, wenn eine Sicherheits- oder Datenschutzlücke gefunden wird, und diese zu beheben.
    • Eine eigenständige Webbrowser-Engine zeichnet sich dadurch aus, dass sie von einer anderen Entität oder Organisation als jede andere Webbrowser-Engine betrieben wird und sowohl Architektur als auch Unterstützung für Web-APIs bietet, die sich materiell von jeder anderen Engine unterscheiden. Die Engine wird in der Regel nicht aktualisiert, um Änderungen aus ihren Forks zu übernehmen, sondern schickt stattdessen Änderungen zu ihren Forks.
    App-Anforderungen

    Ihre App muss die folgenden Anforderungen erfüllen:

    • Sie darf ausschließlich für iOS in Japan bereitgestellt werden (außer in anderen Gerichtsständen oder auf anderen Apple-Plattformen, die von Apple laut Entwicklervereinbarung – einschließlich etwaiger Anhänge – ausdrücklich genehmigt wurden und für die Sie ebenfalls ein entsprechendes Berechtigungsprofil erhalten haben).
    • Sie darf die Berechtigung ausschließlich für In-App-Browsing verwenden.
    • Sie darf nicht über die Berechtigung für Standardbrowser verfügen.
    • Sie muss die folgenden funktionalen Anforderungen erfüllen, um sicherzustellen, dass Ihre App eine Webbrowser-Engine verwendet, die eine grundlegende Webfunktionalität bietet:
      • einen Mindestprozentsatz an Tests bestehen, die in branchenüblichen Testpaketen verfügbar sind:
        • 90 % der Webplattformtests
          • als Prozentsatz der höchsten Anzahl von Subtests, die von einem Browser auf der wpt.fyi-Startseite ausgeführt werden, und
          • auf einem Betriebssystem, mit dem das Testpaket kompatibel ist
        • 80 % von Test262 auf einem iOS-Gerät, iPadOS-Gerät oder Mac mit Apple-Chip und
      • die obige Testpaketanforderung erfüllen, wenn die Just-in-Time-Kompilierung (JIT) nicht verfügbar ist (z. B., wenn der Blockierungsmodus von dem:der Nutzer:in aktiviert wurde).
    • Sie müssen die folgenden Sicherheitsanforderungen erfüllen:
      • Sie verpflichten sich, die Entwicklungsprozesse zu sichern, einschließlich der Überwachung der Software-Lieferkette Ihrer App auf Schwachstellen, und befolgen die Best Practices für die sichere Softwareentwicklung (z. B. die Durchführung von Threat Modeling für neue Funktionen, die sich in der Entwicklung befinden).
      • Sie stellen eine URL zu einer veröffentlichten Richtlinie zur Offenlegung von Sicherheitslücken bereit. Diese Richtlinie muss folgende Punkte enthalten: Kontaktinformationen, über die Dritte (darunter auch Apple) Sicherheitslücken und ‑probleme melden können; Angaben dazu, welche Informationen in einer Meldung angegeben werden müssen; und Informationen darüber, wann Statusaktualisierungen zu erwarten sind.
      • Sie verpflichten sich, Schwachstellen in Ihrer App oder der alternativen Webbrowser-Engine zeitnah zu beheben (z. B. innerhalb von 30 Tagen für die einfachsten Arten von Schwachstellen, die aktiv ausgenutzt werden).
      • Sie stellen eine URL zu einer öffentlich verfügbaren Webseite (oder -seiten) bereit, die Informationen darüber enthält, welche gemeldeten Sicherheitslücken in bestimmten Versionen der Browser-Engine und, falls abweichend, der zugehörigen App-Version behoben wurden.
      • Wenn die von Ihnen gewählte alternative Webbrowser-Engine einen Root-Zertifikatsspeicher verwendet, auf den nicht über das iOS-SDK zugegriffen wird, müssen Sie die Richtlinie für Root-Zertifikate öffentlich zugänglich machen, und der Eigentümer dieser Richtlinie muss als Zertifikatsverbraucher am Certification Authority/Browser Forum teilnehmen.
      • Sie unterstützen nachweislich moderne TSL-Protokolle (Transport Layer Security) zum Schutz der Datenübertragung bei Verwendung der Browser-Engine.
    Anforderungen an die Programmsicherheit

    Sie müssen die folgenden Anforderungen erfüllen:

    • Sie müssen mindestens für den alternativen Web‑Browser‑Engine‑Code, der Web‑Inhalte verarbeitet, entweder eine speichersichere Programmiersprache einsetzen oder Funktionen nutzen, die die Speichersicherheit in anderen Sprachen erhöhen.
    • Sie führen die neuesten Maßnahmen zur Reduzierung von Sicherheitsrisiken ein, die Sicherheitslücken beseitigen oder die Entwicklung einer Exploit-Kette erheblich erschweren.
    • Sie befolgen Best Practices für sicheres Design und sichere Programmierung.
    • Sie achten auf Schwachstellen bei Abhängigkeiten von Drittanbietersoftware und in der breiteren Software-Lieferkette Ihrer App, und migrieren auf neuere Versionen, wenn sich eine Schwachstelle auf Ihre App auswirkt.
    • Sie verwenden keine Frameworks oder Softwarebibliotheken, die als Reaktion auf Schwachstellen keine Sicherheitsupdates mehr erhalten.
    • Sie geben der schnellen Behebung gemeldeter Schwachstellen Vorrang vor der Entwicklung neuer Funktionen. Wenn die alternative Browser-Engine beispielsweise Funktionen zwischen dem SDK der Plattform und den Webinhalten überbrückt, um Web-APIs zu aktivieren, muss auf Anfrage die Unterstützung einer solchen Web-API entfernt werden, wenn festgestellt wird, dass sie eine Schwachstelle darstellt. Die meisten Schwachstellen sollten innerhalb von 30 Tagen behoben werden, einige können jedoch komplexer sein und länger dauern.
    Anforderungen an den Datenschutz des Programms

    Sie müssen die folgenden Anforderungen erfüllen:

    • Sie blockieren standardmäßig seitenübergreifende Cookies (d. h. Cookies von Drittanbietern), es sei denn, der:die Nutzer:in entscheidet sich ausdrücklich dafür, solche Cookies mit Einwilligung nach Aufklärung zuzulassen, oder wenn dies im Falle von Pop-up-Fenstern, die mit Frames in dem geöffneten Fenster interagieren, aus Kompatibilitätsgründen erforderlich ist.
    • Sie partitionieren von Websites beobachtbare Speicher oder Zustände auf der obersten Website oder blockieren diese Speicher oder Zustände für die seitenübergreifende Nutzung und Beobachtung.
    • Sie geben Gerätekennungen nicht ohne Einwilligung nach Aufklärung und Nutzeraktivierung an Websites weiter.
    • Sie kennzeichnen Netzwerkverbindungen mithilfe der bereitgestellten APIs, um einen App-Datenschutzbericht auf iOS zu generieren (d. h. überall dort, wo Ihre App verteilt wird).
    • Sie halten sich an gängige Webstandards, in denen festgelegt ist, wann eine informierte Nutzeraktivierung und/oder Nutzereinwilligung erforderlich ist, je nach Bedarf für Web-APIs (z. B. Zwischenablage oder Vollbildzugriff), einschließlich solcher, die Zugriff auf personenbezogene Daten bieten.
    Zusätzliche Anforderungen
    • Mit jeder binären Einreichung müssen Sie den Namen und die Version der alternativen Webbrowser-Engine einreichen, die in Ihre App eingebettet ist.
    • Sobald eine neue Version der alternativen Webbrowser-Engine verfügbar gemacht wird, die in Ihre App eingebettet ist, müssen Sie innerhalb von fünfzehn (15) Kalendertagen ein Update für Ihre App mit dieser neuen Version übermitteln.

    Beispiele und Ressourcen

    Dieser Abschnitt enthält zusätzliche Ressourcen und Beispiele, die Ihnen helfen, die Anforderungen zu erfüllen, die Ihnen die Verwendung einer alternativen Browser-Engine ermöglichen.

    Sicherer SDLC (Software Development Lifecycle)

    Viele der Anforderungen, die Sie erfüllen müssen, erfordern die Entwicklung eines sicherheits- und datenschutzorientierten Ansatzes für die Einführung neuer Funktionen in Ihre App. Bei der Entwicklung neuer Funktionen sollten Sie zunächst ein Bedrohungsmodell sowie einen Plan erstellen, wie Ihre Architektur und die veröffentlichte Version Ihrer App die von Ihnen identifizierten Risiken mindern können. Es gibt verschiedene Methoden, um Sicherheit zu erlangen, z. B. Code-Auditing, Fuzz-Testing und das Schreiben von Testfällen, um die gewünschten Sicherheitseigenschaften zu überprüfen. Betrachten Sie Webinhalte generell als nicht vertrauenswürdig und potenziell schädlich.

    Ressourcen

    Sicherheitsmaßnahmen und Speichersicherheit

    Beachten Sie auch, welche aktuellen Sicherheitsmaßnahmen von iOS oder iPadOS bereitgestellt werden (etwa Pointer Authentication Codes und Memory Integrity Enforcement) und welche Programmiersprachen (oder Sprach- und Compilerfunktionen sowie andere Tools) es gibt, um von Ihnen identifizierten Bedrohungen entgegenzuwirken. Swift ist beispielsweise standardmäßig eine speichersichere Sprache, die Ihnen helfen kann, häufige Ursachen für Schwachstellen sowie andere speicherbezogene Softwarefehler zu vermeiden. Speicherunsichere Sprachen wie C++ bieten jedoch Funktionen, die die Speichersicherheit verbessern, z. B. std::span. Zusätzlich können Sie Compiler-Optionen und Tools verwenden, zum Beispiel -fbounds-safety mit C, die Ihnen ermöglichen, bestehenden Code zu annotieren, um Speicherzugriffe außerhalb der Grenzen zu vermeiden, ohne dass die Funktionalität immer in eine standardmäßig speichersichere Sprache umgeschrieben werden muss.

    Ressourcen

    Schwachstellenmanagement

    Sie sollten davon ausgehen, dass in einer Browser-Engine immer unentdeckte Schwachstellen vorhanden sind oder dass neue Funktionen unbeabsichtigte Risiken bergen können. Daher ist es wichtig, dass Sie Prozesse einführen, mit denen Sie reagieren können, sobald eine Sicherheitslücke entdeckt wird: sei es durch interne Tests, durch Sicherheits- und Datenschutzmaßnahmen in Ihrer Software-Lieferkette oder durch Meldungen Dritter.

    Wenn Sie einer dritten Person (z. B. einem:einer Sicherheitsforscher:in) die Möglichkeit zur Meldung einer Sicherheitslücke geben, müssen Sie überlegen, welche Informationen sie von ihm bzw. ihr benötigen, damit Sie die Gültigkeit und Ursache des Problems ermitteln können. Außerdem sollten Sie sicherstellen, dass Sie über Prozesse verfügen, mit denen Sie eine Behebung der Schwachstelle priorisieren und dann möglicherweise außerhalb Ihres normalen Zeitplans ein Update veröffentlichen können.

    Es ist auch wichtig, dass Nutzer:innen schnell feststellen können, welche öffentlichen Sicherheitslücken mit einer zugehörigen CVE-Nummer in welcher Version Ihrer App (oder einer alternativen Browser-Engine) behoben werden.

    Ressourcen

    Netzwerksicherheit

    Durch die Nutzung des iOS‑SDK, insbesondere des Network‑Frameworks und/oder der SecTrust‑APIs, verringern Sie Ihren Aufwand, das Vertrauen von Web‑Zertifikaten selbst zu beurteilen und einen zugehörigen Root‑Trust‑Store bzw. ein entsprechendes Trust‑Programm für die von Ihnen eingesetzte alternative Browser‑Engine zu pflegen. Wenn Sie ein Programm betreiben, sollte es Informationen darüber enthalten, wie eine Root-Zertifizierungsstelle (CA) die Aufnahme in das Programm beantragen kann und wie Vorfälle (z. B. die Offenlegung des privaten Schlüsselmaterials einer Root-Zertifizierungsstelle) gemeldet werden können, sodass Sie Maßnahmen ergreifen können.

    Die im Internet verwendeten Protokolle werden ständig weiterentwickelt, um auf aufkommende Bedrohungen zu reagieren und die Privatsphäre und Sicherheit von Nutzer:innen besser zu schützen. Die derzeit empfohlenen TLS-Versionen, die mit Ihrer alternativen Browser-Engine kompatibel sein sollten und nicht veraltet sind, sind TLS 1.2 und 1.3. Diese können sich jedoch mit der Zeit ändern. Sie können veraltete Protokolle in Ihrer alternativen Browser-Engine unterstützen, sollten Nutzer:innen jedoch informieren, wenn sie zu einer Website navigieren, die nur diese Protokolle unterstützt.

    Ressourcen

    Vereinbarungen