Overview

データの更新頻度

Google セーフ ブラウジング v5 が v4（具体的には v4 Update API）から大きく改善された点の 1 つは、データの更新頻度と対象範囲です。保護がクライアントが管理するローカル・データベースに大きく依存するため、ローカル・データベースの更新の遅延とサイズが、保護されない主な原因となっています。v4 の場合、最新版の脅威リストを取得するのに通常 20 ～ 50 分かかります。残念なことに、フィッシング攻撃は急速に広がります。2021 年現在、攻撃を行うサイトの 60% が 10 分以内に応答しています。Google の分析によると、フィッシング対策が機能しない約 25 ～ 30% は、このようなデータの未更新が原因です。さらに、一部のデバイスは Google セーフ ブラウジングの脅威リスト全体を管理できておらず、時間の経過とともに拡大し続けています。

v5 では、リアルタイム保護と呼ばれる運用モードが導入されています。これにより、前述のデータ未更新の問題を回避できます。v4 では、クライアントはローカル データベースをダウンロードして維持し、ローカルにダウンロードした脅威リストと照合し、プレフィックスの部分一致の場合はリクエストを実行して、ハッシュ全体をダウンロードすることが想定されています。v5 では、クライアントは脅威リストのローカルデータベースを引き続きダウンロードして維持する必要がありますが、クライアントは、無害である可能性が高いサイトのリスト（グローバルキャッシュと呼ばれる）をダウンロードし、このグローバルキャッシュのローカルチェックとローカルの脅威リストチェックの両方を実行し、最後に、脅威リストの接頭辞が部分一致の場合、またはグローバルキャッシュに一致しない場合に、完全なハッシュのダウンロードをリクエストします。（クライアントが必要とするローカル処理の詳細については、以下の手順を参照してください）。これは、「デフォルトで許可」から「デフォルトで確認」に移行することを意味しており、ウェブ上での脅威の拡散が加速されることを踏まえて保護を強化できます。言い換えれば、このプロトコルはほぼリアルタイムで保護するように設計されたもので、クライアントがより新しい Google セーフ ブラウジング データを活用することを目指しています。

IP プライバシー

Google セーフ ブラウジング（v4 または v5）では、リクエストの処理中にユーザー ID に関連する処理は一切行われません。Cookie が送信されても無視されます。リクエストの送信元の IP アドレスは Google に認識されますが、この IP アドレスは重要なネットワーキング ニーズ（レスポンスの送信など）と DoS 対策の目的でのみ使用されます。

v5 と並行して、Safe Browsing Oblivious HTTP Gateway API というコンパニオン API を導入します。Oblivious HTTP を使用して、エンドユーザーの IP アドレスを Google から非表示にします。コラボレーションしない第三者で暗号化されたユーザー リクエストを処理し、それを Google に転送するという仕組みです。つまり、サードパーティは IP アドレスにのみアクセスでき、Google はリクエストのコンテンツにのみアクセスできます。サードパーティは Oblivious HTTP Relay（Fastly が提供するサービスなど）を運用し、Google は Oblivious HTTP ゲートウェイを運用しています。これはオプションのコンパニオン API です。Google セーフ ブラウジングと併用すると、エンドユーザーの IP アドレスが Google に送信されなくなります。

使用上の許可

Safe Browsing API は非営利目的での使用のみを目的としています（「販売や収益創出を目的としない」）。商用目的のソリューションが必要な場合は、Web Risk をご覧ください。

料金

Google Safe Browsing API はすべて無料でご利用いただけます。

割り当て

デベロッパーには、Safe Browsing API を有効にすると、デフォルトの使用量割り当てが割り当てられます。現在の割り当てと使用量は、Google Developer Console で確認できます。現在割り当てられている割り当てを超えることが予想される場合は、Play Console の割り当てインターフェースから追加の割り当てをリクエストできます。Google はこれらのリクエストを審査し、サービスの可用性がすべてのユーザーのニーズを満たしていることを確認するために、割り当ての増加を申請する際に連絡をお願いしています。

