ゲーム開発に活用した技術の裏側

2023 年 11 月に Chrome の Manifest V2 拡張機能の段階的廃止についてスケジュールをお知らせしました。コミュニティの進捗状況とフィードバックに基づき、この変更を予定どおりにロールアウトいたします。

Manifest V3 の目標は常に明確で、既存の機能を保護することと、拡張機能エコシステム全体のセキュリティ、プライバシー、パフォーマンス、信頼性を向上させることです。コミュニティの皆さんの協力とフィードバックに感謝いたします。おかげさまで、拡張機能プラットフォームを改善し続けることができています。

コミュニティからのフィードバックへの対応

このような規模の移行には困難が伴う場合があることは理解しています。そのため、デベロッパーからのフィードバックに耳を傾け、何年にもわたって Manifest V3 を改善して、拡張機能コミュニティ全体で起こっているイノベーションをサポートできるようにしてきました。たとえば、ユーザー スクリプトのサポートを追加し、オフスクリーン ドキュメントを導入して拡張機能がバックグラウンド コンテキストから DOM API を使えるようにしました。拡張機能コミュニティからのフィードバックに基づき、declarativeNetRequest のルールセット数も増やしました。これにより、最大 330,000 個の静的ルールを拡張機能にバンドルし、さらに 30,000 個を動的に追加できるようになっています。

今月には、安全なルール更新の審査スキップが始まり、declarativeNetRequest を使う拡張機能の移行がさらに簡単になっています。拡張機能の declarativeNetRequest の静的ルールリストを安全に変更する場合に限り、アップデートは数分で承認されます。先月のバージョン ロールバック機能のリリースと同じく、デベロッパーがアップデートの展開方法を細かく制御できるようになります。

エコシステムの進捗状況

私たちは昨年、移行を妨げる主な問題と不足していた機能に対処しました。その後、Manifest V3 への移行を終える拡張機能の数が増加しています。この 1 年間では、Adblock Plus のメーカーである Eyeo や、Matt Frisbie 氏のような GDE メンバーなど、一部のデベロッパーをお招きし、その経験や知見をゲスト投稿や YouTube 動画を通じてコミュニティと共有することもできました。

現在、Chrome ウェブストアで活発にメンテナンスが行われている拡張機能の 85% 以上が Manifest V3 で動作しています。上位にランキングしているコンテンツ フィルタリング拡張機能にはすべて Manifest V3 バージョンがあり、AdBlock、Adblock Plus、uBlock Origin、AdGuard のユーザーに選択肢を提供しています。

今後に向けて

6 月 3 日以降、Chrome ベータ版、Dev 版、Canary 版チャンネルでは、拡張機能管理ページ（chrome://extensions）にアクセスしたタイミングで、Manifest V2 拡張機能をインストールしたままのユーザーに警告バナーが表示され始めます。これにより、インストールしている拡張機能に、まもなくサポートが終了するもの（Manifest V2）があることをお知らせします。また、おすすめバッジの付いた拡張機能のうち、Manifest V2 を引き続き使っているものはバッジを失います。

その後数か月以内に、これらの拡張機能は徐々に無効になる予定です。ユーザーは Chrome ウェブストアに誘導され、無効になった拡張機能の代替となる Manifest V3 の拡張機能がユーザーに推奨されます。しばらくの間は、Manifest V2 拡張機能が無効になっても、オンに戻すことができますが、将来的にこの切り替え機能も削除されます。

ほかの大規模リリースと同じく、こういった変更はすべて、Chrome 安定版よりも先行するチャンネルのビルド（Chrome ベータ版、Dev 版、Canary 版）で始められます。この変更は、今後数か月をかけて Chrome Stable にロールアウトされます。移行は、来年初めまでに終えることを目指しています。ExtensionManifestV2Availability ポリシーを使っている企業は、ブラウザの変更期限を 2025 年 6 月まで延長できます。

