URLs and Hashing

Questa sezione contiene le specifiche dettagliate su come i client controllano gli URL.

Canonizzazione degli URL

Prima che gli URL vengano controllati, il client deve eseguire una certa canonicalizzazione sull'URL.

Per iniziare, assumiamo che il client abbia analizzato l'URL e lo abbia reso valido in base a RFC 2396. Se l'URL utilizza un nome di dominio internazionalizzato (IDN), il client deve convertirlo nella rappresentazione ASCII Punycode. L'URL deve includere un componente del percorso, ovvero deve avere almeno una barra dopo il dominio (http://google.com/ anziché http://google.com).

Innanzitutto, rimuovi i caratteri tabulazione (0x09), CR (0x0d) e LF (0x0a) dall'URL. Non rimuovere le sequenze di escape per questi caratteri (ad es. %0a).

In secondo luogo, se l'URL termina con un frammento, rimuovilo. Ad esempio, abbrevia http://google.com/#frag in http://google.com/.

In terzo luogo, rimuovi ripetutamente l'escape percentuale dall'URL finché non sono presenti più escape percentuali. (L'URL potrebbe risultare non valido).

Per eseguire la standardizzazione del nome host:

Estrai il nome host dall'URL e poi:

  1. Rimuovi tutti i punti iniziali e finali.
  2. Sostituisci i punti consecutivi con un solo punto.
  3. Se il nome host può essere analizzato come indirizzo IPv4, normalizzalo in 4 valori decimali separati da punti. Il client deve gestire qualsiasi codifica dell'indirizzo IP valida, inclusi ottali, esadecimali e meno di quattro componenti.
  4. Se il nome host può essere analizzato come indirizzo IPv6 tra parentesi, normalizzalo rimuovendo gli zeri iniziali non necessari nei componenti e comprimendo i componenti zero utilizzando la sintassi dei due punti. Ad esempio, [2001:0db8:0000::1] deve essere trasformato in [2001:db8::1]. Se il nome host è uno dei due seguenti tipi di indirizzi IPv6 speciali, trasformalo in IPv4:
    • Un indirizzo IPv6 mappato su IPv4, ad esempio [::ffff:1.2.3.4], che deve essere trasformato in 1.2.3.4.
    • Un indirizzo NAT64 che utilizza il prefisso noto 64:ff9b::/96, ad esempio [64:ff9b::1.2.3.4], che deve essere trasformato in 1.2.3.4.
  5. Scrivi tutta la stringa in minuscolo.

Per eseguire la canonizzazione del percorso:

  1. Risolvi le sequenze /../ e /./ nel percorso sostituendo /./ con / e rimuovendo /../ insieme al componente del percorso precedente.
  2. Sostituisci le serie di barre consecutive con un singolo carattere barra.

Non applicare queste canonizzazioni dei percorsi ai parametri di query.

Nell'URL, inserisci un codice di escape per tutti i caratteri <= ASCII 32, >= 127, # o %. Gli escape devono utilizzare caratteri esadecimali maiuscoli.

Espressioni di prefisso percorso con suffisso host

Una volta canonizzato l'URL, il passaggio successivo consiste nel creare le espressioni di suffisso/prefisso. Ogni espressione di suffisso/prefisso è composta da un suffisso host (o host completo) e da un prefisso percorso (o percorso completo).

Il client formerà fino a 30 possibili combinazioni di suffisso host e prefisso percorso. Queste combinazioni utilizzano solo i componenti host e path dell'URL. Lo schema, il nome utente, la password e la porta vengono ignorati. Se l'URL include parametri di query, almeno una combinazione includerà il percorso completo e i parametri di query.

Per l'host, il client proverà al massimo cinque stringhe diverse. Sono:

  • Se il nome host non è un valore letterale IPv4 o IPv6, fino a quattro nomi host formati iniziando con il dominio eTLD+1 e aggiungendo componenti iniziali successivi. La determinazione di eTLD+1 deve essere basata sull'elenco dei suffissi pubblici. Ad esempio, a.b.example.com restituirà il dominio eTLD+1 di example.com, nonché l'host con un componente host aggiuntivo b.example.com.
  • Il nome host esatto nell'URL. Seguendo l'esempio precedente, verrà selezionato a.b.example.com.

Per il percorso, il client proverà al massimo sei stringhe diverse. Sono:

  • Il percorso esatto dell'URL, inclusi i parametri di query.
  • Il percorso esatto dell'URL, senza parametri di query.
  • I quattro percorsi formati iniziando dalla radice (/) e aggiungendo successivamente i componenti del percorso, inclusa una barra finale.

Gli esempi riportati di seguito illustrano il comportamento del controllo:

Per l'URL http://a.b.com/1/2.html?param=1, il client proverà queste possibili stringhe:

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/

Per l'URL http://a.b.c.d.e.f.com/1.html, il client proverà queste possibili stringhe:

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/

(Nota: salta b.c.d.e.f.com, poiché prenderemo solo gli ultimi cinque componenti del nome host e il nome host completo.)

Per l'URL http://1.2.3.4/1/, il client proverà queste possibili stringhe:

1.2.3.4/1/
1.2.3.4/

Per l'URL http://example.co.uk/1, il client proverà queste possibili stringhe:

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

Hashing

Google Navigazione sicura utilizza esclusivamente SHA256 come funzione di hash. Questa funzione hash deve essere applicata alle espressioni precedenti.

L'hash completo di 32 byte verrà troncato a 4, 8 o 16 byte, a seconda delle circostanze:

  • Quando utilizzi il metodo hashes.search, al momento è necessario che gli hash nella richiesta vengano troncati a esattamente 4 byte. L'invio di altri byte in questa richiesta comprometterà la privacy dell'utente.

  • Quando scarichi gli elenchi per il database locale utilizzando il metodo hashList.get o il metodo hashLists.batchGet, la lunghezza degli hash inviati dal server è codificata nella convenzione di denominazione degli elenchi che contengono il suffisso che indica la lunghezza dell'hash. Per ulteriori dettagli, consulta la sezione Elenchi disponibili.