適切な URL

Google セーフ ブラウジングは、ブラウザのアドレスバーに表示される URL に作用するように設計されています。サブリソース（HTML ファイルによって参照される JavaScript や画像、JavaScript によって開始された WebSocket URL など）のチェックに使用するようには設計されていません。このようなサブリソース URL は、Google セーフ ブラウジングと照合しないでください。

URL にアクセスしてリダイレクト（HTTP 301 など）する場合は、リダイレクト URL を Google セーフ ブラウジングに照らしてチェックすることをおすすめします。クライアントサイドで History.pushState などの URL 操作が行われても、新しい URL が Google セーフ ブラウジングでチェックされることはありません。

ユーザーへの警告

Google セーフ ブラウジングを使用して特定のウェブページのリスクについてユーザーに警告する場合は、次のガイドラインが適用されます。

このガイドラインは、ページが安全でないウェブ リソースであると 100% 確実にはわからないページであること、および警告が潜在的なリスクを特定するだけであることを明確にすることで、ニュース メディアと Google の両方を誤解から守ることを目的としています。

• ユーザーに表示される警告で、問題のページが安全でないウェブリソースであるという確信を持たせることはできません。特定されているページ、またはそのページがユーザーにもたらす潜在的なリスクに言及する場合は、「疑わしい」、「潜在的」、「可能性あり」、「可能性あり」などの用語を使用して警告を確認する必要があります。
• 警告は、ユーザーが Google によるさまざまな脅威の定義を確認することで詳細を把握できるようにする必要があります。次のリンクをおすすめします。
  • ソーシャル エンジニアリング: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • マルウェアと望ましくないソフトウェア: https://developers.google.com/search/docs/monitor-debug/security/malware
  • 有害な可能性があるアプリ（Android のみ）: https://developers.google.com/android/play-protect/potentially-harmful-applications
• セーフ ブラウジング サービスで危険と判断されたページについて警告を表示する場合は、「Google 提供のアドバイザリ」という行とセーフ ブラウジング アドバイザリへのリンクを記載して、Google に帰属を表示する必要があります。商品に他のソースに基づく警告も表示される場合、Google 以外のデータから得られる警告に Google アトリビューションを含めることはできません。

• サービスのドキュメントでは、Google セーフ ブラウジングによる保護は完全ではないことをユーザーに知らせる通知を行う必要があります。偽陽性（リスクがあると報告された安全なサイト）と偽陰性（リスクのフラグが付けられていないサイト）の両方の可能性があることを、保護者に知らせる必要があります。次の表現を使用することをおすすめします。

  Google は、安全でないウェブリソースについて、正確で最新の情報を提供するために尽力しています。ただし、Google では、サイトの情報が包括的でエラーがないことを保証するものではありません。危険なサイトが検出されない場合や、安全なサイトが誤って特定される場合もあります。

リアルタイム モード

クライアントがリアルタイム モードで Google セーフ ブラウジング v5 を使用する場合、クライアントはローカル データベースに次のものを保持します。（i）正当なサイトのグローバル キャッシュ（ホスト サフィックス/パス プレフィックスの URL 式の SHA256 ハッシュ形式）、（ii）一連の脅威リスト（ホスト サフィックス/パス プレフィックス URL 式の SHA256 ハッシュ プレフィックス形式）大まかに言えば、クライアントが特定の URL をチェックするたびに、Global Cache を使用してローカル チェックが実行されます。チェックに合格すると、ローカル脅威リストのチェックが実行されます。それ以外の場合、クライアントは以下で説明するようにリアルタイム ハッシュ チェックを続行します。

ローカル データベースに加えて、クライアントはローカル キャッシュを保持します。このようなローカル キャッシュは、永続ストレージに存在する必要はなく、メモリが圧迫された場合に消去される場合があります。

手順の詳細については、下記をご覧ください。

ローカルリスト モード

このモードで Google セーフ ブラウジング v5 を選択した場合、クライアントの動作は v5 の改善された API サーフェスを使用している点を除き、v4 Update API と同様です。クライアントはローカル・データベースに、ホスト・サフィックス/パス・プレフィックスの URL 式の SHA256 ハッシュ・プレフィックスとしてフォーマットされた一連の脅威リストを保持します。クライアントが特定の URL をチェックするたびに、ローカルの脅威リストを使用してチェックが実行されます。一致する場合にのみ、クライアントはサーバーに接続してチェックを続行します。

上記と同様に、クライアントは永続ストレージに必要のないローカル キャッシュも保持します。

ストレージ不要のリアルタイム モード

クライアントが Google セーフ ブラウジング v5 をストレージ不要のリアルタイム モードで使用することを選択した場合、クライアントはローカル データベースを維持する必要がありません。クライアントが特定の URL をチェックすると、常にサーバーに接続してチェックが実行されます。このモードは、v4 Lookup API のクライアントが実装できるモードに似ています。

URL の正規化

URL を確認する前に、クライアントはその URL を正規化する必要があります。

まず、クライアントが URL を解析し、RFC 2396 に従って有効であると仮定します。URL が国際化ドメイン名（IDN）を使用している場合、クライアントは URL を ASCII Punycode 表現に変換する必要があります。URL にはパス コンポーネントを含める必要があります。つまり、ドメインの後にスラッシュを 1 つ以上含める必要があります（http://google.com ではなく http://google.com/）。

まず、URL からタブ（0x09）、CR（0x0d）、および LF（0x0a）文字を削除します。これらの文字のエスケープ シーケンス（%0a など）は削除しないでください。

次に、URL がフラグメントで終わる場合は、そのフラグメントを削除します。たとえば、http://google.com/#frag を http://google.com/ に短縮します。

次に、パーセント エスケープがなくなるまで、URL に対してパーセント エスケープを繰り返します。（これにより、URL が無効になることがあります）。

ホスト名を正規化するには:

URL からホスト名を抽出し、次の操作を行います。

1. 先頭と末尾のドットをすべて削除する。
2. 連続するドットを 1 つのドットに置き換える。
3. ホスト名を IPv4 アドレスとして解析できる場合は、4 つのドット区切りの 10 進数に正規化します。クライアントは、8 進数、16 進数、4 個未満のコンポーネントを含む、有効な IP アドレス エンコードを処理する必要があります。
4. ホスト名を角かっこ付き IPv6 アドレスとして解析できる場合は、コンポーネント内の不要な先行ゼロを削除し、ダブルコロン構文を使用してゼロ コンポーネントを折りたたんで、ホスト名を正規化します。たとえば、[2001:0db8:0000::1] は [2001:db8::1] に変換する必要があります。ホスト名が次の 2 つの特殊な IPv6 アドレスタイプのいずれかである場合は、IPv4 に変換します。
   • IPv4 にマッピングされた IPv6 アドレス（[::ffff:1.2.3.4] など）。1.2.3.4 に変換する必要があります。
   • 既知のプレフィックス 64:ff9b::/96 を使用した NAT64 アドレス（[64:ff9b::1.2.3.4] など）。1.2.3.4 に変換する必要があります。
5. 文字列全体を小文字にする。

パスを正規化するには:

1. パス内のシーケンス /../ と /./ を解決するには、/./ を / に置き換え、/../ を先行するパス コンポーネントとともに削除します。
2. 連続するスラッシュの実行は単一のスラッシュ文字に置き換えます。

これらのパスの正規化をクエリ パラメータに適用しないでください。

URL 内で、ASCII 32 以上、127 以上、#、% の文字をすべてパーセント エスケープします。エスケープには大文字の 16 進数を使用する必要があります。

ホスト / サフィックス / パス / プレフィックス式

URL を正規化したら、次のステップはサフィックス/プレフィックスの式を作成することです。各サフィックス/プレフィックス式は、ホスト サフィックス（またはフルホスト）とパス プレフィックス（またはフルパス）で構成されます。

クライアントは、最大 30 の異なるホスト サフィックスとパス プレフィックスの組み合わせを形成します。これらの組み合わせでは、URL のホストとパスのコンポーネントのみを使用します。スキーム、ユーザー名、パスワード、ポートは破棄されます。URL にクエリ パラメータが含まれている場合は、少なくとも 1 つの組み合わせにフルパスとクエリ パラメータが含まれます。

ホストの場合、クライアントは最大で 5 つの異なる文字列を試行します。できます。

• ホスト名が IPv4 または IPv6 のリテラルでない場合、eTLD+1 ドメインで始まり、先頭に続くコンポーネントを追加することで形成される最大 4 つのホスト名。eTLD+1 の判断は、公開サフィックス リストに基づいて行う必要があります。たとえば、a.b.example.com は、eTLD+1 ドメイン example.com と、ホスト コンポーネントが 1 つ追加 b.example.com になります。
• URL の正確なホスト名。前の例では、a.b.example.com がチェックされます。

パスの場合、クライアントは最大で 6 つの異なる文字列を試行します。次のとおりです。

• クエリ パラメータを含む URL の正確なパス。
• クエリ パラメータなしの URL の正確なパス。
• ルート（/）から始まり、末尾のスラッシュを含むパス コンポーネントを連続して追加することによって形成される 4 つのパス。

次の例では、チェックの動作を示します。

URL http://a.b.com/1/2.html?param=1 の場合、クライアントは次の文字列の候補を試行します。

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

URL http://a.b.c.d.e.f.com/1.html の場合、クライアントは次の文字列の候補を試行します。

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

（注: 最後の 5 つのホスト名コンポーネントと完全なホスト名のみを取得するため、b.c.d.e.f.com はスキップします）。

URL http://1.2.3.4/1/ の場合、クライアントは次の文字列の候補を試行します。

1.2.3.4/1/
1.2.3.4/

URL http://example.co.uk/1 の場合、クライアントは次の文字列の候補を試行します。

example.co.uk/1
example.co.uk/

ハッシュ化

Google セーフ ブラウジングでは、ハッシュ関数として SHA256 のみが使用されます。このハッシュ関数は、上記の式に適用する必要があります。

完全な 32 バイトのハッシュは、状況に応じて、4 バイト、8 バイト、または 16 バイトに切り捨てられます。

• 現在、hashes.search メソッドを使用する場合、リクエストのハッシュは 4 バイトに切り捨てられます。このリクエストで追加のバイト数を送信すると、ユーザーのプライバシーが侵害されます。

• hashList.get メソッドまたは hashLists.batchGet メソッドを使用してローカル データベースのリストをダウンロードする場合、サーバーによって送信されるハッシュの長さは、リストの性質と、desired_hash_length パラメータで伝達されるクライアントの設定（ハッシュ長）の両方に影響されます。

リアルタイムの URL チェック手順

この手順は、クライアントがリアルタイム オペレーション モードを選択した場合に使用されます。

この手順は、単一の URL u を受け取り、SAFE、UNSAFE、または UNSURE を返します。SAFE が返された場合、その URL は Google セーフ ブラウジングによって安全であるとみなされます。UNSAFE が返された場合、その URL は Google セーフ ブラウジングによって安全でない可能性があると判断されたため、エンドユーザーに警告を表示する、受信したメールを迷惑メールフォルダに移動する、続行する前にユーザーによる追加の確認を求めるなどの適切な措置を講じる必要があります。UNSURE が返された場合は、後で次のローカルチェック手順を使用します。

1. expressions を、URL u によって生成された接尾辞または接頭辞の式のリストとします。
2. expressionHashes をリストにすると、要素は expressions 内の各式の SHA256 ハッシュです。
3. expressionHashes の hash ごとに次の操作を行います。
   1. グローバル キャッシュで hash が見つかった場合は、UNSURE を返します。