このプロセスの詳細は、先日開催された Chrome 拡張機能に関する Google I/O のトークでご案内しています。ほかに不明な点がございましたら、Chromium 拡張機能のメーリング リストからお気軽にお問い合わせください。

ほとんどの場合に高速であるだけでは不十分で、いつでも高速でなければならないというのが Chrome チームの考えです。今回の「速さと好奇心」の投稿では、ウェブに関する主な指標を向上させ、最終的にウェブのパフォーマンスを改善できた方法について取り上げます。これは、あらゆるウェブサイトでのユーザー インタラクションへの応答を表す Chrome のフィールド データを調査することによって実現しました。

日々、何十億人もの人々がさまざまなことにウェブを活用しています。ブラウザは同時に多くのアプリをホストしなければならなくなり、リソースの競合が課題になっています。マルチプロセス ブラウザである Chrome では、複数のリソースが競合しています。CPU やメモリはもちろんのこと、内部サービス（この記事では、ネットワーク サービス）間の専用作業キューもあります。

このような理由のため、私たちは Chrome ユーザーのフィールド データから遅いインタラクションを特定し、修正することに重点を置いています。このフィールド データこそ、実際のユーザー エクスペリエンスを表す確かな情報源です。このデータは、Chrome Canary 版で匿名化した Perfetto トレースを記録し、プライバシー保護フィルタを使って報告することで収集しています。

遅いインタラクションのフィールド データに注目したとき、ある 1 つの原因が浮かび上がってきました。それは、ネットワーク サービスから現在のサイトの Cookie を取得するため、同期呼び出しを繰り返し行っていることです。

その経緯から振り返ることにしましょう。

進化するウェブにおける Cookie

Cookie は、その創生期のころからウェブ プラットフォームの一部であり続けています。通常は、次のようにして作成します。

    document.cookie = "user=Alice;color=blue"

すると、次のようにして取得できます。

    // Assuming a `getCookie` helper method:
    getCookie("user", document.cookie)

シングルプロセス ブラウザでは、この実装はシンプルで、Cookie の器はメモリに保持されていました。

しかし時間が経つと、ブラウザはマルチプロセスとなり、Cookie の器をホストするプロセスは、ますます多くのクエリに答えなければならなくなります。ただし、ウェブの仕様では、Cookie は Javascript から同期的に取得できなければなりません。そのため、document.cookie クエリに回答する操作はブロック操作です。

この操作自体は非常に高速なので、通常、このアプローチは問題にはなりませんでした。しかし、高負荷シナリオでは、複数のウェブサイトがネットワーク サービスから Cookie（およびその他のリソース）をリクエストしており、リクエストのキューが滞る可能性があります。

遅いインタラクションのフィールド トレースから、一部のウェブサイトで、Cookie が連続して複数回フェッチされるという非効率的なシナリオが起きていることがわかりました。そこで追加の指標を作成し、すべてのナビゲーションでの冗長な GetCookieString() IPC（前回と同じ値が返されたもの）の頻度を測定しました。その結果、Cookie アクセスの 87% が冗長で、それが毎秒数百回発生している場合もあることがわかりました。これは驚愕の事実でした。

つまり、document.cookie のシンプルなデザインが裏目に出たということです。ウェブの JavaScript では、これをローカル値のように扱っていましたが、実際にはリモート検索が行われていました。これは、古典的なコンピュータ サイエンスのキャッシュを行えばよいケースでしょうか？！早まってはいけません！

ウェブの仕様では、協調ドメインが相互に Cookie を変更し合えることになっています。したがって、レンダラ プロセスごとの単純なキャッシュでは、うまくいきません。そのようなサイト間で書き込みが伝播されないからです（古い Cookie が残り、e コマース アプリケーションでカートが同期されなくなるなどの現象が発生します）。

新たなパラダイム : 共有メモリのバージョニング

