SharedArrayBufferがついにブラウザで再び動作するようになりましたが、それはページがクロスオリジン分離（cross-origin isolated）されている場合に限られます。この状態を実現するには2つのレスポンスヘッダーが必要です。これらのヘッダーを追加したことで、サイト上のすべてのサードパーティースクリプトを削除せざるを得なくなり、フロントエンド全体の構築方法とデータ漏洩のあり方が一変しました。
なぜヘッダーが重要なのか
SharedArrayBufferはJavaScriptにおける真のマルチスレッドを可能にし、これはタブ内でffmpegを実行するための前提条件となります。現代のブラウザはSpectre型の緩和策の後にこの機能を再有効化しましたが、それをクロスオリジン分離と紐付けました。その分離を実現するには、サーバーは以下を送信する必要があります：
Cross-Origin-Opener-Policy: same-originCross-Origin-Embedder-Policy: require-corp
2つ目のヘッダーである require-corp は、外部リソースが Cross-Origin-Resource-Policy ヘッダーを持っているか、CORS（Cross-Origin Resource Sharing）を用いて取得される必要があることをブラウザに伝えます。ほとんどのサードパーティサービスはこれらのヘッダーを設定していないため、それらのスクリプト、フォント、iframeは完全にブロックされてしまいます。
分離を有効にしたときに失われたもの
ヘッダーを適用した瞬間、連鎖的な失敗が発生しました：
- アナリティクス – ほとんどのプロバイダーは、no-CORSリクエストを行う単純な
<script>でトラッキングコードを読み込みます。CORPヘッダーがないとリクエストが拒否されるため、トラッカーは一切動作しません。 - Google Fonts – スタイルシートがCORSなしで
fonts.googleapis.comから取得されます。ブラウザはこれを破棄するため、ページからカスタムタイポグラフィが失われます。 - 埋め込みメディア – YouTubeのiframeやウィジェットスクリプトにはCORPがないため、レンダリングが停止します。
- OAuthポップアップ – 厳格なsame-originポリシーによって
window.openerの関係が断たれ、通常のポップアップベースのログインフローが壊れてしまいます。
要するに、そのドメインが新しいヘッダーの仕組みを採用しない限り、サードパーティードメインに依存するあらゆるアセットが消滅してしまったのです。
中間業者なしでの再構築
壊れたサイトに直面し、私はセルフホストされたアセットを中心にフロントエンドスタックを書き換えました：
- フォントと画像 は現在、自身のオリジンから配信されており、外部スタイルシートの必要性を排除しています。
- データAPI は、自身で制御するプライベートなバックエンド上に構築されているため、すべてのリクエストが自身のドメイン内に留まります。
- アナリティクス は、
POSTイベントを受け取り、プライベートなバケットに保存する小さなCloudflare Workerへと変更しました。クライアント側はわずか十数行のfetchコードだけです。 - Sentryなどのエラー報告およびセッションリプレイ ツールは完全に廃止しました。クラッシュはすべて自身のエンドポイントにログとして記録されます。
もし外部リソースがどうしても必要な場合は、自身が所有するサーバーを経由してプロキシし、ブラウザがそれを見る前に必要なCORPヘッダーを追加する以外に実行可能な道はありません。
プライバシーの向上 vs 運用コスト
直接的なメリットは明確です。サイトが広告ネットワークやフォントプロバイダー、動画プラットフォームに利用データを漏洩させなくなりました。すべてのテレメトリは自身の管理下に置かれ、いつでも削除できます。これほどのレベルのプライバシーを、典型的なサードパーティースタックで実現するのは困難です。
トレードオフは、追加のメンテナンス負担です。フォントのホスティング、アナリティクスのストレージ管理、プロキシの更新維持などは、ほとんどの開発者が専門サービスにアウトソーシングするタスクです。また、このアプローチは、それらのサービスが提供する機能（例えば、リアルタイムのエラー集計や詳細なファネルの可視化など）を失うことも意味します。
反論：エコシステムは適応するか？
サードパーティのベンダーはやがて必要なヘッダーを追加し、クロスオリジン分離の導入が苦痛のないものになると主張する人もいます。すでにいくつかのアドオンは対応していますが、広く利用されているサービスの大部分はまだ対応していません。エコシステムが追いつくまでは、開発者はプライバシーのメリットがセルフホストに必要なエンジニアリングの労力を上回るかどうかを判断しなければなりません。
本当に分離されているか確認する方法
書き換えを始める前に、ブラウザがページを分離状態として認識しているか確認してください：
crossOriginIsolated // should be true
typeof SharedArrayBuffer // should be "function"
どちらかのチェックが失敗する場合、ヘッダーが正しく適用されておらず、SharedArrayBufferは利用できないままとなります。
開発者の次なるステップは？
より多くのウェブアプリがマルチスレッドJavaScriptによるパフォーマンス向上を求めるようになるにつれ、CORPを採用すべきだというサードパーティプロバイダーへの圧力は強まるでしょう。当面の間、SharedArrayBufferを必要とするプロジェクトは、セルフホストのアセット戦略、または軽量なプロキシレイヤーを計画しておくべきです。また、分離要件の変更についてブラウザのリリースノートを注視しておくことも不可欠です。
要点: SharedArrayBufferを利用可能にするためにクロスオリジン分離を有効にすることは、サードパーティスクリプトの利便性を維持するか、より厳格で自己管理型のプライバシーモデルと引き換えるかという、難しい選択を迫るものです。この決定は、現代のウェブサイトの技術アーキテクチャとデータフローのフットプリントの両方を再構築することになります。