私たちは、常にセキュリティとユーザビリティのバランスを取ることを最優先し、絶えず進化する脅威の状況を把握しながら、使いやすいプロダクトを構築するよう努めています。これを実現するために、Chrome と Google セーフ ブラウジングの連携方法にいくつかの変更を加え、スムーズで中断のないウェブ ブラウジングを最適化しつつ、オンラインの安全性を確保できるようにしました。
非同期チェック
現在のセーフ ブラウジング チェックは、Chrome のページ読み込みのブロッキング パスで行われています。つまり、ユーザーは、チェックが完了するまでページを見ることができません。これは、セーフ ブラウジング API v4 で行われるようなローカル ファーストのチェックでは問題ありませんが、セーフ ブラウジング サーバーで直接行われるチェックでは、遅延が発生する可能性があります。そこで、Chrome 122 より非同期メカニズムの導入を開始します。これにより、セーフ ブラウジング サーバーでリアルタイム チェックが進行中でも、サイトを読み込めるようになるので、ページ読み込み時間が短縮され、ユーザー エクスペリエンスが向上することが期待されます。リアルタイムのサーバー側チェックでページ読み込みがブロックされることはなくなりますが、ページ読み込み後にサイトが危険であることが判明すると、警告が表示されます。
この変更によって向上するのは、パフォーマンスだけではありません。時間の経過とともに保護の質も向上します。リモート検索がページ読み込みのブロッキング パスの外側で行われるようになったため、AI や ML ベースの新たなアルゴリズムを実験して展開することで、より多くのフィッシング攻撃やソーシャル エンジニアリング攻撃を検出してブロックできるようになります。これまでは、ページ読み込みが遅くなる可能性があったので、このような実験は困難でした。
潜在的なリスクに関しては、次の点を評価し、十分な緩和策が講じられていると判断しました。
フィッシング攻撃とソーシャル エンジニアリング攻撃 : 非同期チェックに移行すると、サーバー側のセーフ ブラウジング チェックが進行中に、そのようなサイトの読み込みが開始される可能性があります。タイミングに関するデータを精査した結果、警告が表示される前にユーザーがそのようなサイトと重要なやり取りを行う（パスワード入力など）可能性は、極めて低いものと判断しました。
ブラウザに対するエクスプロイト : Chrome では、ブラウザのエクスプロイトを提供していることがわかっている一部のサイトを、ローカルのセーフ ブラウジング リストとして保持しており、これを同期的に確認する処理は今後も継続されます。また、オンラインの保護を維持するために、アップデートが利用可能になったらすぐに Chrome をアップデートすることを常にお勧めしています。
サブリソースのチェック
私たちが閲覧するほとんどのサイトには、さまざまなサブリソースが含まれており、それを使ってコンテンツがレンダリングされています。こういったサブリソースには、画像やスクリプトなどがあります。これまで、Chrome では、セーフ ブラウジングでトップレベルの URL とサブリソースの両方を確認し、害を及ぼす可能性があるサイトについて警告してきました。サブリソースの大部分は安全ですが、かつては、悪意のあるアクターによってサイトが不正使用され、大規模にマルウェアを配布したり、ブラウザを悪用したりするサブリソースが埋め込まれることもよくありました。
近年、攻撃者のそのような傾向は減少しています。サブリソースを悪用する大規模攻撃はもはや一般的ではなく、サブリソースのチェックはそれほど重要でなくなっています。さらに、インテリジェンス収集、脅威検出、セーフ ブラウジング API の進化により、サブリソース チェックを行わずに、他の方法でユーザーをリアルタイム保護することもできるようになっています。たとえば、Chrome のクライアント側ビジュアル ML モデルは、サブリソースの有無に関係なく、フィッシング ページの作成に使われる画像を特定できます。
以上を踏まえて、今後、Chrome はセーフ ブラウジングでサブリソースの URL を確認しなくなります。これにより、Chrome クライアントが Google に接続する頻度が減るので、ユーザーにとって不要なネットワーク帯域幅のコストが削減されます。セーフ ブラウジング側では、この変更によって検出ロジックと API を大幅に簡素化できるため、インフラストラクチャの信頼性と警告精度が向上し、全体的なリスクが軽減されます。
PDF ダウンロード チェック
最後に、Chrome が PDF ダウンロードを確認するためにセーフ ブラウジングにアクセスする頻度を大幅に減らしました。
かつて、PDF は人気が高く、広く使われていたファイル形式でした。時間とともに PDF ビューアが継続的に強化された（Chrome の PDF ビューアのサンドボックス化など）こともあり、PDF が広く悪用されるケースはなくなり、業界から危険なファイル形式であると報告されることもなくなっています。悪意のある PDF を閲覧してしまった場合でも、そこにはユーザーを Chrome にリダイレクトするリンクが含まれているため、ユーザーを保護する機会がもう一度得られます。
この変更の結果、Chrome のセーフ ブラウジングへのアクセス回数が毎週数十億回減少しています。
今後に向けて
以上の変更は、主に内部処理の変更です。これによって Chrome ユーザーのウェブ ブラウジング エクスペリエンスは快適になるはずですが、セキュリティが低下することはありません。私たちは、今後も脅威の状況をモニタリングし、オンラインの安全性を確保するための態勢を維持していきます。
この記事は Chromium Blog の記事 "Update to Developers: Chromium Issue Tracker migration" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Chromium で長期にわたって十分にサポートされるユーザー エクスペリエンスを提供するため、別の問題トラッカーに移行する作業を行っています。Google のチームは、2024 年 1 月に移行することを目標としています。この投稿では、その詳細を説明します。
問題の履歴やスターを含め、すべての Chromium の問題を Monorail から別のツールに移行します。Google Issue Tracker を利用した Chromium Issue Tracker が新しいツールです。このツールの変更により、豊富な機能を持ち、十分にサポートされる問題トラッカーが Chromium エコシステムに提供されます。このツールに関連する他のオープンソース プロジェクト（Git、Gerrit）に、Chromium も参加する予定です。バグの透明性レベルは、現在のまま維持されます。
Chromium の移行は 2024 年 1 月を目標としており、今後数か月にわたってマイルストーンとスケジュールに関する最新情報を共有します。
今後、新しい問題トラッカーのチュートリアルなど、主な機能を説明した追加リソースを共有します。
違う部分はありますが、簡単に移行できるようにするための作業を行っています。移行が完了すると、既存の Monorail への問題のリンクは、移行された新しい問題トラッカーの問題にリダイレクトされます。
質問や懸念などがありましたら、いつでも issue-tracker-support@chromium.org までお問い合わせください。
P-MAX キャンペーンの最近発表された検索テーマ（ベータ版）機能を使うと、Google AI に顧客やビジネスに関する貴重な情報を提供して、P-MAX キャンペーンの配信とプレースメントをさらに最適化できます。 Google Ads API v15 以降では、API で P-MAX キャンペーンの検索テーマを作成できます。
BRAND
CustomerNegativeCriterionService
NegativeKeywordList
url_expansion_opt_out
campaign_search_term_insight
customer_search_term_insight
Google Ads API の検索テーマは AssetGroupSignal の一種で、アセット グループのレベルで P-MAX キャンペーンにアタッチできます。アセット グループに検索テーマを追加するには、 AssetGroupSignal を作成し、AssetGroupSignal.search_theme に検索テーマを表すテキスト文字列（「子ども向けアクティビティ」など）を含めた SearchThemeInfo 条件を設定します。さらに、AssetGroupSignal.asset_group にターゲットとする既存のアセット グループのリソース名を設定する必要があります。
AssetGroupSignal
AssetGroupSignal.search_theme
SearchThemeInfo
AssetGroupSignal.asset_group
次に、検索テーマ アセット グループ シグナルを作成する Java の例を示します。
// Creates a search theme asset group signal. AssetGroupSignal assetGroupSignal = AssetGroupSignal.newBuilder() .setAssetGroup(assetGroupResourceName) .setSearchTheme( SearchThemeInfo.newBuilder().setText("activities for children").build()) .build();
同じアセット グループをターゲットにして複数の AssetGroupSignal オブジェクトを作成すると、複数のアセット グループ シグナルを 1 つのアセット グループに追加することができます。ただし、1 つの AssetGroupSignal オブジェクトで表すことができるのは、1 つの検索テーマまたはオーディエンス シグナルのみです。
asset_group_signal リソースを使うと、Google 広告アカウントに存在する検索テーマを取得できます。現在のところ、パフォーマンスの指標はアセット グループ レベルで利用できますが、アセット グループ シグナル レベルでは利用できません。
asset_group_signal
次に、特定のアセット グループの検索テーマのテキストを取得する GAQL の例を示します。
SELECT asset_group_signal.search_theme.text FROM asset_group_signal WHERE asset_group.id = <Asset Group ID>
Google Ads API の v15 には、search_theme の承認に関する追加情報を含む 2 つの新しいフィールドである asset_group_signal.approval_status と asset_group_signal.disapproval_reasons も導入しています。検索テーマのテキストは、Google による承認を受ける必要があります。 asset_group_signal.approval_status フィールドには、承認ステータスに関する情報が含まれます。検索テーマのテキストが承認されない場合は、asset_group_signal.disapproval_reasons フィールドにその理由が含まれます。
search_theme
asset_group_signal.approval_status
asset_group_signal.disapproval_reasons
次に、特定のアセット グループの検索テーマのテキストとポリシー審査情報を取得する GAQL の例を示します。
SELECT asset_group_signal.search_theme.text, asset_group_signal.approval_status, asset_group_signal.disapproval_reasons FROM asset_group_signal WHERE asset_group.id = <Asset Group ID>
検索テーマのテキストが Google のポリシーに準拠していると思われるにもかかわらず承認されない場合は、ポリシー違反となった検索テーマのポリシー適用除外リクエストを送信できます。
たとえば、検索テーマに医学用語が含まれており、その用語を Google 広告のポリシーに準拠して使用していて、さらに審査を受ける正当な理由があると思われる場合は、AssetGroupSignalOperation.exempt_policy_violation_keys[] フィールドを使ってポリシーの適用除外をリクエストできます。
AssetGroupSignalOperation.exempt_policy_violation_keys[]
この記事は、皆さんから要望があった新機能や今後予定されている機能についてお伝えするシリーズの一部です。今後のアップデートや改善についてお伝えするデベロッパー ブログにご注目ください。 Google Ads API と P-MAX の連携についてのフィードバックも、引き続きお寄せください。サポートが必要な場合は、いつものようにチームにお問い合わせください。
P-MAX キャンペーンを初めて使う方は、スタートガイドで詳細をご確認ください。詳細については、アセット グループとアセット グループ シグナルのガイドをご覧ください。
Chromium の問題追跡システムの移行が完了したことをお知らせします！Issue Tracker とサポート ドキュメントにはこちらからアクセスできます。
問題追跡システムを Monorail から Chromium Issue Tracker（Google Issue Tracker を利用しています）に移行することで、Chromium エコシステムに豊富な機能と充実したサポートを備えた問題トラッカーを導入しました。Chromium は、このツールに関連する他のオープンソース プロジェクト（Git、Gerrit）に参加します。
既存の Monorail への問題のリンクは、移行された新しい問題トラッカーの問題にリダイレクトされます。今後も、フィードバックを重視して問題トラッカーのエクスペリエンスを改善していく予定です。
質問や懸念事項などがありましたら、いつでも issue-tracker-support@chromium.org までお問い合わせください。
Posted by Eiji Kitamura - Developer Relations Team
昨年お知らせしたように、Chromium で長期にわたって十分にサポートされるユーザー エクスペリエンスを提供するため、別の問題トラッカーに移行する作業を行っています。移行は、2024 年 2 月 2 日 午後 5 時（太平洋標準時）より開始し、2024 年 2 月 4 日（太平洋標準時）までに完了する予定です。
移行が完了しましたら、別の投稿でお知らせします。移行が完了すると、既存の Monorail への問題のリンクは、移行された新しい問題トラッカーの問題にリダイレクトされます。今後も、フィードバックを重視して問題トラッカーのエクスペリエンスを改善していく予定です。移行が完了したタイミングで、chromium.org に一般的な新しいワークフローに関するドキュメントを追加します。