これを解決したのが、私たちが共有メモリのバージョニングと呼ぶ新たなパラダイムでした。すなわち、document.cookie のそれぞれの値と、単調に増加するバージョン番号を組み合わせるという考え方です。各レンダラは、最後に読み取った document.cookie を、バージョン番号とともにキャッシュします。ネットワーク サービスは、そのバージョンのそれぞれの document.cookie を共有メモリにホストします。このようにすると、レンダラはネットワーク サービスにプロセス間クエリを送信しなくても、最新バージョンを保持しているかどうかがわかります。

この結果、Cookie 関連のプロセス間メッセージが 80% 削減され、document.cookie へのアクセスが 60% 速くなりました 🥳。

仮説の検証

アルゴリズムを改善するのは良いことですが、私たちが最終的に重視しているのは、改善によって遅いユーザー インタラクションが速くなったかどうかです。つまり、遅い Cookie クエリが遅いインタラクションの主要な原因であるという仮説を検証する必要があります。

これを実現するため、Chrome の A/B テスト フレームワークを使って効果を調査しました。その結果、すべてのプラットフォームで、他の改善によるリソースの競合の減少と合わせて、最も遅いインタラクションを約 5% 改善できたことがわかりました。そして、ウェブに関する主な指標を満たすサイトがさらに増加しています 🥳。こうしたすべてのことにより、ユーザーがさらにシームレスだと感じられるウェブが実現します。

Chrome におけるウェブで最も遅いインタラクションの加重平均のタイムライン。本機能が 1%（11 月）のユーザー、50%（12 月）のユーザー、すべてのユーザー（2 月）にリリースされるにあたっての状況。

Posted by Eiji Kitamura - Developer Relations Team

新たなウェブ標準である Reporting API は、本番ウェブサイトにアクセスするブラウザで発生する問題をレポートする汎用的な仕組みを提供します。受け取るレポートでは、世界中のユーザーのブラウザで発生するセキュリティ違反やまもなく非推奨になる API などの問題が詳しく説明されています。

多くの場合は、HTTP ヘッダーでエンドポイント URL を指定するだけでレポートを収集できます。するとブラウザは、皆さんにとって関心のある問題が含まれたレポートをエンドポイントに自動転送し始めます。ただし、レポートの処理や分析はそれほど簡単ではありません。たとえば、エンドポイントには大量のレポートが送られてくる可能性がありますが、そのすべてが根本的な問題の特定に役立つわけではない場合があります。そのような状況では、問題を抽出して修正するのは非常に困難かもしれません。

このブログ投稿では、Google セキュリティ チームがどのように Reporting API を使って潜在的な問題を検出し、実際の問題を特定しているかを紹介します。また、Google と同じようなアプローチで簡単にレポートの処理や対策ができるように、オープンソースのソリューションも紹介します。

Reporting API の仕組み

本番環境のユーザーのブラウザでしか発生しないエラーもあります。もちろん、皆さんはユーザーのブラウザにアクセスすることはできません。こういったエラーは、ローカルで、あるいは開発中に見かけることはありません。実際のユーザーやネットワーク、デバイスがどのような状態になっているかわからないからです。Reporting API を使えば、ブラウザを直接利用してこういったエラーをモニタリングできます。つまり、ブラウザがエラーをキャッチし、エラーレポートを生成して、指定したエンドポイントに送信してくれます。

レポートの生成と送信の仕組み。

Reporting API でモニタリングできるエラーには、次のようなものがあります。

• セキュリティ違反 : Content-Security-Policy（CSP）、Cross-Origin-Opener-Policy（COOP）、Cross-Origin-Embedder-Policy（COEP）
• 非推奨とまもなく非推奨になる API の呼び出し
• ブラウザの介入
• 権限ポリシー
• その他の役割

# CSP 違反レポート、Document-Policy 違反レポート、非推奨レポートを受け取る設定の例
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
# CSP 違反と Document-Policy 違反を `main-endpoint` に送信する
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# 非推奨レポートは自動生成され、明示的なエンドポイントは必要ない。常に `default` エンドポイントに送信される

DevTools の [Application] パネルに表示されるレポートの例。