4. expressionHashPrefixes をリストにします。このリストでは、要素は expressionHashes の各ハッシュの最初の 4 バイトです。
5. expressionHashPrefixes の expressionHashPrefix ごとに次の操作を行います。
   1. ローカル キャッシュで expressionHashPrefix を検索します。
   2. キャッシュに保存されたエントリが見つかった場合:
      1. 現在の時刻が有効期限より後かどうかを判断します。
      2. 大きい場合:
         1. 検出されたキャッシュ エントリをローカル キャッシュから削除します。
         2. ループを続行します。
      3. その値より大きい場合:
         1. この特定の expressionHashPrefix を expressionHashPrefixes から削除します。
         2. expressionHashes 内の対応する完全なハッシュが、キャッシュ エントリにあるかどうかを確認します。
         3. 見つかった場合は、UNSAFE を返します。
         4. 見つからなかった場合は、ループを続けます。
   3. キャッシュ エントリが見つからない場合は、ループを続けます。
6. RPC SearchHashes または REST メソッド hashes.search を使用して、expressionHashPrefixes を Google セーフ ブラウジング v5 サーバーに送信します。エラー（ネットワーク エラー、HTTP エラーなど）が発生した場合は、UNSURE を返します。それ以外の場合、レスポンスは SB サーバーから受信した response とします。これは、脅威の性質（ソーシャル エンジニアリング、マルウェアなど）を特定する補助情報とともに完全なハッシュのリストと、キャッシュの有効期限 expiration です。
7. response の fullHash ごとに次の操作を行います。
   1. fullHash を expiration とともにローカル キャッシュに挿入します。
8. response の fullHash ごとに次の操作を行います。
   1. expressionHashes で fullHash が見つかった結果を isFound とします。
   2. isFound が False の場合は、ループを続行します。
   3. isFound が True の場合、UNSAFE を返します。
9. SAFE を返します。

LocalThreat List の URL チェック手順

このプロシージャは、クライアントがローカルリスト モードを選択した場合に使用されます。また、上記の RealTimeCheck プロシージャが UNSURE の値を返すときにも使用されます。

この手順は、単一の URL u を受け取り、SAFE または UNSAFE を返します。

1. expressions を、URL u によって生成された接尾辞または接頭辞の式のリストとします。
2. expressionHashes をリストにすると、要素は expressions 内の各式の SHA256 ハッシュです。
3. expressionHashPrefixes をリストにします。このリストでは、要素は expressionHashes の各ハッシュの最初の 4 バイトです。
4. expressionHashPrefixes の expressionHashPrefix ごとに次の操作を行います。
   1. ローカル キャッシュで expressionHashPrefix を検索します。
   2. キャッシュに保存されたエントリが見つかった場合:
      1. 現在の時刻が有効期限より後かどうかを判断します。
      2. 大きい場合:
         1. 検出されたキャッシュ エントリをローカル キャッシュから削除します。
         2. ループを続行します。
      3. その値より大きい場合:
         1. この特定の expressionHashPrefix を expressionHashPrefixes から削除します。
         2. expressionHashes 内の対応する完全なハッシュが、キャッシュ エントリにあるかどうかを確認します。
         3. 見つかった場合は、UNSAFE を返します。
         4. 見つからなかった場合は、ループを続けます。
   3. キャッシュ エントリが見つからない場合は、ループを続けます。
5. expressionHashPrefixes の expressionHashPrefix ごとに次の操作を行います。
   1. ローカル脅威リストのデータベースで expressionHashPrefix を検索します。
   2. expressionHashPrefix がローカル脅威リストのデータベースで見つからない場合は、expressionHashPrefixes から削除します。
6. RPC SearchHashes または REST メソッド hashes.search を使用して、expressionHashPrefixes を Google セーフ ブラウジング v5 サーバーに送信します。エラー（ネットワーク エラー、HTTP エラーなど）が発生した場合は、SAFE を返します。それ以外の場合、レスポンスは SB サーバーから受信した response とします。これは、脅威の性質（ソーシャル エンジニアリング、マルウェアなど）を特定する補助情報とともに完全なハッシュのリストと、キャッシュの有効期限 expiration です。
7. response の fullHash ごとに次の操作を行います。
   1. fullHash を expiration とともにローカル キャッシュに挿入します。
