- SafariとFirefoxは、TikTok、Netflix、Instagramのような特定ドメインでレンダリングやAPIの挙動を変えるコードを配布している
- Firefoxのabout:compatではサイト別介入とトグルを確認でき、カスタムCSS・JavaScriptの注入やユーザーエージェント偽装を行っている
- SafariのWebKitはこれをquirksとして管理し、PiP動画・画像整列・ポップオーバー・ストリーミングアクセスの問題をドメイン単位で回避している
- Chromeは別個の例外ファイルをほとんど必要としないが、それはWebがすでにChrome中心に作られており、他ブラウザが差異を補正しているためである
- こうした例外はログやコンソールに現れにくいため、開発者はFirefoxとSafariで定期的にテストし、quirksファイルに含まれていないか確認すべきである
ブラウザ内のドメイン別例外処理
- SafariとFirefoxは、ユーザーが訪れたドメインに応じてレンダリングやAPIの挙動を変えるコードを配布している
- TikTok、Netflix、Instagram、SeatGuruのようなサイトが、こうしたサイト別処理の対象になっている
- 関連ソースは、WebKitの
Quirks.cppとFirefoxのWebCompat interventionsで公開されている
- このコードは、「特定ドメインなら別のレンダリングを行う」あるいは「特定ドメインならAPI呼び出しを別扱いする」という形で、ブラウザのレンダリングエンジンに組み込まれている
- Chromeは同様の例外ファイルを事実上必要としておらず、WebがすでにChrome中心に作られているという非対称性が表れている
Firefoxのabout:compat
- Firefoxのアドレスバーに
about:compatと入力すると、サイト別介入の一覧とトグルスイッチを確認できる
- 各項目は特定のWebサイト向けのカスタム修正であり、無効にするとサイトが壊れる様子を確認できる
- FirefoxのWebCompat systemは、特定ドメインにカスタムCSSとJavaScriptを注入する
- ブラウザを誤検知するサイトに対しては、ユーザーエージェント文字列を変更して送信する
- こうした介入は、Webが壊れて見えないようにバグを覆い隠しており、Mozilla Bugzillaではバグ報告やサイトへの連絡の試みまで追跡されている
Safariのquirks
- SafariのWebKitエンジンではこの種の処理をquirksと呼び、
Quirks.cppがGitHubで公開されている
- WebKitのコードには、Facebook、X、Redditが画面外にスクロールされた
<video>をPiPモードかどうかに関係なく一時停止すると書かれたコメントがある
- Safariは
facebook.com、x.com、reddit.comを検知し、Picture-in-Picture動画の処理を変更している
- サイト側の動画コードが壊れていても、その企業が修正するのを待たず、ブラウザ側がすべてのユーザー向けに回避策を配布している
- SeatGuruに関するコメントには
FIXME: Remove this quirk if seatguru decides to adjust their site.とあり、サイトが修正されれば例外を削除できることを示している
- コミット履歴を見ると、ここ数か月の間にも複数のサイト別修正が追加されている
- Zillowのfloorplan画像が中央揃えされない問題
- TikTokで「please upgrade your browser」というメッセージが表示される問題
- Instagram Reelsが再生中に不規則にリサイズされる問題
- Netflixの「Episodes and Info」ボタンがポップオーバーを誤って閉じてしまう問題
- Twitchがタブ切り替え時にPiP動画を一時停止する問題
- Amazon Prime VideoがSafariユーザーに視聴を許可しない問題
Chrome中心のWebと非対称性
- WebKitのquirksやFirefoxのWebCompatは、壊れたサイトを直すだけでなく、Chromeが「動作すること」の基準を左右している状況も補正している
- 一般にChromeが機能をリリースすると、その市場支配力ゆえに開発者はその機能を使い、他ブラウザはその機能を実装するか、サイト別例外で差を覆い隠すことになる
- SafariやFirefoxが追いつく頃には、例外処理はすでに数百万のユーザーへ配布された後になっている
- WebKitには、Amazonの動画ページや複数のストリーミングサービスでSafariをChromeに見せかけるユーザーエージェントのオーバーライドが含まれている
- こうしたサイトはChromeかどうかを判定して他ブラウザに劣化した体験を提供するため、WebKitはSafariユーザーを守るためにブラウザの正体を偽る
- 現在の
Quirks.cppには、次のような偽のChromeユーザーエージェント文字列が含まれている
auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;
- Firefoxも同様に動作しており、
about:compatの多くの介入は、サイトに「私はChromeです」と伝えるユーザーエージェント偽装である
- Mozilla wikiでは、一部サイトがブラウザ判定の結果に応じて「アクセスを完全に遮断したり、別のデザインを表示したり、別の機能を提供したりする」と説明している
- この構造はフィードバックループを生む
- 開発者はChromeのシェアが高いためChrome基準で作る
- サイトはChromeで最もよく動作する
- 他ブラウザでバグに遭遇したユーザーは、サイトではなくブラウザを責める
- ユーザーはChromeへ移り、Chromeの支配力はさらに強まる
- Chromeが別個のquirksファイルをほとんど必要としないのは、Chromeの設計が優れているからというより、WebがすでにChrome向けに最適化されているためである
- Chromium系ブラウザの利用者が80%を超える状況では、開発者はまずChromeを対象にする
- サイトがChromeで動けばそのまま公開され、SafariやFirefoxで壊れていても、その問題の優先度は低くなりやすい
- Chromeは例外を追加するよりも、議題を設定している
- Chromeがある挙動を変えると、サイトはそれに合わせて更新され、他ブラウザは追随するか壊れるかになる
仕様と実際のWebのギャップ
- ブラウザエンジニアは、現在の仕様は十分に定義されており、HTML5の「living specification」アプローチがIE/Netscape時代の混乱を減らしたと考えている
- 問題は、開発者が仕様にない実装の詳細に依存し、その詳細が他ブラウザで異なると、非準拠なのはブラウザ側だと見なしてしまう点にある
- Chromeの実装が皆の対象とする基準になると、Chromeの仕様外の細かな挙動が事実上の仕様になってしまう
- 2000年代のInternet Explorer時代にも、開発者がIE向けにサイトを作ったことで他ブラウザでは壊れ、標準準拠より「IEで動くこと」が優先された
- かつてはWebが標準をより守るようになればブラウザのquirksは消えると期待されていたが、実際にはquirksが消えたのではなく、Chrome以外のブラウザへ移っただけだった
- 標準はブラウザごとのコードをなくすために存在したが、IE時代を抜けた後、別のブラウザを中心に同じ穴が再び作られてしまった
- いまやブラウザ別コードは支配的ブラウザの中ではなく、支配的ブラウザに合わせて作られたWebを補正する非支配的ブラウザの中に入っている
例外処理は思ったより深い
- こうした処理は単なる視覚的調整にとどまらず、ドメインに応じてブラウザの基本動作そのものを変えている
- WebKitの一覧だけでも数千行に及び、スクロール動作、タッチイベント処理、ビューポート計算、画像MIMEタイプ処理まで含まれている
- Amazonの商品画像ズーム機能に関するコメントには、次のような記述がある
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- SafariはAmazonにアクセスしているかを確認した上で、商品ズーム機能のためにタッチイベントをマウスイベントへ変換する方法を変更している
- AmazonのサイトがSafariの基本動作とは異なる特定のイベント挙動を前提にしているため、SafariはAmazonに対してのみその挙動を提供している
- storage access、スクロールバーのレンダリング、自動補正動作、ズーム処理にもドメイン別quirksがある
- 各例外はドメイン判定の背後にあり、ブラウザ実行ファイルの中にコンパイルされている
待つよりブラウザが直接直す理由
- ブラウザベンダーが問題のあるサイトに連絡し、修正を依頼する場合もあり、ソースコードにはoutreachの取り組みへリンクした項目もある
- しかし人気サイトがChromeでは動き、自社ブラウザでは壊れる場合、ユーザーはサイトではなくブラウザを責める
- サードパーティにバグを報告して数週間から数か月待つより、翌日に5行の回避策を配布するほうが、ブラウザ側にとっては実用的である
- そもそも誰に連絡すべきかも明確でないことがある
- 壊れたコードを書いた開発者がすでに会社を去っているかもしれない
- そのエンドポイントを所有するチームが責任を認識していないかもしれない
- サイトがセキュリティパッチだけを受ける保守モードに入っているかもしれない
- ブラウザ側から見れば、即座に、見えない形で修正してユーザーの問題を減らす選択は単純である
- WebKitエンジニアによるFlightAwareのquirk削除プロセスを扱った記事もある
- FlightAwareはCSS transform matrix文字列を比較しており、CSS仕様が値のシリアライズ方法を変更した結果、ブラウザが仕様に従ったことでサイトが壊れた
- エンジニアたちは
flightaware.comを判定するドメイン別コードを追加し、その後連絡が成功してFlightAware側がコードを修正したため、quirkは削除された
- その数か月の間、Safariユーザーはブラウザ内の
if文のおかげで正常な体験を得られていた
開発者が確認すべきこと
- Webサイトが知らないうちに特別なレンダリング処理を受けている可能性がある
- こうしたquirkはエラーログに現れず、コンソールにも「ブラウザがミスを回避中です」という警告は出ない
- 回避処理は意図的に見えない形で動作する
- Chrome中心でテストしているサイトは特に危険である
- サイトが完璧に動いている理由は良いコードだからではなく、Chromeの挙動が開発者の前提と一致しているだけかもしれない
- 他ブラウザは、サイトを壊れたままユーザーに見せるか、quirksファイルに追加するかを選ばなければならない状況になる
- FirefoxとSafariでは、たまにではなく定期的にサイトを開いて確認すべきである
- quirksファイルは、開発者が定期的にそうしてこなかったからこそ存在している
- 自分のドメインがquirksファイルに含まれているなら、ブラウザが回避処理した箇所を点検する必要がある
- Webは開発者の介入がなくても動き続けてきたが、使っていないブラウザのエンジニアが、開発者の知らない問題を代わりに解決していた可能性がある
1件のコメント
Lobste.rsの反応
LLMっぽい駄文の奥に、興味深い話が隠れている
文体が気に入らないことはあるだろうし、その点を無理に議論したいわけではないが、文章がひどいからといって必ずしもAIが書いたことを意味するわけではない。AI以前からひどい文章はいくらでもあった
残念な話だし、Googleがここまでウェブを左右しない世界に生きたかった。「ウェブ」という夢はもっとずっと野心的で、個人的には人を鼓舞するものだったのに、今の姿になってしまったのが惜しい
引用ブロックが読みにくい。たぶんダークモードの問題かもしれない
回避策の細部を共有してくれたのは有用だった
「これらのサイトはChromeかどうかを検出して、他のブラウザには劣化した体験を提供する。だからSafariユーザーを苦しませる代わりに、WebKitは自分がどのブラウザかについて嘘をつく」という部分は、この業界全体で繰り返されていることのように見える
コンピュータメーカーも、サポートしていないOSには情報を隠すACPIファームウェアを出すことが珍しくなく、その結果それらのOSはWindowsのふりをしてファームウェアをだますことになる
この記事がAI文体っぽく読めるのが気に入らない
ここで挙げられているもの以外にも、2つのフィードバックループがある。1つはChromeが支配的なので開発者がChrome基準で作り、結果としてChromeで最もうまく動き、他のブラウザで問題が起きるとユーザーはサイトではなくブラウザのせいだと考えてChromeへ移る、というループだ
もう1つは、サイトがFirefoxで壊れているのに、サイト運営者が統計上Firefoxユーザーが見当たらないと言うループだ。ユーザーエージェントを変えるような特別扱いがあっても、こうしたことは起こりうる
記憶では、古いOpera(Presto) がこうした互換性レイヤーを最初に実装し始めた
実装がそのまま仕様になってしまうのは、この分野に広くある問題だ。以前の職場では、複数の実装が生まれ、ワークフローが移植可能になることを期待して、適合性テスト付きのワークフロー言語を使っていた
核心的な問題は、完全な移植性を実現する経済的インセンティブが低いことにある。自分たちの実装に追加機能を入れて、人々をその製品に留めておきたくなる
また、委員会方式でソフトウェアを作っている時間はないので、新機能を先に実装して入れたくもなる
実装が仕様になるのは、私たちが人間社会に生きているからだ
新しい話ではない。少数派ブラウザは常に特定サイト向けのハックを抱えていたし、昔はその相手がIEだった。代替案は、サイトが壊れたまま残ることだけだった
何十年も前、ウェブ開発者はIEでしか動かないサイトを作り、「このサイトを使いたければIEを使え」と言っていた。そして今、同じことがChromeで繰り返されている。Chromeが正しいか間違っているかは重要ではない。サイトがChromeでしか動かず、他のブラウザがそのサイトでChromeの挙動を保証しなければ、人々は「このブラウザは壊れている」と言ってChromeへ移る
本当に気になるのは、人々がGeckoとWebKitは原則のためにこうしたサイトを壊れたまま放置すべきだと考えているのか、それとも全員がChromeだけを使い他のブラウザを使うべきではないと考えているのか、ということだ。特定サイト向けハックの代替案は、その2つしかない
FirefoxとSafariがユーザーエージェントでChromeのふりをするのは滑稽だと思う
とはいえ、Chromeのユーザーエージェント文字列には、Mozillaブラウザのふりをし、Appleブラウザのふりをしていた化石のような痕跡が残っている
この1行のコードには地質学的な地層が積み重なっている: