URLs and Hashing

このセクションでは、クライアントが URL を確認する方法の詳細な仕様について説明します。

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 など）は削除しないでください。

2 つ目は、URL の末尾がフラグメントになっている場合は、フラグメントを削除します。たとえば、http://google.com/#frag を http://google.com/ に短縮します。

3 つ目に、パーセント エスケープがなくなるまで繰り返して、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 に変換する必要があります。
    • well-known プレフィックス 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 の決定は、Public Suffix List に基づいて行う必要があります。たとえば、a.b.example.com では、eTLD+1 ドメインが example.com になり、ホスト コンポーネントが b.example.com 1 つ追加されます。
  • 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/

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

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 メソッドを使用してローカル データベースのリストをダウンロードする場合、サーバーから送信されたハッシュの長さは、ハッシュの長さを示す接尾辞を含むリストの命名規則内にエンコードされます。詳しくは、使用可能なリストのセクションをご覧ください。