Google Ads API の 2022 年のリリースと提供終了のスケジュール

この記事は David Stevens による Google Ads Developer Blog の記事 “Google Ads API 2022 release and sunset schedule” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。計画サイクルをより明確にするために、今後のバージョンの Google Ads API について、2022 年のリリースと提供終了の暫定スケジュールをお知らせします。以下の日付は単なる想定であり、今後変更される可能性があることに…

Chrome 93: マルチスクリーン ウィンドウの配置、URL ハンドラとしての PWA など

この記事は Chromium Blog の記事 “Chrome 93: Multi-Screen Window Placement, PWAs as URL Handlers, and More” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Android WebView、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 7 月 29 日の時点で Chrome 93 はベータ版です。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Cross-Origin-Embedder-Policy: credentialless

credentialless キーワードを使って、Cookie やクライアント証明書などの認証情報を省略したクロスオリジン no-CORS リクエストが可能になりました。COEP: require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。現在は COEP: require-corp が存在し、クロスオリジン分離の有効化に利用されています。これは確実に機能しますが、すべてのサブリソースで明示的にオプトインしなければならないので、大規模な導入は難しいことがわかっています。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、一般的なソーシャル メディア、フォーラムなど）では、依存関係の問題が発生します。

マルチスクリーン ウィンドウの配置

Multi-Screen Window Placement API を使えば、マシンに接続された任意のディスプレイへのウィンドウの配置、その配置の保存、任意のディスプレイでのウィンドウの全画面表示が可能です。プレゼンテーション アプリでこの API を使うと、ある画面にスライドを、別の画面に発表者用のノートを表示できます。アートや音楽の制作アプリでは、2 つ目の画面にパレットを配置できます。また、レストランなら、座席側にタッチスクリーン メニューを、従業員側に別のウィンドウを表示できます。この API は、最初のオリジン トライアルでのデベロッパーからのフィードバックに基づいて形状や人間工学が改善され、2 回目のオリジン トライアルに入ります。

インストールされたデスクトップ版ウェブアプリ向けのウィンドウ コントロール オーバーレイ

ウィンドウ コントロール オーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロール ボタン（閉じる、最大化/復元、最小化）も含まれます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされたデスクトップ版ウェブアプリを OS のアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウ コントロール オーバーレイをカスタマイズするをご覧ください。

URL ハンドラとしての PWA

URL ハンドラとしての PWA を使うと、music.example.com のようなアプリが、自分自身を https://music.example.com、https://*.music.example.com、https://🎵.example.com といったパターンに一致する URL のハンドラとして登録できます。これにより、インスタント メッセンジャー アプリケーションやメール クライアントなどの PWA の外部からのリンクが、ブラウザのタブではなく、インストールした PWA で開くようになります。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

ウェブバンドルによるサブリソースの読み込み

ウェブバンドルは、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです。この機能は、以前のリソース バンドルへのアプローチが抱えていた問題に対処します。

一部の JavaScript バンドラの出力は、HTTP キャッシュをうまく扱うことができず、設定が難しくなる場合もあります。バンドルされた JavaScript でも、すべてのバイトがダウンロードされるまで実行を待つ必要があります。複数のサブリソースを読み込む場合、ストリーミングと並列化を使用するのが理想ですが、これは 1 つの JavaScript ファイルでは実現できません。JavaScript モジュールでは、決定的実行の関係で、リソースツリー全体がダウンロードされるのを待ってから実行する必要があります。

WebXR Plane Detection API

WebXR アプリケーションで、ユーザーの環境に存在する平面のデータを取得できるようになります。これにより、拡張現実アプリケーションでさらに臨場感の高い体験を実現できます。この機能がない場合、デベロッパーは getUserMedia()（navigator と MediaDevices で利用可能）のデータに対して独自のコンピュータ ビジョン アルゴリズムを実行してユーザーの環境に存在する平面を検知するしかありませんでした。そのため、このようなソリューションでは、ネイティブの拡張現実機能に匹敵する質や精度を実現したり、ワールド スケールをサポートしたりすることはできませんでした。

今回のリリースに追加されたその他の機能

AbortSignal.abort() 静的メソッド

静的メソッドである AbortSignal.abort() は、すでに中止された AbortSignal オブジェクトを新しく作成します。これは Promise.reject() と同じような考え方で、デベロッパーの人間工学を改善します。

