Apple によるブラウザエンジン規制の緩和
Intro
以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。
- Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple
ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。
筆者が公開情報を読んで解釈したものなので、内容は保証しない。
前提
iOS/iPadOS に入れられるブラウザには、WebKit を用いる必要があるという制限があった。
つまり、App Store から Chrome や Firefox を入れても、それは PC にインストールできる Chromium や Gecko ベースではなく、WebKit の上に実装されたもの。つまり、UI だけが異なる Safari のようなものだった。
従ってこれまで iPhone にインストールできた Chrome や Firefox は、Chromium や Gecko に実装されていても、WebKit が実装してない機能は使えなかったのだ。
もし WebKit 以外のエンジンでブラウザを作っても、それを App Store に公開する際に申請で落とされることになる。これは、ブラウザという非常に重要なアプリの上で行われるユーザのアクティビティや、そのパフォーマンス体験を Apple が守るといった理由がある。もしストアや実装が自由になれば、マルウェア化したブラウザアプリの普及でユーザが被害を被る可能性が否定できないからだ。
一方、このような Apple の制限は、独占禁止法に抵触するという問題が指摘され、長い間調査と議論が行われてきた。一定の安全性は保たれるかもしれないが、自由にアプリを作成できず、健全な経済活動に寄与できてないというものだ。
今回は、特にこの分野に敏感な EU からの要請を飲んだ形で、Apple が EU 限定で制限を緩和することになった。
日本での対応
今回は EU だけであるが、日本でもこの問題は政府を中心に調査、議論、パブリックコメントの募集などが行われている。
- モバイル・エコシステムに関する競争評価 最終報告
この報告書では、ブラウザに関する部分に以下のようなまとめがある。
(ウ)対応の方向性
以上を踏まえ、一定規模以上の OS を提供する事業者が、ブラウザを提供するサードパーティに対して、自らのブラウザ・エンジンの利用を義務付けることを禁止する規律を導入すべきである。
この分野で日本は、海外の事例を参考にしてこうした法令を整備することが多いこともあり、日本でも同様の制限緩和が行われる可能性は、ゼロではないと見て良さそうだ。
EU でのブラウザエンジン緩和
今回の一連の発表の中で、ブラウザに関するものは以下だ。
- Using alternative browser engines in the European Union - Support - Apple Developer
この内容について、詳細を見ていく。
Browser Engine Entitlement
EU において、iOS17.4 から WebKit 以外のブラウザエンジンが利用可能になるというものだ。
申請には、2 つの種類があるとされている。
- Web Browser Engine Entitlement
- ブラウザを開発する場合に通すべき申請
- Embedded Browser Engine Entitlement
- 埋め込み用途で利用する場合に通すべき申請
ここで認定されたデベロッパーに、ブラウザ開発に必要な API (JIT や Multiprocess など) を解放する。
今回は Web Browser Engine Entitlement の方に絞る。
Web Browser Engine Entitlement
各項目ごとに条件を要約する。
なお、現時点で WPT 90% と Test262 80% を満たすブラウザは、いわゆるメジャーブラウザくらいしか存在しないだろう。
PKI についても、Keychain を推奨しつつも、自前で持つのを禁止はしてないようなので、そこは意外ではあった。Firefox も Chrome も、PC 版は自前で持っているため、そことの兼ね合いもあるのかもしれない。
1 つ目から、メモリ安全な言語などと指定してくるのもちょっと意外だった。後半でわかるが、Rust を推奨してるという意味では無いようだ。
Cookie や IDFA も、基本的に WebKit ベースのものを維持する。今回の緩和で Chrome のシェアがまた広がったとしても Cookie は ITP 相当を求めている。
Permission 周りは、条件や UI がまだブラウザ間や API ごとに揺れている部分もあるため、"Follow commonly adopted web standards" とあるが、それがなんなのかは変わっていくと思われる。そこを、WebKit ベースに準拠するように求めることになるのだろう。
Requirements
Program Security Requirements
Program privacy requirements
Examples and resources
Secure SDLC (Software Development Lifecycle)
前半では、「Web コンテンツは悪意に満ちているため、読み込む際の注意が必要である」と述べており、セキュリティ面、脆弱性対応、セキュアコーディングに注意を払うよう求めている。
後半は、メモリセーフに焦点を当てている。ここではメモリセーフな言語として Swift を挙げ、C++への注意や std::span の紹介などを行っている。
とにかく、バグのあるブラウザが iPhone で動作することを防ぎたいという意志が伝わる。
Vulnerability Management
脆弱性報告を受け付ける体制や、トリアージや緊急リリースパスなど、対応プロセスを組むよう求めたり、CVE の採用を推奨している。
現在の主要なブラウザベンダはこれを行っているが、「これを機に自分も独自ブラウザを作って iPhone にリリースする」と考えた人が、Blink をフォークしてコードを書けたとしても、ここが一番大変かもしれない。
Network Security
前半は PKI について。iOS の SDK に任せるのが推奨だが、自分で Root Store を運用する場合は、その運用やインシデント管理について注意が必要だ。
後半は TLS について。1.2, 1.3 をベースとして、更新されたら対応していくこと。非推奨のプロトコルを必要とする際はユーザに通知すること。
前述したが、自前 Root Store を禁止してない。また、TLS 1.0 や 1.1 も禁止はしてない。この辺は、思った以上に緩めている点で意外だった。
その他
独自エンジンを開発する上での技術的ガイダンスが提供されている。
それぞれ実装上の API や、細かな条件が記されているが、特に最後のものは、対応すればデフォルトブラウザを自前エンジンのものに変更できる。
つまり、例えば Chromium Chrome をインストールして、それをデフォルトにする、ということが iPhone でも可能になるということだ。
所感
いよいよ来たなという印象だ。
細かい実装がどうなるのかは、実際に Chrome や Firefox が出てみないとわからないのが実際なので、実装面の制約についてはこれだけを見てもなんとも言えない。
しかし、WPT 90%, Test262 80% はハードルとしては非常に高いため、新しくブラウザエンジンを実装して参入しようとしても、そんなに簡単ではない。習作のブラウザを公開するといったことは不可能だろう。
また、もともとサイドローディングの根拠の 1 つに、Apple による審査を通じたユーザの安全確保が強調されていた通り、別エンジン実装を許すからといって、その側面を緩めいないように強めの釘を打っていることを見て取れる。
つまり、仮に実装できても、体制の面で新規参入の敷居はやはり高い。
逆に、これらの条件を既に満たしている Chromium, Gecko をベースとした実装には、門戸が開かれた状況になった。
Chrome だけでなく、Edge, Brave, Vivaldi, Opera といった Chromium 派生のブラウザも全て PC 同等の機能が提供可能になる。
これは Chromium ベースのブラウザのシェアが広がる可能性を示唆し、そこが最も Web に与えるインパクトが大きい部分と言える。
ブラウザエンジンの多様性
iPhone に Safari 以外のブラウザをわざわざインストールするユーザがどのくら増えるかわからない。もし iPhone でも Chromium Chrome をインストールしてデフォルトブラウザにすることが一般的になれば、Safari シェアを支える最後の砦が崩れることにも繋がり得る。
そうなった場合に懸念されるのが、ブラウザエンジンの多様性だ。
Edge, Opera, Brave, Vivaldi など Chromium をベースとした「ブラウザ」の多様性は増える一方、Trident/EdgeHTML を失って以降ブラウザエンジンの多様性とパワーバランスはかなり変わってしまっている。
使っているユーザーや、サービス開発者にとっては大きな問題を感じないかもしれないが、標準化などの場面で勢力の寡占は起こってしまうことには一定のリスクが指摘され続けている。
もちろん、EdgeHTML が無くなったことはネガティブな影響ばかりではなかった。MS のチームは Chrome チームがカバーしきれてない OpenUI などにリソースを増やし、HTML 周りの更新を推し進めているのも事実だ。また、リソースを Edge の UI に回せたからか、Collection, Vertical Tab, Split Screen, Bing Chat など、最近の Edge はブラウザとして非常に使いやすくなっているとも感じ、筆者はここ数年 Edge をメインブラウザ、Chrome を開発/検証用にしている。
問題の根幹は「ブラウザエンジンをゼロから作ることはもうできない」という点だ。多少はサードパーティのライブラリを入れたとしても、今から WPT 90% を達成するブラウザエンジンの開発を目指しても、達成に何年かかるかわからない。その間にも WPT の方が膨らみ、追いつくのは不可能と言っていいだろう。
結果 Chromium のフォークがベースとなり、ベースに入る機能のイニシアチブは Google が握っていることになる。Linux カーネルのように、それをみんなでメンテするという考え方もあるが、Google が提唱し Mozilla/Apple の standard position で否定されている機能が少なくないことは、無視できない事実だ。
では、ユーザがわざわざ iPhone に Chromium Chrome や Gecko Firefox を入れるモチベーションはあるだろうか? 一般的に見れば、ユーザ側が機能の有無などで積極的に選択するかというと怪しい。あっても、常用アカウントの連携などといった外的要因の方が多いと思われる。
むしろ最悪の想定は、Web サービスの開発者側が Chrome でしか見れないページなどを提供する可能性だ。iPhone でサイトを開いても、Store へ誘導しインストールを求めるのは、無料である点で PayWall よりは敷居が低い。その結果、Privacy Sandbox 系の API が動くなら、メディア系のサービスはそちらを強制したいかもしれないし、Fugu 系の API が動けばデバイス機能を活用したいサービスはそちらに誘導したい。そこまで積極的な理由でなくても、サービス開発者にとって iOS Safari の評判は決して良かったとは言えないため、単にサポートブラウザを減らすことは、コストメリットに繋がるのを否定できない。Interop は、こうしたバランスの調整のための活動であり、既に一定の成果が出ているが、それでもやはり複数ブラウザの対応に苦労している開発者がいるのも事実だ。
近年の Safari のアップデートには、それまで音沙汰なかった機能が続々と追加されたように思うが、これもそうしたギャップをなるべく埋めた上でこの日を迎えたかったのではないかという邪推もできる。しかし、API によっては Standard Position で否定され Safari には絶対に入らないことが決定済みなものもあるため、これを Chromium が提供できるとなると、その格差はスタンスよりも星取表で評価されてしまう可能性もあるだろう。
今回の決定は、独占禁止法をベースとしたビジネス上のフェアネスに由来するものだ。それが Web というエコシステムに、長期的にどういう影響を与えるかとはまた別の視点が必要だ。Apple は WebKit を必須にすべきだという気はないが、この後ろ盾が無くなった Apple が WebKit をどれだけ本気で育て、健全なシェア争いを繰り広げてくれるかはかなり重要になると思う。そして、サービス開発者についても、シェアやコストを理由に安易にサポートを狭めるようなことがないよう、Interop などに Web 全体で取り組んでいくことも重要だと思う。
この話が「iPhone でのブラウザエンジンの選択が自由になった」という表面上の変化以上の大きな流れとして、今後の Web にどう影響していくか。はたまた全て杞憂で特に何ごともなく進んでいくか。2024 年の重要なトピックとして、注視していきたい。