Migration From V4

Un miglioramento significativo della versione 5 di Google Navigazione sicura rispetto alla versione 4 (in particolare, l'API Update v4) è l'aggiornamento e la copertura dei dati. Poiché la protezione dipende molto dal database locale gestito dal cliente, il ritardo e le dimensioni dell'aggiornamento del database locale sono i fattori principali che contribuiscono alla mancata protezione. Nella versione 4, il client tipico impiega da 20 a 50 minuti per ottenere la versione più aggiornata degli elenchi di minacce. Purtroppo, gli attacchi di phishing si diffondono rapidamente: a partire dal 2021, il 60% dei siti che lanciano attacchi è attivo per meno di 10 minuti. La nostra analisi mostra che circa il 25-30% della protezione da phishing mancante è dovuto all'obsolescenza di questi dati. Inoltre, alcuni dispositivi non sono equipaggiati per gestire l'intera gamma di elenchi di minacce di Navigazione sicura di Google, che continuano ad aumentare nel tempo.

Se al momento utilizzi l'API Update 4, esiste un percorso di migrazione senza problemi dalla versione 4 alla versione 5 senza dover reimpostare o cancellare il database locale. Questa sezione illustra come eseguire questa operazione.

Aggiornamento degli elenchi di conversione

A differenza della versione 4, in cui gli elenchi sono identificati dalla tupla di tipo di minaccia, tipo di piattaforma, tipo di voce di minaccia, nella versione 5 gli elenchi sono identificati semplicemente per nome. Ciò offre flessibilità quando più elenchi della versione 5 potrebbero condividere lo stesso tipo di minaccia. I tipi di piattaforme e i tipi di voci di minaccia vengono rimossi nella versione 5.

Nella versione 4, si utilizza il metodo threatListUpdates.fetch per scaricare gli elenchi. Nella versione 5, si passa al metodo hashLists.batchGet.

È necessario apportare le seguenti modifiche alla richiesta:

  1. Rimuovi del tutto l'oggetto ClientInfo v4. Anziché fornire l'identificazione di un client utilizzando un campo dedicato, utilizza semplicemente la nota intestazione User-Agent. Sebbene non sia prescritto un formato per fornire l'identificazione del client in questa intestazione, ti consigliamo di includere semplicemente l'ID client e la versione client originali separati da uno spazio o da un carattere barra.
  2. Per ogni oggetto ListUpdateRequest v4: * Cerca il nome dell'elenco v5 corrispondente nella tabella sopra e forniscilo nella richiesta v5.
    • Rimuovi i campi non necessari, ad esempio threat_entry_type o platform_type.
    • Il campo state nella versione 4 è direttamente compatibile con il campo versions nella versione 5. La stessa stringa di byte che verrebbe inviata al server utilizzando il campo state nella versione 4 può essere semplicemente inviata nella versione 5 utilizzando il campo versions.
    • Per i vincoli della versione 4, la versione 5 utilizza una versione semplificata chiamata SizeConstraints. I campi aggiuntivi come region devono essere eliminati.

Alla risposta devono essere apportate le seguenti modifiche:

  1. L'enum ResponseType della versione 4 viene semplicemente sostituito da un campo booleano denominato partial_update.
  2. Ora il campo minimum_wait_duration può essere zero o omesso. In questo caso, al cliente viene chiesto di inviare immediatamente un'altra richiesta. Ciò accade solo quando il client specifica in SizeConstraints un vincolo sulle dimensioni massime dell'aggiornamento inferiore alle dimensioni massime del database.
  3. L'algoritmo di decodifica di Rice per gli interi a 32 bit dovrà essere modificato. La differenza è che i dati codificati sono codificati con un endianness diverso. Sia nella versione 4 che nella versione 5, i prefissi degli hash a 32 bit sono ordinati in ordine alfabetico. Tuttavia, nella versione 4 questi prefissi vengono trattati come little endian quando sono ordinati, mentre nella versione 5 vengono trattati come big endian. Ciò significa che il client non deve eseguire alcun ordinamento, poiché l'ordinamento lessicografico è identico all'ordinamento numerico con big endian. Un esempio di questo tipo nell'implementazione di Chromium della versione 4 è disponibile qui. Questo tipo di ordinamento può essere rimosso.
  4. L'algoritmo di decodifica di Rice dovrà essere implementato anche per altre lunghezze dell'hash.

Conversione delle ricerche di hash

Nella versione 4, è possibile utilizzare il metodo fullHashes.find per ottenere gli hash completi. Il metodo equivalente nella versione 5 è il metodo hashes.search.

È necessario apportare le seguenti modifiche alla richiesta:

  1. Struttura il codice in modo da inviare solo prefissi di hash di esattamente 4 byte di lunghezza.
  2. Rimuovi del tutto gli oggetti ClientInfo v4. Anziché fornire l'identificazione di un client utilizzando un campo dedicato, utilizza semplicemente la nota intestazione User-Agent. Sebbene non sia prescritto un formato per fornire l'identificazione del client in questa intestazione, ti consigliamo di includere semplicemente l'ID client e la versione client originali separati da uno spazio o da un carattere barra.
  3. Rimuovi il campo client_states. Non è più necessario.
  4. Non è più necessario includere threat_types e campi simili.

Alla risposta devono essere apportate le seguenti modifiche:

  1. Il campo minimum_wait_duration è stato rimosso. Il cliente può sempre emettere una nuova richiesta in base alle esigenze.
  2. L'oggetto ThreatMatch v4 è stato semplificato nell'oggetto FullHash.
  3. La memorizzazione nella cache è stata semplificata in una singola durata della cache. Consulta le procedure riportate sopra per interagire con la cache.