8. response の fullHash ごとに次の操作を行います。
   1. expressionHashes で fullHash が見つかった結果を isFound とします。
   2. isFound が False の場合は、ループを続行します。
   3. isFound が True の場合、UNSAFE を返します。
9. SAFE を返します。

ローカル データベースを使用しないリアルタイム URL チェック手順

この手順は、クライアントがストレージを使用しないリアルタイム モードを選択した場合に使用されます。

この手順は、単一の URL u を受け取り、SAFE または UNSAFE を返します。

1. expressions を、URL u によって生成された接尾辞または接頭辞の式のリストとします。
2. expressionHashes をリストにすると、要素は expressions 内の各式の SHA256 ハッシュです。
3. expressionHashPrefixes をリストにします。このリストでは、要素は expressionHashes の各ハッシュの最初の 4 バイトです。
4. expressionHashPrefixes の expressionHashPrefix ごとに次の操作を行います。
   1. ローカル キャッシュで expressionHashPrefix を検索します。
   2. キャッシュに保存されたエントリが見つかった場合:
      1. 現在の時刻が有効期限より後かどうかを判断します。
      2. 大きい場合:
         1. 検出されたキャッシュ エントリをローカル キャッシュから削除します。
         2. ループを続行します。
      3. その値より大きい場合:
         1. この特定の expressionHashPrefix を expressionHashPrefixes から削除します。
         2. expressionHashes 内の対応する完全なハッシュが、キャッシュ エントリにあるかどうかを確認します。
         3. 見つかった場合は、UNSAFE を返します。
         4. 見つからなかった場合は、ループを続けます。
   3. キャッシュ エントリが見つからない場合は、ループを続けます。
5. RPC SearchHashes または REST メソッド hashes.search を使用して、expressionHashPrefixes を Google セーフ ブラウジング v5 サーバーに送信します。エラー（ネットワーク エラー、HTTP エラーなど）が発生した場合は、SAFE を返します。それ以外の場合、レスポンスは SB サーバーから受信した response とします。これは、脅威の性質（ソーシャル エンジニアリング、マルウェアなど）を特定する補助情報とともに完全なハッシュのリストと、キャッシュの有効期限 expiration です。
6. response の fullHash ごとに次の操作を行います。
   1. fullHash を expiration とともにローカル キャッシュに挿入します。
7. response の fullHash ごとに次の操作を行います。
   1. expressionHashes で fullHash が見つかった結果を isFound とします。
   2. isFound が False の場合は、ループを続行します。
   3. isFound が True の場合、UNSAFE を返します。
8. SAFE を返します。

データベースの更新

クライアントは定期的に hashList.get メソッドまたは hashLists.batchGet メソッドを呼び出して、データベースを更新します。一般的なクライアントでは一度に複数のリストを更新するため、hashLists.batchGet メソッドを使用することをおすすめします。

リストは個別の名前で識別されます。名前は数文字の短い ASCII 文字列です。

脅威の種類、プラットフォームの種類、脅威のエントリの種類のタプルによってリストが識別される V4 とは異なり、v5 のリストでは単に名前で識別されます。これにより、複数の v5 リストが同じ脅威タイプを共有している場合に柔軟に対応できます。プラットフォーム タイプと脅威エントリ タイプは v5 で削除されます。

いったんリストの名前を選択すると、名前は変更されません。また、一度表示されたリストは削除されません（そのリストが有用でなくなった場合は空になりますが、存在し続けます）。そのため、こうした名前は Google セーフ ブラウジングのクライアント コードにハードコードすることをおすすめします。

hashList.get メソッドと hashLists.batchGet メソッドはどちらも、増分更新をサポートしています。増分アップデートを使用すると、帯域幅を節約でき、パフォーマンスが向上します。増分更新は、クライアントのリストのバージョンとリストの最新バージョンの間で差分を取得することで機能します。（クライアントが新しくデプロイされ、利用可能なバージョンがない場合は、フル アップデートを利用できます）。増分アップデートには、削除のインデックスと追加が含まれています。クライアントはまず、指定されたインデックスのエントリをローカル データベースから削除してから、その追加を適用することが求められます。