ウェブ デベロッパーは、中止された AbortSignal オブジェクトをさまざまな目的に役立てることができます。これを使って、作業をしないように JavaScript API に指示します。現在、すでに中止された AbortSignal オブジェクトを作るには、複数行のコードが必要です。AbortSignal.abort() を使うと、次の 1 行で作成できます。

return AbortSignal.abort();

CSS Flexbox: alignment キーワードが start、end、self-start、self-end、left、right をサポート

flexbox と flex 項目が位置ベースの alignment キーワードに従うようになります。これまでの flexbox は、center、flex-start、flex-end のみに従っていました。追加された alignment キーワード（start、end、self-start、self-end、left、right）を使うと、flex 項目の位置をさまざまな書き込みモードや flex フローに簡単に合わせることができます。

これらの追加キーワードがない場合、書き込みモード、テキストの方向、flex の逆方向プロパティ（flex-direction: row-reverse、flex-direction:column-reverse、align-content: wrap-reverse）を変えるたびに、キーワードの値を変更する必要があります。今回実装されたキーワードを使うと、alignment を一度設定するだけで済みます。

Error.cause プロパティ

Error() コンストラクタが cause という新しいオプション プロパティをサポートし、これはプロパティとしてエラーに割り当てられます。これにより、エラーを条件でラップするという不必要で複雑な作業をすることなく、エラーをチェーンさせることができます。

meta name=theme-color が media HTML 属性を反映

meta[name="theme-color"] で meta 要素の “media” 属性が反映されます。これにより、ウェブ デベロッパーがメディア クエリに基づいてサイトのテーマカラーを調整できるようになります（ダークモードとライトモードなど）。最初に一致したものが選択されます。

HTMLMediaElement.controlsList の noplaybackrate

HTMLMediaElement.controlsList プロパティが noplaybackrate をサポートします。これにより、ブラウザが公開する再生速度のコントロールをウェブサイトで有効化または無効化できるようになります。ブラウザ ベンダーが再生速度のコントロールをメディア コントロールに追加したことで、デベロッパーはこの新しいコントロールの表示を制御する方法が得られます。新しいプロパティは、HTMLMediaElement.controlsList のサンプルの noplaybackrate で試すことができます。

Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダー

CSS ユーザー プリファレンス メディア機能の prefers-color-scheme は、ページで提供する必要がある CSS の量とページ読み込み時のユーザー エクスペリエンスに大きな影響を与える可能性があります。新しい Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダーを使うと、サイトのリクエスト時にオプションでユーザー プリファレンスを取得できるので、サーバーは適切な CSS をインラインで提供できます。そのため、一瞬だけ適切でないカラーテーマが表示されることを回避できます。

User-Agent Client-Hint API のアップデート

このバージョンの Chrome には、User-Agent Client-Hint API に 4 つの新機能と変更点が追加されています。

  • Sec-CH-UA-Bitness: ユーザー エージェントが動作するプラットフォーム アーキテクチャのビットネスに関する情報をサーバーに提供するためのリクエスト ヘッダーです。ビットネスとは、特定のシステムが評価できる基本値を構成するビットの数を表します。
  • Sec-CH-UA-Platform を低エントロピー ヒントに変更 : Sec-CH-UA-Platform は、ユーザー エージェントが動作するプラットフォームに関する情報をサーバーに提供するためのリクエスト ヘッダーです。
  • 低エントロピー ヒントを UADataValues.getHighEntropyValues() に追加 : ヒントが高エントロピーから低エントロピーに移動した場合、それに依存するコードの将来性が保証されます。
  • NavigatorUAData.toJSON() メソッドの改善 : このメソッドが便利なデータを返すようになります。

低エントロピー ヒントとは、あまり多くの情報を公開しないヒントや、他の方法で簡単に検出できるため現実的に隠蔽するのは難しい情報を提供するヒントです。Client-Hint においては、関連するオリジンがリクエストしたかどうかにかかわらず、また関連するフレームがファースト パーティかサード パーティかにかかわらず、すべてのリクエストで利用できるヒントを指します。

WebOTP API: クロスデバイスのサポート

デスクトップ向け Chrome と Android Chrome の両方が同じ Google アカウントにログインしている場合、PC でも WebOTP API がサポートされます。WebOPT API は、プログラムによってオリジン宛ての特定の形式の SMS メッセージからワンタイム コードを読み取る機能を提供するため、ログイン時のユーザーの手間を減らすことができます。これまで、この機能は SMS がサポートされるモバイル デバイスのみで利用できました。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.3 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Object.hasOwn

新しい Boolean 型のプロパティである Object.hasOwn は、使いやすい静的メソッド バージョンの Object.prototype.hasOwnProperty を提供します。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

