Migration From V4

Google セーフ ブラウジング v5 の v4(特に v4 Update API)に対する大きな改善点の 1 つは、データの鮮度とカバレッジです。保護はクライアントが維持するローカル データベースに大きく依存するため、ローカル データベースの更新の遅延とサイズが、保護の失敗の主な原因となります。v4 では、一般的なクライアントが最新バージョンの脅威リストを取得するのに 20 ~ 50 分かかります。残念ながら、フィッシング攻撃は急速に拡大しています。2021 年の時点で、攻撃を配信するサイトの 60% は 10 分未満で消滅しています。Google の分析によると、フィッシング対策が欠落している原因の約 25 ~ 30% は、このようなデータの古さによるものです。また、一部のデバイスは、時間の経過とともに拡大し続ける Google セーフ ブラウジングの脅威リスト全体を管理する機能を備えていません。

現在 v4 Update API を使用している場合は、ローカル データベースをリセットまたは消去することなく、v4 から v5 へのシームレスな移行パスがあります。このセクションでは、その方法について説明します。

コンバージョン リストの更新

V4 では、リストは脅威タイプ、プラットフォーム タイプ、脅威エントリ タイプのタプルで識別されますが、V5 ではリストは名前で識別されます。これにより、複数の v5 リストで同じ脅威タイプを共有する場合に柔軟性が得られます。v5 では、プラットフォーム タイプと脅威エントリ タイプが削除されています。

v4 では、threatListUpdates.fetch メソッドを使用してリストをダウンロードします。v5 では、hashLists.batchGet メソッドに切り替えます。

リクエストに次の変更を加える必要があります。

  1. v4 ClientInfo オブジェクトを完全に削除します。専用のフィールドを使用してクライアントの識別情報を指定する代わりに、既知の User-Agent ヘッダーを使用するだけです。このヘッダーでクライアント ID を指定する形式は規定されていませんが、元のクライアント ID とクライアント バージョンをスペース文字またはスラッシュ文字で区切って含めることをおすすめします。
  2. v4 ListUpdateRequest オブジェクトについて: * 利用可能なリストから対応する v5 リスト名を検索し、その名前を v5 リクエストで指定します。
    • threat_entry_typeplatform_type などの不要なフィールドを削除します。
    • v4 の state フィールドは、v5 の versions フィールドと直接互換性があります。v4 の state フィールドを使用してサーバーに送信されるバイト文字列は、v5 の versions フィールドを使用して送信できます。
    • v4 制約の場合、v5 では SizeConstraints という簡略版が使用されます。region などの追加フィールドは削除する必要があります。

レスポンスに次の変更を加える必要があります。

  1. v4 の enum ResponseType は、partial_update という名前のブール値フィールドに置き換えられます。
  2. minimum_wait_duration フィールドは、ゼロまたは省略できるようになりました。その場合、クライアントは直ちに別のリクエストを行うよう求められます。これは、クライアントが SizeConstraints で、データベースの最大サイズよりも小さい最大更新サイズの制約を指定した場合にのみ発生します。
  3. Rice-Golomb エンコードされたハッシュをデコードするロジックには、主に次の 2 つの調整が必要です。
    • エンディアンと並べ替え: v4 では、返されたハッシュはリトル エンディアン値として並べ替えられていました。v5 では、ビッグエンディアン値として扱われます。バイト文字列の辞書式順序の並べ替えはビッグエンディアン値の数値順序の並べ替えと同等であるため、クライアントは特別な並べ替え手順を実行する必要がなくなりました。Chromium v4 の実装のようなカスタム リトル エンディアン ソートは、以前に実装されている場合は削除できます。
    • 可変ハッシュ長: v4 で使用される 4 バイトのハッシュ長だけでなく、HashList.compressed_additions フィールドで返される可能性のあるさまざまなハッシュ長をサポートするように、デコード アルゴリズムを更新する必要があります。レスポンスで返されるハッシュの長さは、hashLists.list から返される HashList.metadata.hash_length に基づいて決定できます。また、リクエストされたハッシュリストの名前は、リストから返されるハッシュのサイズを示します。ハッシュリストの詳細については、ローカル データベースのページをご覧ください。

ハッシュ検索の変換

v4 では、fullHashes.find メソッドを使用して完全なハッシュを取得します。v5 の同等のメソッドは the hashes.search メソッドです。

リクエストに次の変更を加える必要があります。

  1. コードを構造化して、長さが 4 バイトのハッシュ プレフィックスのみを送信します。
  2. v4 ClientInfo オブジェクトをすべて削除します。専用のフィールドを使用してクライアントの識別情報を指定する代わりに、既知の User-Agent ヘッダーを使用するだけです。このヘッダーでクライアント ID を指定する形式は規定されていませんが、元のクライアント ID とクライアント バージョンをスペース文字またはスラッシュ文字で区切って含めることをおすすめします。
  3. client_states フィールドを削除します。不要になりました。
  4. threat_types などのフィールドを含める必要はなくなりました。

レスポンスに次の変更を加える必要があります。

  1. minimum_wait_duration フィールドが削除されました。クライアントは必要に応じていつでも新しいリクエストを発行できます。
  2. v4 ThreatMatch オブジェクトFullHash オブジェクトに簡略化されました。
  3. キャッシュ保存期間が 1 つに簡素化されました。キャッシュの操作については、上記の手順をご覧ください。