レポートのエンドポイントのデモでは、生成されたさまざまな違反がサーバーでどのように受信されるかを確認できます。

違反レポートの例

2024 年 3 月時点で、Chrome は Reporting API をサポートしており、Safari は一部をサポートしています。詳細については、ブラウザ サポートの表をご覧ください。

Google のアプローチ

Google は、セキュリティを大規模に向上できるという恩恵を受けています。Content Security Policy、Trusted Types、Fetch Metadata、Cross-Origin Opener Policy といったウェブ プラットフォームによる対策は、さまざまな Google プロダクトや無数の個々のサービスからあらゆる脆弱性を排除するために役立ちます。この点は、こちらのブログ投稿で詳しく説明しています。

1. ポリシーを report-only モード でロールアウトします（CSP report-only モードの例）。こうすると、ブラウザはクライアント側のコードを通常どおり実行するよう指示しつつ、ポリシーが適用された場合に違反となるイベントの情報を収集します。この情報は、レポートのエンドポイントに送信される違反レポートに集約されます。
2. 違反レポートをトリアージし、ポリシーに準拠していないコードの場所にリンクします。たとえば、危険な API を使っていたり、ユーザーデータとコードが混在するパターンを使っていたりするため、セキュリティ ポリシーに準拠していないコードベースがあるかもしれません。
3. 特定したコードをリファクタリングして準拠させます。たとえば、危険な API を安全なバージョンに置き換えたり、ユーザー入力をコードと混在させないようにしたりします。こうしたリファクタリングにより、危険なコーディング パターンが減り、コードベースのセキュリティ態勢が向上します。
4. すべてのコードを特定し、リファクタリングが終わった段階で、report-only モード からポリシーを削除し、完全に適用します。通常のロールアウトでは、手順 1～3 を繰り返し、すべての違反レポートを確実にトリアージします。

Reporting API では、1 つのレポート エンドポイントと、複数のセキュリティ機能を表現する 1 つのスキーマを使ってこのサイクルを実行できます。そのため、ブラウザ、コードパス、ユーザータイプを問わずに、さまざまな機能のレポートを一元的に収集できます。

注 : ポリシーで禁止されているアクションを行おうとすると、違反レポートが生成されます。たとえば、あるページに CSP を設定しているにもかかわらず、CSP で許可されていないスクリプトを読み込もうとする場合です。Reporting API で生成されるレポートのほとんどは違反レポートですが、それがすべてではありません。その他のタイプには、非推奨レポートやクラッシュ レポートなどがあります。詳細については、ユースケースとレポートタイプをご覧ください。

残念ながら、違反レポートのストリームにはノイズが紛れ込むことがよくあります。その場合、準拠していないコードを見つけることが難しくなる可能性があります。たとえば、多くのブラウザ拡張機能、マルウェア、ウィルス対策ソフトウェア、開発ツールのユーザーは、DOM にサードパーティのコードを挿入したり、禁止された API を使ったりしています。挿入されるコードがポリシーに準拠していない場合、コードベースにリンクされていない対策不可能な違反レポートになる可能性があります。そのため、レポートのトリアージが困難になり、すべてのコードを確実に準拠させてから新しいポリシーを適用するのが難しくなります。

Google は長年にわたり、違反レポートを収集して活用し、それをまとめて 根本原因に集約するための多くの技術を開発してきました ここでは、デベロッパーが違反レポートのノイズを除外できる技術の中から、特に役立つ技術の概要を紹介します。

根本原因に注目する

ブラウザのタブが使われている間に、ポリシーに準拠していないコードが何度も実行されることはよくあります。それが発生するたびに、新しい違反レポートが作成され、キューイングされて、レポートのエンドポイントに送信されます。これが起きると、冗長な情報を含む大量のレポートができてしまいます。そこで、違反レポートをクラスタにグループ化することで、個々の違反を意識することなく、根本原因について考えることができます。根本原因の方が理解しやすいので、有効なリファクタリング方法を探す時間を短縮できます。