ポート 989 と 990 のブロック

ポート 989 と 990 による HTTP、HTTPS、FTP サーバーへの接続が失敗するようになります。これらのポートは FTPS プロトコルで使われていますが、FTPS は Chrome では実装されていません。ただし、悪意のあるウェブページが FTPS サーバーに対して、綿密に作成された HTTPS リクエストを使ったクロスプロトコル攻撃を仕掛ける可能性があります。これは、ALPACA 攻撃の緩和策になります。

TLS から 3DES を削除

Chrome で、TLS_RSA_WITH_3DES_EDE_CBC_SHA 暗号スイートのサポートが削除されます。TLS_RSA_WITH_3DES_EDE_CBC_SHA は、SSL 2.0 と SSL 3.0 時代の遺物です。トランスポート レイヤー セキュリティ（TLS）での 3DES は、Sweet32 攻撃に対して脆弱です。これは CBC 暗号スイートであるため、Lucky Thirteen 攻撃に対しても脆弱です。TLS では、最初の代替案である AES 暗号スイートが 19 年ほど前に公開された RFC3268 によって定義され、その後も何度かの反復が行われています。

WebAssembly のクロスオリジン モジュール共有

エージェント クラスタが長期的にオリジンにスコープできるように、クロスオリジンでありながら同一サイト環境であるサイト間での WebAssembly モジュール共有が非推奨となります。これは WebAssembly の仕様変更に従ったもので、プラットフォームにも影響します。

Reviewed by Eiji Kitamura – Developer Relations Team
<!—->

クラウドベースのマップスタイル設定に追加された新機能によりオプションの幅が広がり、制御性、柔軟性、ユーザー エクスペリエンスが向上

この記事は Google マップ、Google Maps Platform プロダクト マネージャー Alicia Sullivan による Google Cloud Blog の記事 ” New Cloud-based maps styling features provide more options, control, and flexibility to enhance your user experience” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 今年の…

Chrome のサイト分離による保護の強化

この記事は Chrome セキュリティ チーム、Charlie Reis、Alex Moshchuk による Google Online Security Blog の記事 “Protecting more with Site Isolation” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome のサイト分離により、悪意のあるウェブサイトが他のウェブサイトからデータを盗みにくくなる、重要なセキュリティ保護機能です。サイト分離は、Windows、Mac、Linux、Chrome OS ですべてのウェブサイトを他のサイトから保護し、ウェブサイトよりも権限が高い拡張機能とプロセスが共有されないことも保証します。Chrome 92 では、この機能をさらに拡張し、拡張機能が相互にプロセスを共有できないようにする予定です。これにより、既存の拡張機能の動作を一切妨げることなく、悪意のある拡張機能に対する保護が強化されます。

一方で、現在の Android のサイト分離は、パフォーマンスのオーバーヘッドを低く保つため、高価値サイトのみを保護しています。今回は、サイト分離の 2 つの改善についてお知らせします。これにより、Android ユーザーのサイト保護の対象となるサイトが増加します。Chrome 92 以降、ユーザーがサードパーティ プロバイダ経由でログインするサイトや、Cross-Origin-Opener-Policy ヘッダーが設定されているサイトに、サイト分離が適用されます。

Android のサイト分離の継続的な目標は、リソースの制約があるデバイスで、ユーザー エクスペリエンスを低下することなくセキュリティ層を追加することです。ほとんどの Android デバイスにとって、 すべての サイトでサイト分離をすると、コストがかかりすぎる点は変わりません。そのため、保護を追加することで最もメリットを得られるサイトを優先するように経験則を改善することを戦略としています。現在のところ、Chrome はユーザーがパスワードを入力してログインするサイトを分離しています。しかし、多くのサイトが、サードパーティのサイト（たとえば、「Google でログイン」を提供するサイト）を使って、パスワードを入力しなくても認証できるようになっています。ほとんどの場合、これは業界標準の OAuth プロトコルで実現されています。Chrome 92 以降のサイト分離は、一般的な OAuth のインタラクションを認識し、OAuth ベースのログインを利用するサイトを保護します。そのため、ユーザーがどのように認証をしても、データは安全です。