最後に、破損を防ぐため、クライアントは保存されたデータをサーバーが提供するチェックサムと照合する必要があります。チェックサムが一致しない場合、クライアントはフル アップデートを実行する必要があります。

リスト コンテンツのデコード

リストはすべて、サイズを小さくするために特別なエンコードを使用して配信されます。このエンコードは、Google セーフ ブラウジング リストに概念的には、統計的にランダムな整数と区別できないハッシュまたはハッシュ プレフィックスが含まれていることを認識することで行われます。これらの整数を並べ替えて隣接差分を取得すると、そのような隣接差分はある意味「小さい」と予想されます。Golomb-Rice エンコードはこの小さい性を悪用します。

Google セーフ ブラウジング v5 には、4 バイトのデータ、8 バイトのデータ、16 バイトのデータ、32 バイトのデータを扱う 4 種類のデータがあります。数値的に連続する 3 つの 4 バイトの整数がエンコードされる例を見てみましょう。k で表される Rice パラメータを 3 とします。エンコードの商の部分は、単に k ビットだけ右にシフトされた隣接差分値です。与えられた整数は連続しているため、隣接する差分は 1 になり、3 ビットシフトした後の商部はゼロになります。最下位 k ビットは 001 です。商ゼロは単一の 0 ビットとしてエンコードされます。余りは 1 で、100 にエンコードされます。これを繰り返して、ビットストリーム 01000100 を形成する。結果のビットストリームは、リトル エンディアンを使用して 00100010 としてエンコードされます。したがって、次のデータに対応します。

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

上記の 32 ビット整数のデコードステップの後、結果は除去インデックスまたは追加のいずれかとして直接使用可能です。v4 とは異なり、後でバイトスワップを実行する必要はありません。

使用可能なリスト

v5alpha1 では、次のリストを使用することをおすすめします。

別のリストは後日利用可能になり、その時点で上記の表が展開されます。

更新の頻度

クライアントは、minimum_wait_duration フィールドでサーバーによって返された値を調べ、その値を使用してデータベースの次回の更新をスケジュールする必要があります。この値はゼロになる可能性があり、その場合はクライアントはすぐに別の更新を実行する必要があります。

変換リストの更新

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

リクエストに次の変更を行う必要があります。

1. v4 ClientInfo オブジェクトを完全に削除します。専用のフィールドを使用してクライアントの ID を指定する代わりに、既知の User-Agent ヘッダーを使用します。このヘッダーにクライアント ID を入力するための所定の形式はありませんが、元のクライアント ID とクライアント バージョンをスペースまたはスラッシュで区切って指定することをおすすめします。
2. v4 ListUpdateRequest オブジェクトごとに、次の操作を行います。
   • 上の表で対応する v5 リスト名を検索し、その名前を v5 リクエストで指定します。
   • threat_entry_type や platform_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. 32 ビット整数の Rice デコード アルゴリズムを調整する必要があります。違いは、エンコードされたデータが異なるエンディアンでエンコードされることです。v4 と v5 の両方で、32 ビットのハッシュ プレフィックスは辞書順に並べ替えられます。ただし、v4 では、これらの接頭辞は並べ替えたときにリトル エンディアンとして扱われますが、v5 では、接頭辞は並べ替えたときにビッグ エンディアンとして扱われます。つまり、辞書順による並べ替えはビッグ エンディアンによる数値の並べ替えと同じであるため、クライアント側で並べ替えを行う必要はありません。Chromium v4 の実装におけるこのような形式の例については、こちらをご覧ください。このような並べ替えは解除できます。
4. 他のハッシュ長については、Rice デコード アルゴリズムを実装する必要があります。

ハッシュ検索の変換

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

リクエストに次の変更を行う必要があります。

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

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

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