Migration From V4

Google Safe Browsing v5 は、v4（特に v4 Update API）と比較して、データの更新頻度とカバレッジが大幅に改善されています。この保護はクライアントが管理するローカル データベースに大きく依存するため、ローカル データベースの更新の遅延とサイズが保護の失敗の主な原因となります。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 オブジェクトごとに、次のようにします。
*   Look up the corresponding v5 list name from the [available
    lists](/safe-browsing/reference/Local.Database#available-lists) and
    supply that name in the v5 request.
*   Remove unneeded fields such as `threat_entry_type` or `platform_type`.
*   The `state` field in v4 is directly compatible with the v5 `versions`
    field. The same byte string that would be sent to the server using the
    `state` field in v4 can simply be sent in v5 using the `versions` field.
*   For the v4 constraints, v5 uses a simplified version called
    [`SizeConstraints`](/safe-browsing/reference/rest/v5/SizeConstraints).
    Additional fields such as `region` should be dropped.

レスポンスに次の変更を加えます。

  1. v4 の 列挙型 ResponseType は、partial_update という名前のブール値フィールドに置き換えられています。
  2. minimum_wait_duration フィールドをゼロにするか、省略できるようになりました。期限切れの場合は、クライアントにすぐに別のリクエストを行うよう依頼します。これは、クライアントが SizeConstraints で最大更新サイズにデータベースの最大サイズよりも小さい制約を指定した場合にのみ発生します。
  3. 32 ビット整数の Rice デコード アルゴリズムを調整する必要があります。違いは、エンコードされたデータが異なるエンディアン形式でエンコードされている点です。v4 と v5 の両方で、32 ビットのハッシュ プレフィックスは辞書順に並べ替えられます。ただし、v4 ではこれらの接頭辞は並べ替え時にリトル エンディアンとして扱われますが、v5 ではビッグ エンディアンとして扱われます。つまり、辞書順の並べ替えはビッグエンディアンの数値並べ替えと同じであるため、クライアントは並べ替えを行う必要はありません。v4 の Chromium 実装におけるこの種の例は、こちらで確認できます。このような並べ替えは削除できます。
  4. ライス復号アルゴリズムは、他のハッシュ長にも実装する必要があります。

ハッシュ検索の転換

v4 では、fullHashes.find メソッドを使用して完全なハッシュを取得します。v5 の同等のメソッドは 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. キャッシュは単一のキャッシュ時間に簡素化されました。キャッシュの操作については、上記の手順をご覧ください。