さらに Chrome は、新しい Cross-Origin-Opener-Policy（COOP）レスポンス ヘッダーに基づいてサイト分離をトリガーするようになります。このヘッダーは Chrome 83 以降でサポートされ、セキュリティを考慮したウェブサイトの運営者が、特定の HTML ドキュメントで新しいブラウジング コンテキスト グループをリクエストできるようにします。これにより、信頼できないオリジンからドキュメントが切り離されるので、攻撃者はサイトのトップレベル ウィンドウを参照したり操作したりできなくなります。このヘッダーは、SharedArrayBuffer などの充実した API を使う際に必要なヘッダーの 1 つでもあります。Chrome 92 以降のサイト分離では、ドキュメントの COOP ヘッダーがデフォルト以外の値だった場合、ドキュメントのサイトに機密データが含まれる可能性があるものとして扱い、サイト分離を開始します。そのため、Android でサイト分離によって確実にサイトを保護したいサイト運営者は、サイトで COOP ヘッダーを指定することでそれを実現できます。

これまでと同様、Chrome は新しく分離されたサイトをデバイスのローカルに保存します。ユーザーが閲覧履歴などのサイトデータを削除すると、そのリストもクリアされます。また、Chrome は、COOP によって分離されるサイトに一定の制限を課し、リストを最近使われたサイトのみに集中させ、リストが大きくなりすぎるのを防ぎ、悪用されないように保護しています（COOP サイトがリストに追加される前にそのサイトでのユーザー インタラクションを必須とするなど）。今後も、この新しいサイト分離モードには、最低 RAM しきい値（現在は 2 GB）を設けます。以上の点を踏まえたサイト分離の新たな改善では、Chrome の全般的なメモリ使用量やパフォーマンスに大きな影響を与えることなく、ユーザーの機密データを扱うたくさんのサイトに保護を追加できることがデータによりわかっています。

Android のサイト分離におけるこれらの改善に伴い、Android で Spectre に対応するための V8 ランタイム対策の無効化も行うことにしました。この対策は、サイト分離よりも効果が低く、パフォーマンスのコストがかかります。デスクトップ プラットフォームでは Chrome 70 以降でこの対策は無効化されており、今回の対応によって Android もそれと同等になります。Spectre からデータを保護したいサイトでは、COOP ヘッダーを設定することを検討してください。それによってサイト分離が行われます。

Android デバイスで完全な保護を実現したいユーザーは、chrome://flags/#enable-site-per-process から手動でサイト分離をオプトインすることもできます。これにより、すべてのウェブサイトが分離されるようになりますが、メモリの消費量は増加します。

Reviewed by Eiji Kitamura – Developer Relations Team
<!—->

モダンシステムにおける検証可能な設計について

この記事はプロダクション セキュリティ チーム、Ryan Hurst による Google Online Security Blog の記事 “Verifiable design in modern systems” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ソフトウェアの設計方法や構築方法は絶え間なく進化しています。現在、私たちは、セキュリティをソフトウェアに最初から組み込むものとして考えていますが、そのソフトウェアへの信頼を最小限に抑える新たな方法も模索し続けています。それを実現する方法の 1 つは、ソフトウェアが行ったことを暗号学的な確実性をもって確認できるようにソフトウェアを設計することです。

この投稿では、この暗号学的な確実性を実現する際に役立つ、検証可能なデータ構造という考え方を紹介します。検証可能なデータ構造の既存の応用例や新しい応用例についても説明します。また、皆さん独自のアプリケーションでこの構造を活用していただくためのリソースも提供します。

 
検証可能なデータ構造とは、暗号学的な確実性によって、そこに含まれているデータが正しいという合意を効率的に形成できるデータ構造です。

最も有名なのがマークル木です。マークル木が数十年にわたって使用されているのは、多くのレコードの中にデータの特定の部分が含まれていることを効率的に検証できるからです。そのため、ほとんどのブロックチェーンの基礎としても使われています。

このような検証可能なデータ構造は新しいものではありませんが、新しい世代のデベロッパーたちがこのデータ構造によって実現できる設計を発見することにより、採用が加速されています。

 
こういった検証可能なデータ構造を使えば、動作自体に検証可能性と透明性が組み込まれた要素を利用して、新たな種類のソフトウェアを構築できます。これは型強制に対する新たな形での防御になり、既存のエコシステムや新しいエコシステムにアカウンタビリティが導入されるとともに、規制機関、消費者、パートナーに対するコンプライアンスの実証も簡単になります。

証明書の透明性は、検証可能なデータ構造の大規模な利用例の 1 つであり、ブロックチェーンを利用せずに、インターネットの中核インフラストラクチャを保護する方法です。私たちはこのパターンを使い、ウェブを破壊することなく、あらゆる人が利用する既存システムに透明性とアカウンタビリティを導入することができました。

 
残念なことに、検証可能なデータ構造とそれに関連するパターンの機能はあるものの、デベロッパーがスケーラブルな実稼働品質のシステムを設計、開発、デプロイするうえで利用できるリソースは多くありません。

