日本での代替ブラウザエンジンの使用

    iOS 26.2以降では、日本のユーザー向けの2種類のアプリで、WebKit以外のブラウザエンジンを使用できます。1つ目はフル機能のWebブラウザ体験を提供する専用ブラウザアプリであり、2つ目は組み込みのブラウザエンジンを使用してアプリ内ブラウズ体験を提供するブラウザエンジンスチュワードのアプリです。

    Appleは承認されたデベロッパに対し、デベロッパが最新の高性能ブラウザエンジンを提供できるよう、重要な機能を実現するシステム内テクノロジーへのアクセスを許可します。このテクノロジーには、ジャストインタイム（JIT）コンパイル機能、マルチプロセスサポートなどが含まれます。

    しかし、ブラウザエンジンは、信頼できないコンテンツや悪意のある恐れがあるコンテンツに常にさらされており、機密性の高いユーザーデータが閲覧されてしまう可能性があるため、悪意ある攻撃で狙われる最も一般的な攻撃経路の1つです。Appleは、オンラインでユーザーの安全を確保するため、新たに発生する脅威や脆弱性に対処するための迅速なセキュリティアップデートなど、継続的なプライバシーとセキュリティの多数の要件を満たすことを保証し、特定の基準を満たしたデベロッパにのみ、代替ブラウザエンジンの実装を許可します。

    Webブラウザエンジンエ⁠ン⁠タ⁠イ⁠ト⁠ル⁠メ⁠ン⁠ト

    ブラウザアプリの場合

    Webブラウザエンジンエンタイトルメントでは、ブラウザアプリで代替ブラウザエンジンを使うことができます。ブラウザアプリで代替ブラウザエンジンを使用するには、以下の要件を確認してから、Webブラウザエンジンエンタイトルメントのリクエストを送信してください。技術的なガイダンスについては、以下をご参照ください。

    要件

    エンタイトルメントを得るには、アプリが次の要件を満たしている必要があります。

    • 日本においてiOSのみで配信されること。ただし、対応するエンタイトルメントプロファイルを同様に取得済みの、Apple Developer契約（追加契約を含む）に基づきAppleによって明示的に許可されているその他の司法管轄区域またはAppleプラットフォームでの配信を除く。
    • システムが提供するWebブラウザエンジンを使用するアプリとは別のバイナリであること。
    • デフォルトのブラウザエンタイトルメントを取得していること。
    • アプリで使用するWebブラウザエンジンがベースラインとなるWeb機能を確実に提供できるよう、以下の機能要件を満たしていること。
      • 業界標準の一連のテストで実行できるテストで、以下に示す基準以上のパーセンテージを達成していること。
        • WPT（Webプラットフォームテスト）：90%
          • （wpt.fyiのフロントページの任意のブラウザを使用して実行したサブテストの最高値のパーセンテージとしての数値。
          • テストスイートと互換性のあるオペレーティングシステム上で実行されたもの）
        • Appleシリコン搭載のiOS／iPadOSデバイス、またはMac上で実行したTest262：80%
      • ジャストインタイム（JIT）コンパイルが利用できない場合（ユーザーがロックダウンモードを有効にした場合など）、上記のテストスイートの要件を満たしていること。
    • 貴組織とそのアプリが次のセキュリティ要件を満たしていること。
      • アプリのソフトウェアサプライチェーンの脆弱性の監視、安全なソフトウェア開発（開発中の新機能に対して脅威のモデリングを実行するなど）に関するベストプラクティスの遵守など、安全な開発プロセスの実施に努めていること。
      • 脆弱性開示ポリシーの公開済みのURLを提供していること。このポリシーには、サードパーティ（Appleが含まれる場合がある）からデベロッパへのセキュリティの脆弱性や問題に関する報告する際の連絡先情報、報告に含める情報、ステータスの更新予定時期を記載する必要があります。
      • アプリ内、またはアプリが使用している代替Webブラウザエンジン内で悪用されている脆弱性を、迅速に（例えば、当該の時点で悪用されている最も単純な脆弱性クラスであれば30日間で）軽減することを確約していること。
      • 報告された脆弱性のうち、ブラウザエンジンの特定のバージョン、および（ブラウザエンジンと異なる場合）対応するアプリバージョンで解決された脆弱性の情報を一般公開されているWebページで公表し、そのURLを提供していること。
      • 代替WebブラウザエンジンがiOS SDK経由ではアクセスできないルート証明書ストアを使用している場合は、ルート証明書ポリシーを一般公開し、そのポリシーの所有者がCertification Authority／Browser Forumにブラウザデベロッパとして参加していること。
      • ブラウザエンジン使用時に転送中データの通信を保護するために、最新のTLS（Transport Layer Security）プロトコルをサポートしていることを実証していること。
    プログラムのセキュリティ要件

    以下の要件を満たしている必要があります。

    • 少なくともWebコンテンツを処理するすべてのコードについて、代替Webブラウザエンジン内で、メモリセーフなプログラミング言語を使用するか、ほかの言語でメモリの安全性を向上させる機能を使用していること。
    • 脆弱性クラスを排除したり、エクスプロイトチェーンの形成を大幅に困難にしたりする、最新のセキュリティ対策（Pointer Authentication Codeなど）を採用していること。対策には以下が含まれます。
      • Pointer Authentication Codes（PAC）
      • 次のアロケータを対象とするMemory Integrity Enforcement（MIE）：（i）コンテンツ拡張機能においてシステムが提供するアロケータ、（ii）アプリのプロセスや拡張機能（ネットワークやグラフィックスレンダリングの拡張機能を含む）における、カスタムのアロケータまたはシステムが提供するアロケータ
    • セキュアな設計とコーディングのベストプラクティスに従うこと。
    • 代替Webブラウザエンジン内でプロセス分離を使用してエクスプロイトの影響を制限し、プロセス間通信（IPC）を検証すること。
    • サードパーティソフトウェアとの依存関係や自社アプリのより広範なソフトウェアサプライチェーンに脆弱性がないか監視し、アプリが脆弱性の影響を受ける場合は新しいバージョンに移行すること。
    • 脆弱性に対応するセキュリティアップデートが提供されなくなったフレームワークまたはソフトウェアライブラリを使用しないこと。
    • 新機能の開発よりも、報告された脆弱性の迅速な解決を優先すること。例えば、Web APIを有効にするために代替ブラウザエンジンがプラットフォームのSDKとWebコンテンツの間で機能の橋渡しを行っており、当該のWeb APIに脆弱性が存在することが確認された場合は、要請があれば当該のWeb APIのサポートを削除しなければなりません。ほとんどの脆弱性は30日以内に解決されますが、一部の脆弱性はより複雑で、それ以上かかる場合があります。
    プログラムのプライバシー要件

    以下の要件を満たしている必要があります。

    • クロスサイトCookie（サードパーティCookie）については、ユーザーが十分な情報提供を受けた上で明示的に同意することを選択している場合や、開いているウインドウのフレームへの何らかの相互作用が発生するポップアップウインドウで互換性のために必要とされている場合を除き、これらのCookieをデフォルトでブロックすること。
    • Webサイトによる監視が可能なストレージまたは状態をトップレベルWebサイトごとに分割するか、またはそのようなストレージまたは状態がサイトを越えて使用されたり監視されたりしないようブロックすること。
    • 当該アプリと他のアプリ（デベロッパが同一の場合も含む）との間で状態（Cookieを含む）を同期しないこと。ただし、当該アプリと他のアプリの両方にユーザーがサインインするか、明示的な許可を与えるその他のメカニズムによって、状態の同期をユーザーが明示的に許可している場合は除く。
    • ユーザーが十分な情報提供を受けて同意した上で機能をアクティベートした場合を除き、デバイス識別子をWebサイトと共有しないこと。
    • iOS（またはアプリが配信されているその他のプラットフォーム）でアプリのプライバシーレポートを生成するために提供されているAPIを使用して、ネットワーク接続にラベルを付けること。
    • 個人を特定できる情報（PII）へのアクセスを提供するAPIを含むWeb API（クリップボードやフルスクリーンアクセスなど）については、情報を提供した上でのユーザーによるアクティベーションやユーザーの同意が必要となるタイミングについて、一般的に採用されているWeb標準に従うこと。

    組み込みブラウザエンジンエ⁠ン⁠タ⁠イ⁠ト⁠ル⁠メ⁠ン⁠ト

    アプリ内ブラウズ機能の場合

    組み込みブラウザエンジンエンタイトルメントでは、アプリに代替ブラウザエンジンを埋め込んで、アプリ内ブラウズ機能を提供できます。アプリ内ブラウズ機能とは、WebブラウザアプリからアクセスできWebブラウザアプリ内で機能するコンテンツを、Webから取得して動的に表示する機能です。これには、アプリに埋め込まれたコンテンツや、アプリでのみ取得可能なコンテンツは含まれません。

    アプリがアプリ内ブラウズ機能を提供する際の機能の中心は、Webブラウズ機能の提供でなければなりません。アプリ内ブラウズ機能を提供する場合、ユーザーインターフェイスが次の条件を満たしている必要があります。

    • エンドユーザーがブラウズセッションをコントロールするための関連コントロールを除き、ディスプレイの大部分を占めること。
    • エンドユーザーが現在表示されているコンテンツを専用ブラウザアプリを開いて閲覧できるよう、システムのデフォルトブラウザに移動するボタンまたはリンクを提供すること。
    • アプリ内ブラウズ機能によってレンダリングされているコンテンツのドメインまたはURLを表示すること。

    アプリで代替ブラウザエンジンを使用してアプリ内ブラウズ機能を提供するには、以下の要件を確認してから、組み込みブラウザエンジンエンタイトルメントのリクエストを送信してください。どのようにして要件を満たし、どのようにアプリに組み込んでアプリ内ブラウズ機能を提供するかなど、埋め込むエンジンに関する情報を提供する必要があります。技術的なガイダンスについては、「例とリソース」セクションを参照してください。

    要件

    エンタイトルメントを取得するには、貴組織がブラウザエンジンスチュワードである必要があります。ブラウザエンジンスチュワードとは、独立したWebブラウザエンジンの運用に関する主たる責任者である法人を指します。

    • 主たる責任者とは、Webブラウザエンジンにセキュリティまたはプライバシーの脆弱性が見つかった場合の対応の統括と脆弱性の解決について、その実施を管理し最終的な責任を負う主体を指します。
    • 独立したWebブラウザエンジンとは、ほかのWebブラウザエンジンとは異なる法人または組織によって管理され、ほかのエンジンとは実質的に異なるアーキテクチャとWeb APIのサポートの両方を備えているWebブラウザエンジンを指します。このエンジンは通常、フォークに加えられた変更を反映する形で更新されるのではなく、フォークへの変更をプッシュします。
    アプリの要件

    アプリは以下の要件を満たしている必要があります。

    • 日本においてiOSのみで配信されること。ただし、対応するエンタイトルメントプロファイルを同様に取得済みの、Apple Developer契約（追加契約を含む）に基づきAppleによって明示的に許可されているその他の司法管轄区域またはAppleプラットフォームでの配信を除く。
    • エンタイトルメントはアプリ内ブラウズ機能のためだけに使用すること。
    • デフォルトのブラウザエンタイトルメントを持っていないこと。
    • 以下の、Web機能のベースラインを提供するWebブラウザエンジンをアプリで使用するための機能要件を満たしていること。
      • 業界標準のテストスイートで実行できるテストで、次の通り、基準以上のパーセンテージを達成していること。
        • WPT（Webプラットフォームテスト）：90%
          • wpt.fyiのフロントページの任意のブラウザを使用して実行したサブテストの最高値のパーセンテージとしての数値
          • テストスイートと互換性のあるオペレーティングシステム上での実行
        • Appleシリコン搭載のiOSデバイス、iPadOSデバイス、またはMac上で実行したTest262：80%
      • ジャストインタイム（JIT）コンパイルが利用できない場合（ユーザーがロックダウンモードを有効にした場合など）、上記のテストスイートの要件を満たしていること。
    • 次のセキュリティ要件を満たしていること。
      • アプリのソフトウェアサプライチェーンの脆弱性の監視、安全なソフトウェア開発（開発中の新機能に対して脅威のモデリングを実行するなど）に関するベストプラクティスの遵守など、安全な開発プロセスの実施に努めていること。
      • 脆弱性開示ポリシーの公開済みのURLを提供していること。このポリシーには、サードパーティ（Appleが含まれる場合がある）からデベロッパへのセキュリティの脆弱性や問題に関する報告する際の連絡先情報、報告に含める情報、ステータスの更新予定時期を記載する必要があります。
      • アプリ内または代替Webブラウザエンジン内で悪用されている脆弱性を、迅速に（例えば、当該の時点で悪用されている最も単純な脆弱性クラスであれば30日間で）軽減することを確約していること。
      • 報告された脆弱性のうち、ブラウザエンジンの特定のバージョン、および（ブラウザエンジンと異なる場合）対応するアプリバージョンで解決された脆弱性の情報を一般公開されているWebページで公表し、そのURLを提供していること。
      • 選択した代替Webブラウザエンジンが、iOS SDK経由ではアクセスできないルート証明書ストアを使用している場合は、ルート証明書ポリシーを一般公開し、そのポリシーの所有者がCertification Authority／Browser Forumに証明書消費者として参加していること。
      • ブラウザエンジン使用時に転送中データの通信を保護するために、最新のTLS（Transport Layer Security）プロトコルをサポートしていることを実証していること。
    プログラムのセキュリティ要件

    以下の要件を満たしている必要があります。

    • 代替Webブラウザエンジン内で、少なくともWebコンテンツを処理するすべてのコードについて、メモリセーフなプログラミング言語を使用するか、ほかの言語でメモリの安全性を向上させる機能を使用していること。
    • 脆弱性クラスを排除したり、エクスプロイトチェーンの形成を大幅に困難にしたりする最新のセキュリティ対策を採用していること。
    • セキュアな設計とセキュアなコーディングのベストプラクティスに従っていること。
    • サードパーティソフトウェアとの依存関係や自社アプリのより広範なソフトウェアサプライチェーンに脆弱性がないか監視し、アプリが脆弱性の影響を受ける場合は新しいバージョンに移行すること。
    • 脆弱性に対応するセキュリティアップデートが提供されなくなったフレームワークまたはソフトウェアライブラリを使用しないこと。
    • 新機能の開発よりも、報告された脆弱性の迅速な解決を優先すること。例えば、Web APIを有効にするために代替ブラウザエンジンがプラットフォームのSDKとWebコンテンツの間で機能の橋渡しを行っており、当該のWeb APIに脆弱性が存在することが確認された場合は、要請があれば当該のWeb APIのサポートを削除しなければなりません。ほとんどの脆弱性は30日以内に解決されますが、一部の脆弱性はより複雑で、それ以上かかる場合があります。
    プログラムのプライバシー要件

    以下の要件を満たしている必要があります。

    • クロスサイトCookie（サードパーティCookie）については、ユーザーが十分な情報提供を受けた上で明示的に同意することを選択している場合や、開いているウインドウのフレームへの何らかの相互作用が発生するポップアップウインドウで互換性のために必要とされている場合を除き、これらのCookieをデフォルトでブロックすること。
    • Webサイトによる監視が可能なストレージまたは状態をトップレベルWebサイトごとに分割するか、またはそのようなストレージまたは状態がサイトを越えて使用されたり監視されたりしないようブロックすること。
    • ユーザーが十分な情報提供を受けて同意した上で機能をアクティベートした場合を除き、デバイス識別子をWebサイトと共有しないこと。
    • iOS（またはアプリが配信されているその他のプラットフォーム）でアプリのプライバシーレポートを生成するために提供されているAPIを使用して、ネットワーク接続にラベルを付けること。
    • 個人を特定できる情報（PII）へのアクセスを提供するAPIを含むWeb API（クリップボードやフルスクリーンアクセスなど）については、情報を提供した上でのユーザーによるアクティベーションやユーザーの同意が必要となるタイミングについて、一般的に採用されているWeb標準に従うこと。
    その他の要件
    • バイナリを提出するたびに、アプリに埋め込まれている代替Webブラウザエンジンの名前とバージョンを提出すること。
    • アプリに埋め込まれている代替Webブラウザエンジンの新しいバージョンが利用可能になったら、15暦日以内に、その新しいバージョンを搭載したアプリのアップデートを提出すること。

    例とリソース

    このセクションでは、代替ブラウザエンジンを使用するための要件を満たす上で役立つ追加のリソースや例について説明します。

    セキュアなSDLC（ソフトウェア開発ライフサイクル）

    満たすべき要件の多くは、アプリに新機能を導入する際にセキュリティとプライバシーを最優先にしたアプローチを必要とします。新機能の開発に着手する時は、まず脅威モデルを作成し、アプリのアーキテクチャとリリース版がこのモデルで特定されたリスクの軽減をどのように保証するのか、計画を立てる必要があります。この保証の実現方法にはさまざまなものがあり、例えば、コード監査、ファズテスト、適用するセキュリティプロパティを検証するテストの記述などを利用できます。すべてのWebコンテンツは、信頼できない、潜在的に悪意のあるものであると想定する必要があります。

    リソース

    セキュリティ対策とメモリの安全性

    iOSまたはiPadOSで現在提供されているセキュリティ対策（Pointer Authentication CodeやMemory Integrity Enforcementなど）や、特定された個々の脅威を軽減するために利用できるプログラミング言語（または言語やコンパイラの機能、その他のツール）についても考慮する必要があります。例えば、Swiftはデフォルトでメモリセーフな言語であり、脆弱性の一般的な原因の多くやその他のメモリ関連のソフトウェアバグを回避する上で有効です。一方、C++などのメモリセーフではない言語にも、メモリの安全性を高めるstd::spanなどの機能があります。さらに、コンパイラのオプションとツール（Cの-fbounds-safetyなど）では、既存のコードの注釈を使用して、デフォルトでメモリセーフな言語を使って機能を書き直すことなく、境界外のメモリアクセスによるリスクを軽減できます。

    リソース

    脆弱性管理

    ブラウザエンジンには未発見の脆弱性が常に存在し、新しい機能は意図しないリスクをもたらす可能性があることを想定する必要があります。したがって、社内のテストやセキュリティとプライバシーを保証する取り組み、または自社のソフトウェアサプライチェーン、サードパーティからの報告などによって脆弱性が発見された時に、脆弱性に対応できるプロセスを整備しておくことが極めて重要です。

    サードパーティ（セキュリティ研究者など）が脆弱性の報告を報告するための手段を提供する場合は、問題の妥当性と原因をすばやく判断するためにはサードパーティからどのような情報の提供を受ける必要があるか検討する必要があります。また、脆弱性の修正にまず優先的に対処しアップデートをリリースするための、通常のスケジュールとは異なるプロセスを整備する必要があります。

    CVE-IDが関連付けられた一般公開されている脆弱性のうち、どのバージョンのアプリ（または代替ブラウザエンジン）でどの脆弱性が解決されたかをユーザーがすばやく判断できることも重要です。

    リソース

    ネットワークセキュリティ

    iOS SDK、特にNetworkフレームワークやSecTrust APIを使用すると、Web証明書の信頼性を評価する作業や、使用する代替ブラウザエンジンに対応する信頼されたルートストアやプログラムを管理したり使用したりする作業負担を減らせます。自社でプログラムを運用している場合は、どのようにしてルート認証局（CA）がプログラムへの参加を申請するのか、また、インシデント（ルート認証局の秘密鍵マテリアルの漏洩など）の発生時に対処するためどのようにインシデント報告を行うのかに関して、情報を提供する必要があります。

    Webで使用されるプロトコルは、新たな脅威に対応し、ユーザーのプライバシーとセキュリティをより強力に保護するために、常に進化しています。現在利用されている代替ブラウザエンジンと互換性があると想定される、非推奨になっていない最新のTLSのバージョンは、TLS 1.2と1.3です。ただし、これは時間の経過とともに変更する可能性があります。代替ブラウザエンジンで非推奨のプロトコルをサポートすることもできますが、それらのプロトコルしかサポートしていないサイトをユーザーが閲覧する時は、ユーザーにその旨を通知する必要があります。

    リソース

    契約