例を通して、違反がどのようにグループ化されるのかを確認してみましょう。たとえば、インライン JavaScript イベント ハンドラの使用を禁止する report-only の CSP が導入されているとします。違反レポートは、該当するハンドラのすべてのインスタンスについて作成され、次のフィールドが設定されます。

• blockedURL フィールドには、inline が設定されます。これは違反の種類を表します。
• scriptSample フィールドには、フィールド内のイベント ハンドラの内容の最初の数バイトが設定されます。
• documentURL フィールドには、現在のブラウザタブの URL が設定されます。

ほとんどの場合、この 3 つのフィールドで、特定の URL のインライン ハンドラを一意に識別できます。他のフィールドの値が異なる場合でも同様です。こういったことがよく起こるのは、トークンやタイムスタンプなどのランダムな値をページをまたいで使う場合です。前述のようなフィールドの値は、アプリケーションやフレームワークによって微妙に異なる場合があるため、レポート値をあいまい一致させることができれば、手間を省きつつ、違反をクラスタにグループ化して対策につなげることができます。必要に応じて、URL フィールドに既知のプレフィックスがある違反をグループ化することができます。たとえば、URL が chrome-extension、moz-extension、safari-extension で始まるすべての違反をグループ化すると、根本原因がコードベース以外のブラウザ拡張機能である違反を、高い信頼性で特定できます。

環境情報を活用する

対策不可能な違反レポートと対策可能な違反レポートを区別するもう 1 つの方法が、環境情報です。このデータは、レポートのエンドポイントへのリクエストには含まれますが、違反レポート自体には含まれません。環境情報からクライアント設定におけるノイズ源を判別できる可能性があるので、トリアージに役立つかもしれません。

• ユーザー エージェントまたはユーザー エージェント クライアント ヒント : ユーザー エージェントは、対策不可能な違反の大きな兆候です。たとえば、クローラ、ボット、一部のモバイルアプリなどは、サポート対象のブラウザ エンジンとは動作が異なり、カスタムのユーザー エージェントを使っているので、他では起きない違反が発生する可能性があります。それ以外にも、特定のブラウザでのみ発生する違反や、ナイトリー ビルドによる変更や新バージョンのブラウザによって発生する違反もあります。ユーザー エージェント情報がなければ、こういった違反を調査することは非常に困難になります。

• 信頼できるユーザー : エンドポイントが違反の発生したドキュメントと same-site である場合、Reporting API がレポート エンドポイントに対して行うリクエストに利用可能な Cookie が添付されます。Cookie を取得すると、違反が起きたユーザーの種類を特定する際に役立ちます。対策すべき違反の多くは、会社の従業員やウェブサイト管理者など、信頼できるユーザーによるものであり、これらのユーザーが侵略的な拡張機能をインストールしたり、マルウェアに感染していたりすることはないでしょう。レポート エンドポイントから認証情報を取得できない場合は、まず信頼できるユーザーを対象に report-only ポリシーを設定してみましょう。そうすることで、対策すべき違反の基準を明確にしてから、ポリシーを一般公開することができます。

• ユニーク ユーザー数 : 一般原則として、典型的な機能やコードパスのユーザーからは、ほぼ同じ違反が生成されるといえます。そのため、少数のユーザーでしか発生していない違反は除外候補とすることができます。つまり、アプリケーションのコードではなく、ユーザーの特定の設定が問題である可能性があるということです。「ユーザー数をカウントする」方法の 1 つは、違反を報告したユニーク IP アドレス数を記録することです。近似カウント アルゴリズムは使いやすく、特定の IP アドレスを追跡せずにこの情報を収集できます。たとえば、HyperLogLog アルゴリズムは、わずか数バイトで、信頼度高く、集合内のおおまかな一意の要素数を数えることができます。

違反をソースコードにマッピングする（高度な内容）

