Local Database

Bei Google Safe Browsing v5 muss der Client eine lokale Datenbank verwalten, es sei denn, er wählt den Echtzeitmodus ohne Speicher aus. Format und Speicherort dieser lokalen Datenbank liegen im Ermessen des Kunden. Der Inhalt dieser lokalen Datenbank kann als Ordner mit verschiedenen Listen als Dateien betrachtet werden. Der Inhalt dieser Dateien sind SHA256-Hashes oder die entsprechenden Präfixe. Das vier Byte lange Hash-Präfix ist die am häufigsten verwendete Hash-Länge.

Verfügbare Listen

Listen werden anhand ihrer eindeutigen Namen identifiziert, die einer Namenskonvention folgen. Der Name enthält ein Suffix, das die Länge des Hashwerts angibt, der in der Liste erwartet wird. Hash-Listen mit demselben Bedrohungstyp, aber unterschiedlicher Hash-Länge, werden in einer separat benannten Liste mit einem Suffix angegeben, das die Hash-Länge angibt.

Die folgenden Listen können mit den Hash-Listenmethoden verwendet werden.

Name der Liste Entsprechendes ThreatType-Enum der Version 4 Beschreibung
gc-32b Keine Diese Liste ist eine globale Cache-Liste. Es handelt sich um eine spezielle Liste, die nur im Echtzeitmodus verwendet wird.
se-4b SOCIAL_ENGINEERING Diese Liste enthält Bedrohungen vom Typ SOCIAL_ENGINEERING.
mw-4b MALWARE Diese Liste enthält Bedrohungen vom Typ MALWARE für Desktop-Plattformen.
uws-4b UNWANTED_SOFTWARE Diese Liste enthält Bedrohungen vom Typ UNWANTED_SOFTWARE für Desktop-Plattformen.
uwsa-4b UNWANTED_SOFTWARE Diese Liste enthält Bedrohungen vom Typ UNWANTED_SOFTWARE für Android-Plattformen.
pha-4b POTENTIALLY_HARMFUL_APPLICATION Diese Liste enthält Bedrohungen vom Typ POTENTIALLY_HARMFUL_APPLICATION für Android-Plattformen.

Weitere Listen können zu einem späteren Zeitpunkt verfügbar werden. In diesem Fall wird die obige Tabelle erweitert und die Ergebnisse der hashList.list-Methode zeigen ein ähnliches Ergebnis mit den aktuellsten Listen.

Datenbankaktualisierungen

Der Client ruft regelmäßig die Methode hashList.get oder die Methode hashLists.batchGet auf, um die Datenbank zu aktualisieren. Da der typische Kunde mehrere Listen gleichzeitig aktualisieren möchte, wird die Methode „hashLists.batchGet“ empfohlen.

Die Listennamen werden nie umbenannt. Außerdem wird eine Liste, die einmal angezeigt wurde, nie wieder entfernt. Wenn sie nicht mehr nützlich ist, wird sie leer, bleibt aber bestehen. Daher sollten diese Namen im Google Safe Browsing-Clientcode hartcodiert werden.

Sowohl die Methode „hashList.get“ als auch die Methode „hashLists.batchGet“ unterstützen inkrementelle Updates. Mit inkrementellen Updates wird Bandbreite gespart und die Leistung verbessert. Bei inkrementellen Updates wird ein Delta zwischen der Version der Liste des Clients und der neuesten Version der Liste gesendet. Wenn ein Client neu bereitgestellt wird und keine Versionen verfügbar sind, ist ein vollständiges Update verfügbar. Das inkrementelle Update enthält Indexe für Entfernungen und Ergänzungen. Der Client muss zuerst die Einträge an den angegebenen Indizes aus seiner lokalen Datenbank entfernen und dann die Ergänzungen anwenden.

Um Beschädigungen zu vermeiden, sollte der Client die gespeicherten Daten schließlich mit der vom Server bereitgestellten Prüfsumme vergleichen. Wenn die Prüfsumme nicht übereinstimmt, sollte der Client eine vollständige Aktualisierung durchführen.

Listeninhalte decodieren

Hashes und Hash-Präfixe decodieren

Alle Listen werden mit einer speziellen Codierung gesendet, um die Größe zu reduzieren. Bei dieser Codierung wird erkannt, dass Google Safe Browsing-Listen konzeptionell eine Reihe von Hashes oder Hash-Präfixen enthalten, die statistisch nicht von zufälligen Ganzzahlen zu unterscheiden sind. Wenn wir diese ganzen Zahlen sortieren und den Differenzbetrag zwischen benachbarten Zahlen ermitteln, sollte dieser Differenzbetrag in gewissem Sinne „klein“ sein. Die Golomb-Rice-Codierung nutzt diese Kleinheit dann aus.

