※この投稿は米国時間 2021 年 7 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

この記事は 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% 未満に下がりました。この速度の改善により、特に悪意のあるサイトでパスワードの入力を防ぐという点で、セキュリティに大きな違いが生まれます。 

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

お申込み受付中 : https://goo.gle/OCS_gcbg

開催概要

名　称　Open Cloud Summit 
日　程　9 月 14 日（火）～ 9 月 16 日（木）14:00 - 18:30
　　　 （Cloud Study Jam ハンズオン は 9 月 17 日（金） 14:00-17:00 に開催）
対　象　開発エンジニア、インフラエンジニア、運用エンジニア
参加費　無料（事前登録制）
登　録　https://goo.gle/OCS_gcbg

ピックアップ セッション

Data Cloud Summit 本登録開始

この記事は Google Chrome チーム、Shweta Panditrao、Devon O'Brien、Emily Stark による Chromium Blog の記事 "Increasing HTTPS adoption" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ブラウザが（HTTP でなく）HTTPS でウェブサイトに接続すると、ネットワーク上の盗聴者や攻撃者は、その接続で共有されるデータ（個人情報やそのページ自体など）を傍受したり改変したりできなくなります。ウェブのエコシステムにとって、このレベルのプライバシーとセキュリティは不可欠です。そのため、Chrome では HTTPS のサポートを広げるための取り組みを継続しています。
ありがたいことに、HTTPS の採用はここ数年で大幅に増加しています。また、ほとんどのオペレーティング システムで、Chrome が読み込むページの 90% 以上が HTTPS になっています。しかし、HTTPS をウェブの優先プロトコルにし、HTTPS をサポートしていない残りのウェブでユーザーの保護を強化するために、まだできることがあります。そこで今回は、この領域での今後の作業についてお知らせします。

HTTPS ファーストの世界をオプトインする

M94 以降の Chrome は HTTPS ファースト モードを提供します。このモードでは、すべてのページ読み込みが HTTPS にアップグレードされ、HTTPS をサポートしないサイトを読み込む際には、ページ全体に警告が表示されます。このモードを有効にすると、可能な場合には常に HTTPS でサイトに接続し、HTTP でサイトに接続する前には警告が表示されることが保証されます。エコシステムからのフィードバックに基づき、将来的には、すべてのユーザーで HTTPS ファースト モードをデフォルトにする予定です。Mozilla も、将来的に Firefox のウェブ ブラウジングを HTTPS 専用モードにする予定であることを発表しました。

鍵アイコンの実験

HTTPS ファーストの未来に向かうにあたり、ブラウザがサイトを HTTPS で読み込んでいることを示すために使われることが多い鍵アイコンの再検討も行っています。とりわけ、Google の調査によると、実際に安全なのは接続のみであるにもかかわらず、ユーザーはこのアイコンを信頼できるサイトとみなすことがわかっています。最近の調査では、鍵アイコンの意味を正しく認識できたのは、回答者の 11% だけでした。Chrome の M93 では、この混乱を減らすための試みとして、アドレスバーの鍵アイコンをこれまでよりも中立的なページ情報の入口に置き換える実験をする予定です（下の例を参照）。この実験により、重要なプライバシーとセキュリティの情報や、ページ情報で提供されるコントロール（サイトのパーミッションなど）が見つけやすくなることを期待しています。重要なのは、HTTPS がサポートされていないサイトで「保護されていない通信」のインジケーターが表示される点は変わらないことです。また、この実験には、オプトアウトを希望する組織のためのエンタープライズ ポリシーも含まれています。いずれの場合も、全面的にリリースを行う場合は、事前にお知らせします。

HTTP ウェブのユーザーを保護する

今後のバージョンの Chrome でユーザーが HTTPS ファースト モードを採用することを楽しみにしていますが、その一方で、Chrome の HTTP 接続のサポートを継続し、安全でない接続を使用しているときに常にユーザーを保護して通知をするための追加策を実施します。新機能を安全なオリジンに限る、安全でないオリジンで充実した機能を使えなくするといったこれまでの取り組みの続きとして、ウェブ プラットフォームのさまざまな機能を評価して HTTP ウェブページで制限すべきかどうかを判断する作業に着手する予定です。

ユーザーに最大限のセキュリティ強化を提供する変更に注力できるように、この領域で今後優先する作業は、以下の原則に従って判断します。

• 安全でない接続を利用するサイトを、信頼するかどうか判断する際の情報提供を強化する
• 安全でない接続では、サイトでセキュリティ ポリシーをオプトアウトできないように制限する
• 安全でない接続で提供されたサイトのコンテンツを Chrome が保存する方法や期間を制限する

この原則に基づく行動予定の詳しい説明や、影響を受ける機能リストの改訂版は、Chromium Wiki で管理されています。また、今年中にさらに詳しい情報をお伝えする予定です。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google Open Source Security チーム、Kim Lewandowski、Azeem Shaikh、Laurent Simon による Google Online Security Blog の記事 "Measuring Security Risks in Open Source Software: Scorecards Launches V2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この記事は Mike Cloonan による Google Ads Developer Blog の記事 "Standalone Gmail campaigns becoming read only in Google Ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。