違反のタイプによっては、source_file フィールドまたはそれと同等のフィールドが含まれます。このフィールドは、違反の原因となった JavaScript ファイルを表し、通常は行番号と列番号が付いています。これらの 3 ビットデータは高品質の信号であり、リファクタリングが必要なコードの行を直接指すことができます。

ただし、コンパイルや最小化のために、ブラウザがフェッチしたソースファイルがコードベースに直接マッピングできなくなることもよくあります。その場合は、JavaScript ソースマップを使って、デプロイされたファイルとオーサリングされたファイルの間で行番号と列番号をマッピングするとよいでしょう。すると、違反レポートがソースコードの行に直接変換されるので、非常に対策しやすいレポート グループと根本原因が生成されます。

独自のソリューションを確立する

Reporting API は、セキュリティ違反、非推奨の API 呼び出し、ブラウザの介入などのブラウザ側イベントを、イベントごとに指定されたエンドポイントに送信します。ただし、前のセクションで説明したように、そのレポートから実際の問題を抽出するには、データ処理システムが必要です。

• API エンドポイント : HTTP リクエストを受け取り、JSON 形式でレポートを処理するウェブサーバー
• ストレージ : 受け取ったレポートやパイプラインで処理したレポートを格納するストレージ サーバー
• データ パイプライン : ノイズを除去し、必要なメタデータを抽出して集約するパイプライン
• データ視覚化ツール : 処理したレポートから知見を得るためのツール

サンプル アプリケーション : Reporting API プロセッサ

ブラウザからレポートを受け取る方法と、受け取ったレポートを処理する方法を理解できるように、小さなサンプル アプリケーションを作成しました。このアプリケーションで、ブラウザが送信したレポートからウェブ アプリケーションのセキュリティ問題を抽出するために必要なプロセスを示します。具体的には、以下のプロセスになります。

• レポートのストレージへの保存

• ノイズ リダクションとデータ集約

• 処理済みのレポートデータの可視化

緑色のボックスは、独自に実装する必要があるコンポーネントです。 フォワーダ（forwarder） はシンプルなウェブサーバーであり、JSON 形式のレポートを受け取り、それを Bigtable 用のスキーマに変換します。 ビームコレクタ（beam-collector） はシンプルな Apache Beam パイプラインであり、ノイズの多いレポートをフィルタリングし、関連するレポートを集約して、CSV ファイルとして保存します。この 2 つのコンポーネントは、Reporting API からのレポートを有効利用するうえで重要な役割を果たしています。

実際に試す

代替ソリューション

ここで共有したオープンソース ソリューション以外にも、Reporting API を簡単に使えるようにするツールがいくつも用意されています。次のようなものがあります。

• report-uri や uriports などのレポート収集サービス

• Sentry や Datadog などのアプリケーション エラー モニタリング プラットフォーム

• アプリケーションの URL をサードパーティのレポート収集ツールに渡しても構わないでしょうか？ブラウザが URL から機密情報を取り除いたとしても、機密情報はこのように漏洩する可能性があります。アプリケーションにとってリスクが高すぎると思われる場合は、独自のレポート エンドポイントを運用してください。

• 収集ツールは、必要なすべてのレポートタイプをサポートしていますか？たとえば、すべてのレポート エンドポイント ソリューションが COOP/COEP 違反レポートをサポートしているわけではありません。

まとめ

この記事では、ウェブ デベロッパーが Reporting API を使ってクライアント側の問題を収集する方法と、収集したレポートから実際の問題を抽出する際の課題について説明しました。また、その課題を解決するために Google がどのようにレポートをフィルタリングして処理しているかを説明し、同様のソリューションを実現する際に利用できるオープンソース プロジェクトを紹介しました。この情報が役立ち、Reporting API を活用するデベロッパーが増え、結果としてウェブサイトの安全性と持続可能性が向上することを願っています。

学習リソース

• Reporting API を使用してウェブ アプリケーションをモニタリングする | 機能 | デベロッパー向け Chrome

• セキュリティ拡張のためのレシピ – Google Bug Hunters