Angenommen, drei Host-Suffix-Pfadpräfixausdrücke, nämlich a.example.com/, b.example.com/ und y.example.com/, sollen mit 4‑Byte-Hash-Präfixen übertragen werden. Angenommen, der Rice-Parameter, der mit k bezeichnet wird, hat den Wert

  1. Der Server berechnet zuerst den vollständigen Hash für diese Strings:
291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc  a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c  b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03  y.example.com/

Der Server bildet dann für jedes der oben genannten Elemente 4-Byte-Hash-Präfixe. Das sind die ersten 4 Byte des 32-Byte-vollständigen Hashwerts, die als Big-Endian-32-Bit-Ganzzahlen interpretiert werden. Big-Endian-Format bezieht sich darauf, dass das erste Byte des vollständigen Hashes zum höchstwertigen Byte der 32‑Bit-Ganzzahl wird. Dieser Schritt führt zu den Ganzzahlen 0x291bc542, 0x1d32c508 und 0xf7a502e5.

Der Server muss diese drei Hash-Präfixe lexikalisch sortieren (entspricht der numerischen Sortierung in Big-Endian-Format). Das Ergebnis der Sortierung ist 0x1d32c508, 0x291bc542 und 0xf7a502e5. Das erste Hash-Präfix wird unverändert im Feld first_value gespeichert.

Der Server berechnet dann die beiden benachbarten Unterschiede, also 0xbe9003a und 0xce893da3. Da k = 30 ist, teilt der Server diese beiden Zahlen in Quotienten- und Restteile auf, die jeweils 2 und 30 Bit lang sind. Bei der ersten Zahl ist der Quotiententeil null und der Rest ist 0xbe9003a. Bei der zweiten Zahl ist der Quotiententeil 3, da die beiden höchstwertigen Bits im Binärformat 11 sind, und der Rest ist 0xe893da3. Bei einem bestimmten Quotienten q wird er mit genau 1 + q Bits in (1 << q) - 1 codiert. Der Rest wird direkt mit k Bits codiert. Der Quotiententeil der ersten Zahl ist als 0 codiert und der Restteil als Binärzahl 001011111010010000000000111010; der Quotiententeil der zweiten Zahl ist als 0111 codiert und der Restteil als 001110100010010011110110100011.

Wenn diese Zahlen zu einem Byte-String kombiniert werden, wird Little Endian verwendet. Es ist konzeptionell einfacher, sich einen langen Bitstring vorzustellen, der mit den niedrigstwertigen Bits beginnt: Wir nehmen den Quotiententeil der ersten Zahl und fügen den Restteil der ersten Zahl voran. Dann fügen wir den Quotiententeil der zweiten Zahl und den Restteil voran. Dies sollte zu der folgenden großen Zahl führen (Zeilentrennzeichen und Kommentare zur Verdeutlichung hinzugefügt):

001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part

In einer Zeile würde das so aussehen:

00111010001001001111011010001101110010111110100100000000001110100

Diese Zahl übersteigt natürlich die 8 Bits, die in einem einzelnen Byte verfügbar sind. Bei der Little-Endian-Codierung werden dann die acht niedrigstwertigen Bits dieser Zahl als erstes Byte ausgegeben, also 01110100. Zur Verdeutlichung können wir den obigen Bitstring in Gruppen zu acht Bits gruppieren, beginnend mit den niedrigstwertigen Bits:

0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100

Bei der Little-Endian-Codierung wird dann jedes Byte von rechts in einen Bytestring eingefügt:

01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000

Da wir neue Teile konzeptionell voranstellen (d.h. mehr signifikante Bits hinzufügen), aber von rechts (d.h. von den weniger signifikanten Bits) codieren, können Codierung und Dekodierung inkrementell erfolgen.

Das führt letztendlich zu

additions_four_bytes {
  first_value: 489866504
  rice_parameter: 30
  entries_count: 2
  encoded_data: "t\000\322\227\033\355It\000"
}

Der Client führt einfach die oben beschriebenen Schritte in umgekehrter Reihenfolge aus, um die Hash-Präfixe zu decodieren.

Dekodierungsindexe für Entfernungen

Entfernungsindexe werden mit derselben Methode wie oben mit 32-Bit-Ganzzahlen codiert.

Aktualisierungshäufigkeit

Der Client sollte den vom Server zurückgegebenen Wert im Feld minimum_wait_duration prüfen und anhand dieses Werts die nächste Aktualisierung der Datenbank planen. Dieser Wert ist möglicherweise null (das Feld minimum_wait_duration fehlt vollständig). In diesem Fall MUSS der Client sofort eine weitere Aktualisierung ausführen.