プラットフォームの傾き
(mozilla.github.io)- Mozilla の Platform Tilt は、主要なソフトウェアプラットフォーム上で Firefox が各社のファーストパーティブラウザより不利になる技術的条件を追跡し、セキュリティ・安定性・性能・機能面での競争上の格差を明らかにする
- Apple 関連の問題は、サードパーティ製ブラウザエンジンの禁止、iOS のマルチプロセス・JIT・アクセシビリティ API の制約、既定ブラウザ設定、拡張機能・ベータ配布、ホーム画面 Web アプリの扱いにまで最も広く及んでいる
- Google Android では、ブラウザデータ取り込み API の不在、Google アプリが既定ブラウザではなく Chrome を開く流れ、Firefox Android に低品質な検索結果ページが提供された事例が核心となっている
- Microsoft Windows では、サードパーティ製ブラウザが既定ブラウザをプログラム的に設定するのが難しく、Search・Copilot・Widgets などの流れが Edge を優先する
- 共通して、ユーザーの既定ブラウザ選択、ブラウザ間のデータ移行、エンジン機能、配布・テスト・拡張機能へのアクセス性が、プラットフォームごとの自社ブラウザに有利に働いている
Platform Tilt が追跡するもの
- Platform Tilt は、主要なソフトウェアプラットフォーム上で Firefox がファーストパーティブラウザより不利になる技術的事例を追跡するダッシュボードである
- 対象はセキュリティ、安定性、性能、機能であり、より公平な競争環境を作るための変更を提案する
- リアルタイムの課題議論は platform-tilt issue tracker で行われている
Apple プラットフォームのブラウザエンジン・iOS 機能制約
- App Store forbids third-party browser engines: Apple App Store Review Guidelines の Rule 2.5.6 は、Web ブラウジングアプリが適切な WebKit フレームワークと WebKit JavaScript を使用することを求めている
- このポリシーのため、Firefox は iOS で Gecko として配布できない
- macOS など他の Apple プラットフォームでも、App Store 経由での Firefox 配布に影響する
- Web ブラウザにサードパーティ製ブラウザエンジンを許可するよう、App Store ポリシーを変更すべきである
- Support for third-party multi-process applications on iOS: 現代の Web ブラウザは、サイトごとのプロセスや GPU のような機微な機能専用のプロセスを含むマルチプロセスアーキテクチャを使用している
- Safari は iOS でマルチプロセス構造を使っているが、Safari の WebKit エンジンを使わないサードパーティアプリには同じメカニズムが提供されていない
- iOS は、隔離された子プロセスを作成し、効率よく通信するメカニズムを提供すべきである
- 要件には、ユーザーの閲覧操作に応じた子プロセス数と寿命、制限付き権限設定、メッセージングと共有メモリ、read/write または read-only の共有メモリ領域、親・子プロセスの独立した entitlement、バンドル内ライブラリのロード、Metal または OpenGL による IOSurface レンダリングとプロセス間共有が含まれる
- Firefox は複数の OS で共通のコードベースを使うため、プロセス管理インターフェースと動作は macOS・Android など他のプラットフォームと概ね似ている必要がある
- JIT Support on iOS: 高性能な JavaScript/WebAssembly エンジンを配布するには、ブラウザプロセスが書き込み可能かつ実行可能なメモリ領域を作成できる必要がある
- iOS アプリは
mmap(2)システムコールでこのようなメモリ権限を作成できない - Safari の WebKit レンダリングエンジンには例外があり、書き込み可能・実行可能なメモリ領域を作成できる
- macOS には Hardened Runtime entitlement である com.apple.security.cs.allow-jit に相当する方式があり、iOS も非 WebKit ブラウザに同等の entitlement と
pthread_jit_write_protect_np、sys_icache_invalidateAPI の使用権限を提供すべきである
- iOS アプリは
- Accessibility APIs on iOS: iOS のアクセシビリティ API ドキュメントは不完全であり、Web ブラウザがアクセシビリティ関連の Web 標準をサポートするために必要な API の多くが文書化されていない
- WebKit には実行時にロードされるクローズドソースのシステムバンドルがあるとみられ、そのため使い方の推測も難しい
- “visited”、“radio button” のような trait 整数定数と、“value changed” のような notification type 整数定数の一部が公開されていない
- WebKit が使用するすべてのアクセシビリティ API は文書化され安定しているべきであり、理想的には WebKit もサードパーティ製ブラウザエンジンと同じ方法でそれらを使用すべきである
Appleプラットフォームにおけるユーザー体験・配布・拡張の格差
-
Messages integration on iOS: iOS Safariのホームページは、Messagesアプリで最近受信したリンクや送信元の連絡先を表示するが、サードパーティ製ブラウザにはMessagesデータへのアクセス権限がないため、同じ機能を提供できない
-
Importing browser data on iOS: iOSでは、履歴、ブックマーク、Cookieのようなブラウジング情報にサードパーティ製ブラウザがアクセスできず、インポートAPIもない
- このデータは機微情報だが、主要なデスクトッププラットフォームでは同様のインポート機能が利用できる
- iOSは、ヘルスケアやフィットネスデータのように、ユーザーの同意に基づいて機微データへのアクセスを仲介できる
- データをインポートできないと、Safariから別のブラウザへ乗り換える際に摩擦が生じる
-
Setting and checking default browser on iOS: iOSは、サードパーティ製ブラウザが自分自身をデフォルトブラウザに設定するよう求めるシステムプロンプトを表示する機能を提供していない
- Androidはbrowser roleのリクエストを通じて、macOSはLSSetDefaultHandlerForURLSchemeとLSSetDefaultRoleHandlerForContentTypeを通じて、同様の機能を提供している
- iOSブラウザは設定UIへdeep linkできるだけで、ユーザーが設定画面を理解して自分で変更する必要がある
- iOS 17.2.1で、Settings検索に「Default browser app」または「Default」と入力しても、デフォルトブラウザ変更の結果が表示されない事例がある
- サードパーティ製ブラウザは現在、自分がデフォルトブラウザかどうかを検知することもできないため、ユーザーの意図に基づいてブラウザを最適化したり、適切なタイミングでデフォルトブラウザの変更を求めたりすることが難しい
-
Origin-Based Associated Domains dependent features for third-party browser engines on iOS: 非WebKitブラウザがpassword autofill、one-time codes、passkeys、Apple Payをサポートするには、Webコンテンツのoriginに基づくassociated domainを指定できる必要がある
- WebKitベースのブラウザは、ブラウザアプリのassociated domainを、ユーザーが閲覧中のドメインでoverrideできる
- 例えばexample.comのパスワード入力フィールドで、ブラウザはそのフィールドがexample.com originに属していることを示し、パスワードマネージャーがexample.comのスコープで呼び出されるようにする必要がある
- Apple Payのサポートには、Safariと同様に、登録済みのApple Pay受取人が決済を受けられるよう追加の変更が必要になる可能性がある
-
Browser extension support on iOS: SafariはiOS App Storeで配布される拡張機能をサポートしているが、サードパーティ製ブラウザはApp Store Review Guidelines 2.5.2のため、独自の拡張機能を提供しにくい
- ブラウザ拡張はWebエコシステムの中核的な要素であり、開発者がブラウザに機能を追加して、ユーティリティ、使いやすさ、システムアプリとの相互運用性を高められるようにする
- サードパーティ製ブラウザが独自の拡張カタログを使えるよう、App Storeのソフトウェア要件を緩和すべきである
-
Beta testing on iOS: iOSではApp Storeにベータ版アプリを配布できず、TestFlightを使う必要がある
- TestFlightには10,000人の制限があり、大規模ブラウザのベータユーザー規模に比べて小さい
- 制限に達すると、古いユーザーを手動で削除する必要があり、メンテナンス負担が生じる
- ユーザーはTestFlightアプリのインストール、access codeの申請、受信待ち、コード入力の手順を経る必要がある
- Safariの新バージョンはiOSオペレーティングシステムのベータに含まれるため、同じ制限を受けない
- 解決策として、ブラウザのApp Storeプレリリースビルド配布の許可、またはTestFlightのユーザー制限撤廃と公開リンクによる無制限配布が提案されている
-
iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: iOSとmacOSの
Search WebまたはSearch with <Search Engine>コンテキストメニュー、macOSメニューバーのServices検索エントリポイントは、デフォルトブラウザに関係なくSafariで検索を実行する -
SFSafariViewController should respect the user’s default browser: SFSafariViewControllerは、iOSアプリがWebコンテンツのレンダリングをユーザーのブラウザに委ねつつ、アプリ内に埋め込めるようにする高レベルAPIである
- このAPIは、ユーザーのデフォルトブラウザに関係なく、常にSafari版を使用する
- Webコンテンツの表示体験に一貫性がなく、代替ブラウザからトラフィックが流出する
-
Browsers with alternative engines should be able to ship a single binary & bundle on iOS: Appleの現在の提案は、独自のブラウザエンジンを使おうとするブラウザベンダーに、既存アプリをアップデートする代わりにEUで別アプリを配布することを求めている
- 既存のEUユーザーは新しいアプリへ移行する必要があり、これは実行可能性が低く、競争上の障壁を生む
- Firefoxの懸念例には、WebKit FirefoxからGecko Firefoxへの発見・移行の難しさ、Gecko FirefoxのEUユーザーがEU外に30日を超えて滞在した場合にアクセスを失う問題、EUへ恒久的に移転した非EUのWebKit Firefoxユーザーが更新されない「orphaned」バージョンに残る問題が含まれる
- ブラウザ開発者は完全に別個の2つのアプリを開発・維持・配布しなければならず、データ移行の複雑さ、ユーザー離脱、獲得減少、EU iOSユーザー向けの反復的なA/Bロールアウト制限が生じる
- 代替案として、世界共通の単一バイナリとバンドルに2つのエンジンのwebviewを含め、OSが起動時にBrowserEngineKit eligibilityをアプリに通知する方式が提案されている
-
Web developers should be able to test with alternative browser engines on iOS regardless of location: BrowserEngineKit は当初発表時、EU 外のデバイスで独自エンジンのテストを禁止する位置制限があった
- この制限は 18.2 beta でローカル開発とテストについては解除されたが、Web 開発者には依然として残っている
- EU 外の Web 開発者も EU ユーザーをサポートする可能性があるため、場所に関係なく代替ブラウザエンジンでサイトを簡単にテストできる仕組みが必要
-
Browsers with alternative engines should be able to install and manage home screen web apps on iOS: 代替ブラウザエンジンが iOS のホーム画面に Web アプリを追加できる API はあるが、そのアプリは Safari で開かれる
- インストール前後でエンジンごとの機能、ユーザー状態、設定が変わり、体験が分断される
- Apple はセキュリティを理由に、非 WebKit エンジンによるホーム画面 Web アプリのレンダリング許可に反対していた
- ホーム画面 Web アプリの基本的なセキュリティ要件は、通常の Web 閲覧ですでに適用されているサイト間サンドボックス化と分離要件と同じ
- Android は長年、Web アプリのレンダリングをサードパーティ製ブラウザエンジンに委任しており、iOS でもこれを有効にすべき
Google Androidのデータ移行・既定ブラウザ・検索体験
- Importing browser data on Android: Androidでは、閲覧履歴、ブックマーク、Cookieのようなブラウジング情報にサードパーティ製ブラウザがアクセスできない
- データはWebブラウザアプリのdata directoryに保存され、サードパーティ製ブラウザが直接アクセスすることはできない
- インポートを可能にするAPIやContentProviderも存在しない
- データをインポートできないことは、Chromeから別のブラウザへ乗り換える際の大きな摩擦になる
- Some Android features launch Chrome instead of the user’s default browser: プリインストールされたGoogle applicationのGoogle Search、Discoverなどの機能は、ユーザーの既定ブラウザの選択を無視し、外部Webサイトへのリンクを常にChromeで開く
- ホーム画面の検索バーやアプリランチャーなどの組み込み機能にも追加の入口がある
- リンクがChromeで開かれるたびに、ユーザーは既定ブラウザから離脱する
- 外部リンクを開くすべての組み込みアプリと機能は、ユーザーの既定ブラウザで開くべきである
- Lower quality search result pages in third-party browser engines on Android: AndroidではWeb検索体験が複数の組み込み機能と密接に統合されており、FirefoxにChromeより品質の低い検索結果ページが提供された事例がある
- 同じ検索語で、Firefox AndroidはChromeより情報量が少なく、デザイン品質も低いページを受け取っていた
- これは厳密にはGoogle Search Webサイトの問題だが、Androidにおける検索の重要性と統合度の高さにより、サードパーティ製ブラウザの選択をためらわせるユーザー体験の格差につながる
- Firefoxでそのページが動作しないようにする技術的な制約はない
- このIssueの状態はclosedである
Microsoft WindowsのEdge優先フロー
- Setting default browser on Windows: Windowsは、サードパーティ製ブラウザが自分を既定ブラウザに設定するようプログラムから要求する機能を提供していない
- ブラウザのインストール後も、ユーザーはOSの設定に移動して自分で選択しなければならず、これはEdgeの利用を継続させる摩擦と惰性を生む
- AndroidとmacOSは、システムプロンプトや関連APIを通じて、ユーザーが簡単に承認・拒否できるパターンを提供している
- Windows 10では設定UIで何度もクリックし、二重確認する必要があり、Windows 11には
Set defaultボタンがあるが十分ではない
- Default browser is set to Edge by several Windows flows: Windows 10と11は、Microsoft EdgeがWindowsの「recommended」ブラウザであるというメッセージを継続的に表示し、既定ブラウザをEdgeに変更するUIを提供する
- 一部の文言は「recommended browser settings」を適用するよう求めるが、既定ブラウザの変更を明確に示していない
- 例はWindows Updateなど自動的に表示されるUI面で追加・削除され、常に変化している
- Windowsコンポーネントはユーザーの既定ブラウザを直接変更できるが、サードパーティ製ブラウザは
ms-settings:プロトコルのdeep linkを使う必要がある - Windowsも、サードパーティ製ブラウザに提供されているものと同じ機能とAPIを使うべきである
- Some Windows features launch Edge instead of the user’s default browser: Windowsの少なくとも3つの主要機能は、URLを現在の既定ブラウザではなくMicrosoft Edgeで開く
- Windows SearchまたはStart Menu Searchは、タスクバーの検索ボックス・検索ボタン、スタートメニュー入力、
WIN+Sショートカットで表示され、検索結果と記事リンクはいずれもEdgeで開かれる - Windows CopilotはWindows 11で画面右側にドッキングされたウィンドウとして表示され、回答やレンダリング領域内のリンクをEdgeで開く
- WidgetsはWindows 10では「news and interests」と呼ばれ、ニュース・天気・株価・スポーツのスコアなどの情報を表示し、WebページのリンクをEdgeで開く
- Windows SearchまたはStart Menu Searchは、タスクバーの検索ボックス・検索ボタン、スタートメニュー入力、
1件のコメント
Hacker News の意見
Android と Microsoft のどちらにも、ユーザーが選んだブラウザではなく独自の方法で開くアプリがあると言われているが、より大きな問題は、アプリ内でリンクをタップしたときに内蔵 WebViewをブラウザのように表示することだ
その中で行う Web 上の活動をアプリが監視できてしまう。Android Play Store と iOS App Store には、すべてのサードパーティ Web サイトをユーザーのブラウザで開くよう強制してほしい
アプリを「Web ブラウザ」と「Web ブラウザではないもの」に分類し、「Web ブラウザではない」アプリにはアクセス可能なドメインを短く 5〜10 個程度だけ登録させ、それ以外は OS がブロックする、という形が可能だ
Facebook、FB Messenger、Google Maps のように、主な用途が Web 閲覧ではないアプリは明確に「Web ブラウザではないもの」と見なせる
こうすれば内蔵 WebView による監視問題を防ぎ、ブラウザプロファイルに同期されたパスワード・住所・ブックマーク・閲覧履歴をそのまま使える。世界を好きに決められるなら、リンクを開くアプリには「プライベートブラウザウィンドウで開く」コンテキストメニューも求めたい
そこでアプリ内で開くことをデフォルトに変更しつつ、既定ブラウザを使うオプションは残した
本当に重要な問題だという点には同意するし、協力したいなら Open Web Advocacy に連絡してほしい
アプリが関係のないページ、たとえばユーザーが提供したリンクを開くだけでも、既定ブラウザではなく「custom tab」で開くよう推奨しており、その明示的な目的は、ユーザーをアプリから離れさせずエンゲージメントを維持することだ
当然ながら、ユーザーがシステム全体でオフにできる設定はなく、アプリごとに設定を探さなければならず、そもそも設定があることを願うしかない
https://android-developers.googleblog.com/2023/02/bringing-b...
Android がカメラのような実行時権限を追加してからメジャーバージョンで 9 世代が経ったが、インターネットアクセスはいまだに権限を要求しない
「アクセス可能なドメイン」が実際に何を意味するのかも曖昧だ。明示的に移動した URL のドメインだけを検査するなら緩すぎて回避が容易で、すべてのリクエスト URL を検査するなら厳しすぎて、多くの開発者が自分のサイトすら正しく読み込めなくなる可能性がある
「App Storeがサードパーティ製ブラウザエンジンを禁止している」という点についてMozillaが問題提起するのは正当だが、その糸を引っ張りたいのかは分からない。
iOSデバイスではSafariの独占があるため、かなりの数の開発者が非Chrome対応を気にしている。今はやむを得ず対応しなければならない。
ユーザーに「壊れている機能はChromeでは壊れません」というメッセージが届き始めれば、それは独占への道であり、その後はGoogleが新しいWeb標準を作るとき、合意をあまり必要としなくなる。
現状もひどいが、さらに悪くなる可能性もある。この予想が外れてほしい。
FirefoxがGeckoとGeckoベースのWebExtensions、とりわけ広告ブロッカーを実装できないようにしているAppleの制限がなくなれば、iOSでのFirefoxのシェアは上がるほかない。
そうして生まれたiOS Firefoxユーザーは、デスクトップ版Firefoxと広告ブロック可能なiOS Firefoxを同期できるようになるため、デスクトップでもFirefoxを使うよう促される可能性がある。
Firefoxはたいていそのまま動くし、仮にそうでなくても、常に追加作業が必要な放置されたプラットフォームであるSafariのせいで、さらに別の技術スタックまで気にしたくはならない。
現状を擁護する論理にはうんざりしている。現状維持は良い方向に進んでおらず、大胆な措置なしには変わらないだろう。Appleの現状維持を擁護する側にも、今後どう改善していくのかという計画は見えない。
SafariだけではChrome支配を防ぐには十分ではなく、EUのApp Store規則が施行された後にはブラウザエンジンの開放が強制される可能性も小さくないため、長期的には現状維持そのものも保証されていない。
今は、テクノロジー企業に対して歴史的に強い反トラスト法執行の意志を示してきた米国政権が終わりに近づいている時期だ。Biden政権がどれほど反トラスト寄りかを十分に理解していない人が多い。
この政権があと4年続くかもしれないし、そうでないかもしれないが、その不確実性を考えれば、初期のWindows反トラスト事件以降、Google/Apple/Microsoftへの実際の介入を求める最高の機会の一つだ。
反トラストに開かれた政権、ビッグテックに対する消費者感情の変化、iOSをめぐるAppleへの圧力、6月に広告ブロッカーを弱体化させようとするGoogleの動きが重なっている今は、現状変更を強く推し進めるのに良い時期だ。
リスクがないわけではないが、さらに待っても状況は良くならない。待つほどFirefoxの重要性は下がり、政権が変わる可能性は高まり、Mozillaが世論を活用するのは難しくなる。
Mozillaがこの主張に100%簡単に勝てる瞬間は来ないし、今やらなければ最終的に市場から完全に押し出されるだろう。
Appleを含め、全員に対して全力で問題提起することを支持する。iOS開放後のChrome支配が心配なら、その問題はGoogleを規制することで扱うべきで、今こそその主張をする最良の時期だ。
AndroidユーザーとしてFirefoxを使わない主な理由は、反競争的行為ではなく、遅く感じるからだ。
Firefoxではホームページの読み込み時にレイアウトが揺れることが多く、キーボードのアニメーションがたまに跳ね、｢離して選択｣メニューオプションを使えない。
https://github.com/mozilla/platform-tilt/issues/3
iOSのJIT対応は、「EUがiOSでサードパーティ製レンダリングエンジンを強制するだろう」という議論で、あまりにも十分に扱われていない要素だ。
AppleはアプリにJIT対応を許可するのだろうか。ブラウザ開発者が申請しなければならない新しい権限を作るのだろうか。興味深くはあるが、そうはならない気がする。
com.apple.developer.web-browser.public-key-credential
https://developer.apple.com/documentation/bundleresources/en...
これが正確か知っている人はいる？ 以前のバージョンでは正しかったが、今はもうサポートされていないのだろうか？
関連記事: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
https://news.ycombinator.com/item?id=39059255から来たが、そこにはコメントがない。
macOSで選択範囲を右クリックしてWeb検索を選ぶと、デフォルトブラウザを別のものに指定していても、常にSafariが開く。おそらくMail.appでだけそうなのかもしれないが、この項目は抜けているようだ。
Android版Firefoxで最大の不満は、たまにアドレスバーにドメインを入力してEnterを押しても何も起きないこと
この動作は不規則で、https://forum.syncthing.net のような一部のWebサイトだけに影響する
タブを閉じたり別のタブを使ったりしても解決せず、アプリを強制終了しないと直らない
不満はあっても、Googleのブラウザよりはまだまし
大半は理解できるが、iOSのMessages統合の項目は印象がよくない
ユーザーが選択する必要のある「最近送信したリンク」API程度なら問題ないだろうが、メッセージデータ全体へのアクセスは、開発元がMozillaであってもサードパーティアプリには絶対に許可したくない
iOS拡張機能については、OrionはChromeとFirefoxの拡張ギャラリーの両方から拡張機能をインストールできるので、これは実際には問題ではないか、App Reviewを通過した後に何年も維持されているということに見える
[0]: https://github.com/mozilla-mobile/firefox-ios/issues/7374
[1]: https://github.com/mozilla-mobile/firefox-ios/issues/9155
Google Colabでのコピー＆ペーストはChromeでは正しく動作するが、Firefoxではそうではない
「閲覧履歴、ブックマークしたサイト、Cookieのような閲覧情報がAndroidのサードパーティブラウザからアクセスできない」というが、ユーザーの立場で、なぜサードパーティアプリケーションに自分のブラウザの閲覧履歴、ブックマーク、Cookieへアクセスしてほしいと思うのか？
それは明らかなプライバシー漏えいだ。Firefoxは、自分がFirefoxを使っている間にFirefoxが作ったデータだけを持っていけばよく、別の文脈のデータはだめだ
ところがAndroid版Firefoxはそれすらサポートしていない :facepalm:
https://github.com/mozilla-mobile/fenix/issues/417
該当Issueでも検証されていないインポート機能を求めているのではなく、Androidがユーザー同意に基づいてほかの機微なデータへのアクセスを仲介できると言っている