ローカル データベース

このドキュメントは、Update API（v4）メソッド threatListUpdates.fetch に適用されます。

データベースの設定

Update API を使用するクライアントは、ローカル データベースを設定し、使用するセーフ ブラウジング リストの初期ダウンロードを行う必要があります。まず、safebrowsing Go パッケージをビルドしてデプロイします（または、このパッケージを使用して独自の実装をモデル化します）。詳しくは、https://github.com/google/safebrowsing/ をご覧ください。

データベースの更新

最新の脅威から保護するため、クライアントは threatListUpdates.fetch メソッドを使用してローカルのセーフ ブラウジング リストを定期的に更新することを強くおすすめします。 threatListUpdates.fetch リクエストでは、更新するリストを指定します。クライアントにメモリや帯域幅の制限がある場合は、リクエストを使用して更新の制約を設定することもできます（更新の制約をご覧ください）。以下で説明するように、threatListUpdates.fetch レスポンスはリストごとに完全な更新または部分更新のいずれかを返します。

フル アップデート

クライアントが threatListUpdates.fetch リクエストの state フィールドが空のままになっている場合、またはフル アップデートが必要であるとサーバーが判断した場合には、完全な更新が返されます。完全な更新の場合は、追加のみが返されます。クライアントは、更新を適用して検証チェックを実施する前に、ローカル データベースを消去する必要があります。

空の状態

クライアントがリストの最初のリクエストを送信すると、完全な更新が返されます。この場合、指定する値がないため、リクエストの state フィールドは空のままとなり、レスポンスの newClientState フィールドはローカルリストの初期状態を返します。クライアントが後続のリクエストで state フィールドを意図的に空のままにした場合も、完全な更新が返されます。これにより、完全な更新が強制的に行われ、レスポンスの newClientState フィールドに新しい状態が返されます。

サーバーの決定

クライアントが部分的な更新のみをリクエストした場合、セーフ ブラウジング サーバーから完全な更新が返されることがあります。これは、クライアントが最初にリストの小さいバージョンをダウンロードしてから、大きいバージョンに更新する場合に発生することがあります。サーバーは単にリスト全体を含む完全な更新を返します。また、クライアントが長期間データをダウンロードしておらず、部分的な更新をリクエストした場合にも、サーバーはリスト全体を含む完全な更新を返します。

部分更新

クライアントが threatListUpdates.fetch リクエストの state フィールドに値を指定すると、部分更新が返されます（上記の例外は、完全な更新が必要であるとサーバーが判断した場合です）。部分更新の場合は、追加と削除の両方が返されます。クライアントはローカル データベースのリストを更新し（追加前に削除を適用）、検証チェックを実行します。

追加

追加とは、ローカル データベースに追加する必要がある SHA256 ハッシュ プレフィックスです。ハッシュ プレフィックスの大部分は 4 バイトですが、一部のハッシュ プレフィックスの長さは 4 ～ 32 バイトです。したがって、複数の追加セットが返されることがあります。たとえば、1 つに 4 バイトのプレフィックスが含まれ、もう 1 つが 5 バイトのプレフィックスを含む場合などです。

クライアントが圧縮をサポートしている場合、Rice 圧縮を使用してレスポンスを圧縮できます。ただし、圧縮されるのは 4 バイトのハッシュ プレフィックスのみです。長いハッシュ プレフィックスは常に非圧縮の未加工形式で送信されます（圧縮を参照）。

削除

削除は、辞書順に並べ替えられたクライアント データベース内のゼロベースのインデックスで、ローカル データベースから削除する必要があるエントリを指します。削除のセットは 1 つだけ返されます。

クライアントが圧縮をサポートしている場合は、「rice hashes」と「rice indices」が返されます。圧縮がサポートされていない場合は、「未加工ハッシュ」と「未加工インデックス」が返されます（圧縮を参照）。

検証結果

threatListUpdates.fetch レスポンスが完全な更新または部分更新で返されると、クライアントは検証チェックを行うことが想定されます。

クライアントはまずローカル データベースのリストを更新します（追加する前に削除を適用します）。クライアントは、（辞書順に並べ替えられた）ローカルリストの SHA256 ハッシュを計算し、レスポンスで返されたチェックサムと比較します。2 つの値が同じであれば、セーフ ブラウジング リストは「正しい」と見なされます。

2 つの値が等しくない場合、セーフ ブラウジング リストは「破損」していると見なされます。クライアントはデータベースからリストを消去し、state フィールドを空の文字列に設定して 2 回目の更新を再発行する必要があります。これにより、完全な更新が強制的に行われ、まったく新しいリストと状態が返されます。