使ってみるには

この変更はブラウザレベルで行われるので、Chrome のカスタムタブを使用するデベロッパーは、Chrome バージョン M124 以降に自動的に適用された変更を確認することができます。エンドユーザーから見ると、Chrome カスタムタブ ツールバーに最小化アイコンが表示されます。

これは Chrome で行われる変更ですが、ほかのブラウザにも同様の機能が採用されることを願っています。



ほとんどの場合に高速であるだけでは不十分で、いつでも高速でなければならないというのが 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 でモニタリングできるエラーには、次のようなものがあります。

モニタリングできるすべてのエラータイプについては、ユースケースとレポートタイプをご覧ください。

Reporting API は、HTTP レスポンス ヘッダーで有効化と設定を行います。つまり、ブラウザがレポートを送信するエンドポイントと、モニタリングするエラータイプを HTTP レスポンス ヘッダーで宣言します。ブラウザは、レポートのリストをペイロードとする POST リクエストによって、レポートをエンドポイントに送信します。

設定の例 :

# 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` エンドポイントに送信される

注 : "report-only" モードをサポートするポリシーもあります。このポリシーでは、レポートは送信されますが、実際の制限は適用されません。これは、ポリシーが効果的に機能しているかどうかを判断する際に役立ちます。

Chrome ユーザーは、DevTools の [Application] パネルから、ブラウザが生成するレポートを確認できます。

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

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

違反レポートの例

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


Google のアプローチ

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


セキュリティ ポリシーを大規模に導入する場合、エンジニアリング上の課題の 1 つとなるのが、新しい制限に準拠しておらず、制限が適用された場合に動作しなくなるコードを特定することです。この問題を解決するためによく使われる 4 つのステップがあります。
  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 は長年にわたり、違反レポートを収集して活用し、それをまとめて 根本原因に集約するための多くの技術を開発してきました ここでは、デベロッパーが違反レポートのノイズを除外できる技術の中から、特に役立つ技術の概要を紹介します。


See More

根本原因に注目する

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

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

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

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

独自のグループ化戦略を策定すれば、トリアージが必要な違反報告の数を大幅に減らし、根本原因に注目することができます。通常は、関心のある種類の違反を一意に識別するフィールドを選び、そのフィールドを使って、特に重要な根本原因に優先順位をつけられるようにする必要があります。

 

環境情報を活用する

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


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

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

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

 

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

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


幸いなことに、さまざまな方法で必要なアーキテクチャを設定できるようになっており、オープンソースのプロダクトもあります。必要なシステムの基本的な要素は次のとおりです。

以上の各コンポーネントのソリューションは、パブリック クラウド プラットフォーム、SaaS サービス、オープンソース ソフトウェアとして利用できます。詳細については、代替ソリューションのセクションをご覧ください。また、次のセクションでは、サンプル アプリケーションの概要を説明します。

 

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

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

このサンプルでは、Google Cloud を使っていますが、各コンポーネントはお好みのテクノロジーに置き換えることができます。サンプル アプリケーションの概要を次の図に示します。



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


実際に試す

これは実際に実行できるサンプル アプリケーションなので、すべてのコンポーネントを Google Cloud プロジェクトにデプロイし、自分で仕組みを確認することができます。サンプル システムを設定するための詳細な前提条件と手順は、README.md ファイルに記載されています。

 

代替ソリューション

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


代替案を選択する際は、価格だけでなく、次の点を考慮するようにしましょう。

まとめ

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


学習リソース



Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook


日本時間 8 月 1 日（木）、2 日（金）に、旗艦イベント Google Cloud Next Tokyo '24 を開催します。待望のセッション情報が公開されました！

☁︎ 基調講演

生成 AI に関する革新的な取り組みを行う企業の取り組みや、Google Cloud の最新ソリューションをお届けします。DAY1 は、LINEヤフー、星野リゾートなどいち早く生成 AI を活用されている企業が登壇し、ビジネス変革のヒントをお届けします。DAY2 は、開発者目線で Google Cloud が提供する生成 AI のコンセプトや、日本テレビ、ヤマト運輸、トヨタ自動車、三井住友フィナンシャルグループなど、業界をリードする企業がいかに Google Cloud を活用しているか、語ります。

☁︎ おすすめセッション

以下に、一部ご紹介します。当日のライブ配信がないこと、また席数に限りがあるので、気になるものがあれば、イベント登録をした後に、早めにセッション登録いただきますよう、お願いします。


【AI と機械学習】生成 AI Innovation Awards 最優秀賞！AI と人を共進化に導く学習業務活用支援

ソフトバンク Axross の学習の業務定着化支援機能での Vertex AI など Google Cloud をフル活用したアーキテクチャを紹介します。新機能である協働ノートでの学び、意見を Vertex AI 支援で発散 / 収束させ、組織独自のノウハウ ドキュメント化を促進、知識 / スキルを可視化 / 数値化します。それらデータ活用で人に合わせて支援 AI 自体が進化、AI と人が協調的に進化する AI 時代最適なプラットフォームの提案です。


【アプリケーション開発】サーバレスでモバイルアプリ開発！ NTTコム「ビジネスdアプリ」のアーキテクチャ

NTTコミュニケーションズが中小企業向けに開発したモバイルアプリ「ビジネスdアプリ」は社員内製によって開発しています。Google Cloud のサーバレス サービスを徹底的に活用することによって、開発チームはプログラム開発に集中でき、短期間で開発をすることができました。本セッションでは Google Cloud のサーバレス サービスの活用のコツと注意点を解説します。


【インフラストラクチャ】同時接続数 185 万人を支えたパルワールドのインフラ最前線

発売 1 か月で総プレイヤー数 2500 万人を記録したパルワールド。大ヒットの裏側で起きた数々のエピソードや危機的事態を乗り切ったノウハウについて紹介します。


【データ分析】楽天グループの大規模データ分析ツール「Rakuten Analytics」における BigQuery 活用

「Rakuten Analytics」は、楽天グループの膨大なアクセスログを集約し、アナリストやデータ サイエンティストがデータのポテンシャルを最大限に引き出せるように設計された分析プラットフォームです。BigQuery を活用することによってパフォーマンスが大きく改善され、社内のデータドリブンな文化の実現に大きく前進したストーリーについて解説します。


【生産性とコラボレーション】Gemini for Google Workspace 最新アップデート

進化し続ける Gemini for Google Workspace の最新アップデート情報をお届けいたします。業務部門において、どのように利用されているのか？導入におけるメリット、最新機能をご紹介いたします。


開催概要

名称 : Google Cloud Next Tokyo '24（略称 Next Tokyo '24）

日時 : 日本時間 2024 年 8 月 1 日（木） ~ 2 日（金）

会場 : パシフィコ横浜 ノース

対象 : 開発者から CEO まで、クラウド テクノロジーを使ったビジネス課題の解決を探求する、すべての方


- お問い合わせ - 

Google Cloud Next Tokyo 運営事務局

E-mail: [email protected]



Share on Twitter Share on Facebook