URLs and Hashing

Ta sekcja zawiera szczegółowe specyfikacje sposobu sprawdzania adresów URL przez klientów.

Wybór strony kanonicznej

Przed sprawdzeniem adresów URL klient musi przeprowadzić ich kanonizację.

Na początek zakładamy, że klient przeanalizował adres URL i uznał go za prawidłowy zgodnie ze standardem RFC 2396. Jeśli adres URL zawiera międzynarodową nazwę domeny (IDN), klient powinien przekonwertować adres URL do postaci Punycode ASCII. Adres URL musi zawierać element ścieżki, czyli musi mieć co najmniej 1 ukośnik po domenie (http://google.com/ zamiast http://google.com).

Najpierw usuń z adresu URL znaki tabulacji (0x09), CR (0x0d) i LF (0x0a). Nie usuwaj sekwencji znaków ucieczki (np. %0a).

Po drugie, jeśli adres URL kończy się fragmentem, usuń go. Na przykład skrócenie http://google.com/#frag do http://google.com/.

Po trzecie, powtarzaj odkodowywanie adresu URL, aż nie będzie już więcej znaków ucieczki. (może to spowodować, że adres URL stanie się nieprawidłowy).

Aby zmienić nazwę hosta na postać kanoniczną:

Wyodrębnij nazwę hosta z adresu URL, a potem:

  1. Usuń wszystkie kropki na początku i na końcu.
  2. Zastąp kolejne kropki jedną kropką.
  3. Jeśli nazwę hosta można przeanalizować jako adres IPv4, znormalizuj ją do 4 wartości dziesiętnych oddzielonych kropkami. Klient powinien obsługiwać dowolne legalne kodowanie adresów IP, w tym oktetowe, szesnastkowe i mniej niż 4 komponentów.
  4. Jeśli nazwę hosta można przeanalizować jako adres IPv6 w nawiasach, znormalizuj ją, usuwając zbędne zera na początku komponentów i upraszczając komponenty równe 0 za pomocą podwójnego dwukropka. Na przykład [2001:0db8:0000::1] należy przekształcić w [2001:db8::1]. Jeśli nazwa hosta jest jednym z tych 2 specjalnych typów adresów IPv6, przekształc ją w adres IPv4:
    • adres IPv6 mapowany na IPv4, np. [::ffff:1.2.3.4], który powinien zostać przekształcony w 1.2.3.4;
    • Adres NAT64 korzystający z znanego prefiksu 64:ff9b::/96, np. [64:ff9b::1.2.3.4], który powinien zostać przekształcony w 1.2.3.4.
  5. Użyj małych liter w całym ciągu znaków.

Aby utworzyć ścieżkę kanoniczną:

  1. Rozwiń sekwencje /../ i /./ w ścieżce, zastępując /./ przez / i usuń /../ wraz z poprzednim elementem ścieżki.
  2. Zastąp ciągi kolejnych ukośników pojedynczym znakiem ukośnika.

Nie stosuj kanonizacji ścieżek do parametrów zapytania.

W adresie URL zastosuj kody procentowe dla wszystkich znaków, które są ≤ ASCII 32, ≥ 127, # lub %. W przypadku znaków ucieczki należy używać wielkich liter.

Wyrażenia prefiksu ścieżki i sufiksu hosta

Po kanonizacji adresu URL kolejnym krokiem jest utworzenie wyrażeń prefiksu i sufiksa. Każde wyrażenie sufiksu/prefiksu składa się z sufiksa hosta (lub pełnego hosta) i prefiksu ścieżki (lub pełnej ścieżki).

Klient utworzy do 30 różnych możliwych kombinacji sufiksów hosta i prefiksów ścieżki. Te kombinacje używają tylko elementów hosta i ścieżki adresu URL. Schemat, nazwa użytkownika, hasło i port są ignorowane. Jeśli adres URL zawiera parametry zapytania, co najmniej 1 kombinacja będzie zawierać pełną ścieżkę i parametry zapytania.

W przypadku hosta klient spróbuje użyć maksymalnie 5 różnych ciągów znaków. Są to:

  • Jeśli nazwa hosta nie jest dosłowną nazwą IPv4 ani IPv6, maksymalnie 4 nazwy hosta utworzone przez dodanie kolejnych komponentów domeny eTLD+1. Określanie domeny eTLD+1 powinno być oparte na liście domen publicznych. Na przykład a.b.example.com spowoduje utworzenie domeny eTLD+1 example.com oraz hosta z jednym dodatkowym komponentem hosta b.example.com.
  • Dokładna nazwa hosta w adresie URL. W przypadku poprzedniego przykładu sprawdzana będzie wartość a.b.example.com.

W przypadku ścieżki klient spróbuje maksymalnie 6 różnych ciągów znaków. Są to:

  • Dokładna ścieżka adresu URL, w tym parametry zapytania.
  • Dokładna ścieżka adresu URL bez parametrów zapytania.
  • Cztery ścieżki utworzone przez rozpoczęcie od ścieżki katalogu głównego (/) i kolejno dołączanie elementów ścieżki, w tym ukośnika końcowego.

Zachowanie sprawdzania ilustrują te przykłady:

W przypadku adresu URL http://a.b.com/1/2.html?param=1 klient spróbuje użyć tych ciągów znaków:

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/

W przypadku adresu URL http://a.b.c.d.e.f.com/1.html klient spróbuje użyć tych ciągów znaków:

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/

(Uwaga: pomiń b.c.d.e.f.com, ponieważ weźmiemy tylko 5 ostatnich elementów nazwy hosta i pełną nazwę hosta).

W przypadku adresu URL http://1.2.3.4/1/ klient spróbuje użyć tych ciągów znaków:

1.2.3.4/1/
1.2.3.4/

W przypadku adresu URL http://example.co.uk/1 klient spróbuje użyć tych ciągów znaków:

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

Haszowanie

Bezpieczne przeglądanie Google używa wyłącznie funkcji szyfrowania SHA256. Funkcja szyfrowania powinna być zastosowana do powyższych wyrażeń.

W zależności od okoliczności pełny 32-bajtowy skrót zostanie obcięty do 4, 8 lub 16 bajtów:

  • Gdy używasz metody hashes.search, wymagamy, aby hasze w żądaniu były obcinane do dokładnie 4 bajtów. Wysyłanie dodatkowych bajtów w tym żądaniu spowoduje naruszenie prywatności użytkownika.

  • Podczas pobierania list do bazy danych lokalnej za pomocą metody hashList.get lub metody hashLists.batchGet długość haszy wysyłanych przez serwer jest zakodowana w konwencji nazewnictwa list, które zawierają sufiks wskazujący długość hasza. Więcej informacji znajdziesz w sekcji Dostępne listy.