Memorizzazione nella cache

Questo documento si applica ai seguenti metodi:

• API Lookup: uris.search
• API Update: hashes.search

Informazioni sulla memorizzazione nella cache

Per ridurre l'utilizzo della larghezza di banda del client e per proteggere Google dagli picchi di traffico, i client sia dell'API Lookup sia dell'API Update devono creare e manutenere una cache locale dei dati sulle minacce. L'API Lookup utilizza la cache per ridurre il numero di richieste uris.search inviate dai client a Google. Per l'API Update, la cache viene utilizzata per ridurre il numero di richiestehashes.search inviate dai client a Google. Il protocollo di memorizzazione nella cache per ogni API è descritto di seguito.

API Lookup

I client dell'API Lookup devono memorizzare nella cache ogni elemento ThreatUrl restituito fino all'ora definita nel campo expireTime. I client devono quindi consultare la cache prima di effettuare una successiva richiesta uris.search al server. Se la voce della cache per un ThreatUrl restituito in precedenza non è ancora scaduta, il cliente deve presumere che l'elemento non sia ancora sicuro. La memorizzazione nella cache degli elementi ThreatUrl potrebbe ridurre il numero di richieste API effettuate dal client.

Aggiorna l'API

Per ridurre il numero complessivo di richieste hashes.search inviate a Google utilizzando l'API Update, i client devono gestire una cache locale. L'API stabilisce due tipi di memorizzazione nella cache, positiva e negativa.

Memorizzazione nella cache positiva

Per impedire ai client di chiedere ripetutamente informazioni sullo stato di un determinato hash completo non sicuro, ogni ThreatHash restituito contiene un tempo di cache positivo (definito dal campo expireTime). L'hash completo può essere considerato non sicuro fino a questo momento.

Memorizzazione nella cache negativa

Per impedire ai client di chiedere ripetutamente informazioni sullo stato di un determinato hash completo sicuro, la risposta definisce una durata della cache negativa per il prefisso richiesto (definito dal campo negativeExpireTime). Fino a questo momento, tutti gli hash completi con il prefisso richiesto devono essere considerati sicuri per i tipi di minacce richiesti, tranne quelli restituiti dal server come non sicuri. Questa memorizzazione nella cache è particolarmente importante perché impedisce il sovraccarico del traffico che potrebbe essere causato da una collisione del prefisso hash con un URL sicuro che riceve molto traffico.

Consultare la cache

Quando il client vuole controllare lo stato di un URL, calcola innanzitutto il suo hash completo. Se il prefisso dell'hash completo è presente nel database locale, il client deve consultare la cache prima di effettuare una richiesta hashes.search al server.

Innanzitutto, i client devono verificare la presenza di un successo della cache positivo. Se esiste una voce della cache positiva non scaduta per l'hash completo di interesse, deve essere considerata non sicura. Se la voce della cache positiva è scaduta, il client deve inviare una richiesta hashes.search per il prefisso locale associato. Secondo il protocollo, se il server restituisce l'hash completo, è considerato non sicuro; in caso contrario, è considerato sicuro.

Se non sono presenti voci della cache positive per l'hash completo, il client deve verificare la presenza di un successo della cache negativo. Se esiste una voce della cache negativa non scaduta per il prefisso locale associato, l'hash completo è considerato sicuro. Se la voce della cache negativa è scaduta o non esiste, il client deve inviare una richiesta hashes.search per il prefisso locale associato e interpretare la risposta normalmente.

Aggiornamento della cache

La cache del client deve essere aggiornata ogni volta che viene ricevuta una risposta hashes.search. Deve essere creata o aggiornata una voce della cache positiva per l'hash completo in base al campo expireTime. Anche la durata della cache negativa del prefisso hash deve essere creata o aggiornata in base al campo negativeExpireTime della risposta.

Se una richiesta hashes.search successiva non restituisce un hash completo attualmente memorizzato nella cache in modo positivo, il client non è tenuto a rimuovere la voce della cache positiva. In pratica, non c'è da preoccuparsi, poiché le durate positive della cache sono in genere brevi (pochi minuti) per consentire una rapida correzione dei falsi positivi.

Scenario di esempio

Nell'esempio seguente, supponiamo che h(url) sia il prefisso dell'hash dell'URL e H(url) sia l'hash completo dell'URL. In altre parole, h(url) = SHA256(url).substr(4), H(url) = SHA256(url).

Supponiamo che un client con una cache vuota visiti example.com/ e veda che h(example.com/) è nel database locale. Il client richiede gli hash di lunghezza intera per il prefisso hash h(example.com/) e riceve l'hash di lunghezza intera H(example.com/) insieme a una scadenza della cache positiva di 5 minuti da adesso e una scadenza della cache negativa di 1 ora da adesso.

La durata positiva della cache di 5 minuti indica al client per quanto tempo l'hash completo H(example.com/) deve essere considerato non sicuro senza inviare un'altra richiesta hashes.search. Dopo 5 minuti, il cliente deve emettere un'altra richiestahashes.search per il prefisso h(example.com/) se visita di nuovo example.com/. Il client deve reimpostare la data e l'ora di scadenza della cache negativa del prefisso hash in base alla nuova risposta.

La durata della cache negativa di 1 ora indica al client per quanto tempo tutti gli altri hash completi oltre a H(example.com/) che condividono lo stesso prefisso di h(example.com/) devono essere considerati sicuri. Per la durata di un'ora, ogni URL deve essere considerato sicuro, in quanto h(URL) = h(example.com/), pertanto non deve generare una richiesta hashes.search (supponendo che H(URL) ≠ H(example.com/)).

Se la risposta fullHashes non contiene corrispondenze e è impostato un tempo di scadenza della cache negativo, il client non deve inviare richieste hashes.search per nessuno dei prefissi richiesti per il tempo di cache negativo specificato.

Se la risposta hashes.search contiene una o più corrispondenze, viene comunque impostato un valore di scadenza della cache negativo per l'intera risposta. In questo caso, la data di scadenza della cache di un singolo hash completo indica per quanto tempo il client deve presumere che il particolare hash completo non sia sicuro. Una volta trascorsa la durata della cache ThreatHash, il client deve aggiornare l'hash completo inviando una richiesta hashes.search per il prefisso dell'hash se l'URL richiesto corrisponde all'hash completo esistente nella cache. In questo caso, la durata della cache negativa non si applica. La durata della cache negativa della risposta si applica solo agli hash completi che non erano presenti nella risposta hashes.search. Per gli hash completi non presenti nella risposta, il client deve astenersi dall'emettere richieste hashes.search fino al termine della durata della cache negativa.