このギャップに対処するため、Google が証明書の透明性の構築に使ったプラットフォームを汎用化し、他の種類の問題にも応用できるようにしました。このインフラストラクチャは、何年にもわたってこのエコシステムの一部として使われているので、よく理解されており、実稼働システムに安心してデプロイできます。
そのため、このプラットフォームは、医療、金融サービス、サプライ チェーンなどの領域のソリューションで活用されています。さらにこのパターンを応用し、Google のプロダクトやサービスの他の問題にも、透明性とアカウンタビリティの特性を適用しています。

その実現に向けて、2019 年にこのプラットフォームを使い、Go Checksum Database によって Go 言語のエコシステムにサプライ チェーンの整合性を導入しました。このシステムにより、デベロッパーは、Go のエコシステムをサポートするパッケージ管理システムが、意図的、恣意的、偶発的に誤ったコードを公開しても、それが見逃されることはないという確証を得ることができます。Go ビルドの再現性によって、ソース リポジトリにあるものがパッケージ管理システムにあるものと一致するという保証を得られるので、これは特に有力です。このソリューションは、ソース リポジトリからコンパイルされた最終アーティファクトまで、一貫して検証可能なチェーンを提供します。

このパターンのもう 1 つの活用例が、最近発表された Sigstore という Linux Foundation とのパートナーシップです。このプロジェクトは、オープンソース エコシステムへのサプライ チェーン攻撃が増え続けていることへの対応です。

サプライ チェーン攻撃が成立するのは、チェーンのリンク部分に弱点があるからです。ビルドシステム、ソースコード管理ツール、アーティファクト リポジトリなどのコンポーネントは、すべて重要な実稼働環境なので、それ相応に扱う必要があります。そのためには、まず、チェーン全体の出所を検証できるようにする必要があり、Sigstore の目的はこれを実現することです。

現在、私たちは、このパターンとツールを使って、デバイスのファームウェアで、ハードウェアによって強制されるサプライ チェーンの整合性を実現する作業をしています。これにより、ファームウェアのサプライ チェーンに透明性とアカウンタビリティが導入されるので、私たちが日々利用するスマートフォンなどのデバイスに対するサプライ チェーン攻撃が減るものと期待しています。

以上のすべての例で、検証可能なデータ構造を使い、サプライ チェーンでアーティファクトの整合性を保証しています。これにより、顧客、監査者、内部セキュリティ チームは、サプライ チェーンのすべての関係者がそれぞれの責任を果たしていることを確信できます。これは、サプライ チェーンの利用者の信頼を得るうえで役立ち、発覚する可能性が増えるため内部関係者による立場の悪用を阻止できます。また、アカウンタビリティが導入され、関連システムが継続的にコンプライアンス義務を果たせるようになります。

このパターンを使う場合、最も重要なタスクは、どのデータを記録するかを定義することです。そこで、分類とモデリングのフレームワークを作成しました。これは、以上で説明したシステムに検証可能性を組み込む際の設計に役立ちました。ご活用いただければ幸いです。
検証可能なデータ構造の詳細については、transparency.dev ウェブサイトや、皆さん独自のアプリケーションで使っていただけるようにまとめたツールやガイダンスをご覧ください。

Google Cloud Next の登録受付を開始（開催日: 10 月 12～14 日）

※この投稿は米国時間 2021 年 7 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。2021 年 10 月 12 日から 14 日に開催される Google Cloud Next の登録の受付が開始されました。Google Cloud を代表するこのイベントは、今年は Google Cloud のようにオープンで柔軟性に富んだ内容となっており、最適な参加方法を自由にお選びいただけます。参加者一人ひとりがいっそう自分に合った体験ができるように、Next ’21 はカ…

Chrome 92 でのフィッシング検知の高速化と効率化

この記事は Chrome デベロッパー、Olivier Li Shing Tat-Dupuis による Chromium Blog の記事 “Faster and more efficient phishing detection in M92” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ウェブをブラウジングする Chrome ユーザーの安全を確保することは、Chrome にとって非常に重要です。実際、セキュリティは 4 つの基本原則の 1 つであり続けています。ときに、セキュリティのためにパフォーマンスが犠牲になることがあります。パフォーマンスの探求シリーズの次の投稿では、オンラインのユーザーの安全を確保するフィッシング検知アルゴリズムをどのように改善したかについてお伝えします。ここで紹介する改善によって、現在のフィッシング検知は 50 倍高速になり、電池使用量も少なくなっています。

フィッシング検知

Chrome は新しいページに移動するたびに、ページの一連のシグナルがフィッシング サイトのシグナルと一致するかどうかを評価します。これを行うため、アクセスしたページのカラー プロファイル（ページで表示される色の範囲と頻度）と、通常のページのカラー プロファイルを比較しています。たとえば以下のイメージでは、ほとんどがオレンジ色で、緑と少しばかりの紫が含まれていることがわかります。

サイトが既知のフィッシング サイトと一致した場合、Chrome は警告をし、個人情報を保護して認証情報が漏れることを防ぎます。

フィッシングの試みが検知された場合に表示される画面

プライバシーを守るため、Chrome のセーフ ブラウジング モードは、デフォルトでブラウザ外にイメージを送信することはありません。これはプライバシーにとってはよいことですが、マシンはイメージを分析する作業をすべて自力で行わなければならないことになります。

多くの場合、イメージ処理は重いワークロードになる可能性があります。イメージの分析には、一般的に「ピクセルループ」と呼ばれる処理をし、各ピクセルを評価する必要があるからです。最新のモニターの中には最大で 1400 万ピクセルを超えるものもあります。そのため、各ピクセルで単純な操作をするだけでも、積もり積もってかなりの CPU 使用量になります。フィッシング検知で各ピクセルに対してするのは、基本色を数える操作です。

この操作は、次のようになります。この数は、ハッシュマップと呼ばれる連想データ構造に格納されます。各ピクセルについて RGB のカラー値を抽出し、その数を色ごとに 1 つずつ、3 つの異なるハッシュマップのいずれかに格納します。

効率の改善

ハッシュマップに 1 つの項目を追加するのは高速ですが、この操作は何百万ものピクセルに対して行う必要があります。分析の質が損なわれないように、ピクセルの数を減らすことは避けますが、計算自体は改善できます。

次のようにパイプラインを改善します。

  • このコードでは、3 つのハッシュマップで RGB チャンネルを追跡するのではなく、ハッシュマップを 1 つだけ使って色ごとにインデックスを管理します。これで、数える回数が 3 分の 1 になります。
  • 連続したピクセルは、ハッシュマップで数える前に合計します。これにより、均一な背景色のサイトでは、ハッシュマップのオーバーヘッドがほぼゼロになります。

その結果、色を数える操作は次のようになります。ハッシュマップの操作が大幅に減っていることに注意してください。

高速化の成果

Chrome M92 以降のイメージベースのフィッシング分類は、50 パーセンタイルで最大 50 倍高速に、99 パーセンタイルで 2.5 倍高速に実行されます。平均で、ユーザーがフィッシング分類結果を取得するまでの時間は 1.8 秒から 100 ミリ秒に短縮されます。

これにより、Chrome を使ううえで 2 つのメリットがあります。1 つ目かつ最大のメリットは、同じ作業をするために消費する CPU 時間が減り、総合的なパフォーマンスが向上することです。CPU 時間が減れば、電池の消耗もファンが回る時間も少なくなります。
2 つ目は、結果を早く取得できるため、Chrome が警告を早く表示できることです。この最適化により、処理に 5 秒以上かかるリクエストの割合が 16.25% から 1.6% 未満に下がりました。この速度の改善により、特に悪意のあるサイトでパスワードの入力を防ぐという点で、セキュリティに大きな違いが生まれます。 

総じて、今回の変更により、Chrome のレンダラー プロセスとユーティリティ プロセスが使用する合計 CPU 時間を約 1.2% 削減できました。

Chrome の規模では、わずかなアルゴリズムの改善であっても、全体では膨大なエネルギー効率の向上になります。つまり、何世紀分にも相当する CPU 時間を節約できます。

今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

Open Cloud Summit 開催のご案内

9 月 14 日（火）から 4 日間にわたり Open Cloud Summit を開催いたします。アプリを高速に開発、改善することが重要な時代になってきています。Kubernetes やサーバーレス プラットフォームを利用した、モダンなシステム構築や開発、最新の運用管理について、わかりやすくお伝えします。そして、お客様セッションでは、デンソー、日本経済新聞社、日本総合研究所、ビザスク、ブレインパッド、みんなの銀行にご登壇いただき、現場目線での Google Cloud 活用事例をお話しいただきます…