Migration From V4

Jedną z najważniejszych zmian w Google Bezpieczne przeglądanie w wersji 5 w porównaniu z wersją 4 (w szczególności w interfejsie Update API w wersji 4) jest aktualność i zasięg danych. Ochrona zależy w dużej mierze od bazy danych lokalnej zarządzanej przez klienta, dlatego opóźnienie i rozmiar aktualizacji bazy danych lokalnej są głównymi czynnikami wpływu na brak ochrony. W wersji 4.0 pobranie najnowszej wersji list zagrożeń zajmuje klientowi zwykle od 20 do 50 minut. Ataki phishingowe rozprzestrzeniają się bardzo szybko: w 2021 r. 60% witryn, które przeprowadzają ataki, działało krócej niż 10 minut. Nasze analizy wskazują, że około 25–30% przypadków braku ochrony przed phishingiem wynika z nieaktualności danych. Ponadto niektóre urządzenia nie są w stanie zarządzać wszystkimi listami zagrożeń Bezpiecznego przeglądania Google, które z czasem się powiększają.

Jeśli obecnie używasz interfejsu Update API w wersji 4, możesz bezproblemowo przejść z wersji 4 na wersję 5 bez konieczności resetowania lub usuwania lokalnej bazy danych. W tej sekcji znajdziesz instrukcje, jak to zrobić.

Konwertowanie aktualizacji listy

W przeciwieństwie do wersji 4, w której listy są identyfikowane przez kolumnę typu zagrożenia, typ platformy, typ wpisu zagrożenia, w wersji 5 listy są identyfikowane po prostu po nazwie. Daje to elastyczność, gdy wiele list w wersji 5 może mieć ten sam typ zagrożenia. W wersji 5 usunięto typy platform i typy wpisów o zagrożeniach.

W wersji 4 do pobierania list używa się metody threatListUpdates.fetch. W wersji 5 należy przejść na metodę hashLists.batchGet.

Wprowadź w prośbie te zmiany:

  1. Usuń całkowicie obiekt v4 ClientInfo. Zamiast podawać identyfikator klienta w specjalnym polu, użyj dobrze znanego nagłówka User-Agent. Nie ma określonego formatu identyfikacji klienta w tym nagłówku, ale zalecamy podanie oryginalnego identyfikatora klienta i wersji klienta oddzielonych spacjami lub znakiem ukośnika.
  2. W przypadku każdego obiektu v4 ListUpdateRequest: * w tabeli powyżej odszukaj odpowiednią nazwę listy v5 i podaj ją w żądaniu v5.
    • Usuń niepotrzebne pola, takie jak threat_entry_type lub platform_type.
    • Pole state w wersji 4 jest bezpośrednio zgodne z polem versions w wersji 5. Ten sam ciąg bajtów, który w wersji 4 zostałby wysłany na serwer za pomocą pola state, można po prostu wysłać w wersji 5 za pomocą pola versions.
    • W przypadku ograniczeń wersji 4 wersja 5 używa uproszczonej wersji o nazwie SizeConstraints. Dodatkowe pola, takie jak region, powinny zostać pominięte.

W odpowiedzi należy wprowadzić te zmiany:

  1. W wersji 4 enum ResponseType jest po prostu zastąpione polem logicznym o nazwie partial_update.
  2. Pole minimum_wait_duration może teraz mieć wartość zero lub może zostać pominięte. W takim przypadku klient musi natychmiast przesłać nowe zgłoszenie. Dzieje się tak tylko wtedy, gdy klient w sekcji SizeConstraints podaje mniejszy limit maksymalnego rozmiaru aktualizacji niż maksymalny rozmiar bazy danych.
  3. Należy dostosować algorytm dekodowania Rice’a w przypadku 32-bitowych liczb całkowitych. Różnica polega na tym, że zakodowane dane są kodowane z inną kolejnością bajtów. Zarówno w wersji 4, jak i 5 prefiksy 32-bitowych haszy są sortowane alfabetycznie. Jednak w wersji 4 te prefiksy są traktowane jako małe i uporządkowane, podczas gdy w wersji 5 są traktowane jako duże i uporządkowane. Oznacza to, że klient nie musi sortować danych, ponieważ sortowanie leksykograficzne jest identyczne z sortowaniem numerycznym z dużym porządkiem bajtów. Przykład takiego rozwiązania w implementacji Chromium w wersji 4 znajdziesz tutaj. Takie sortowanie można usunąć.
  4. Algorytm dekodowania Rice będzie musiał być zaimplementowany również w przypadku innych długości hasha.

Konwertowanie wyszukiwań z haszowaniem

W wersji 4.0 można było uzyskać pełne hasze za pomocą metody fullHashes.find. Odpowiednią metodą w wersji 5 jest metoda hashes.search.

Wprowadź w prośbie te zmiany:

  1. Zadbaj o to, aby kod wysyłał tylko prefiksy skrótów, które mają dokładnie 4 bajty długości.
  2. Usuń wszystkie obiekty ClientInfo w wersji 4. Zamiast podawania identyfikatora klienta za pomocą specjalnego pola, użyj dobrze znanego nagłówka User-Agent. Nie ma określonego formatu identyfikacji klienta w tym nagłówku, ale zalecamy podanie pierwotnego identyfikatora klienta i wersji klienta oddzielonych spacjami lub znakiem ukośnika.
  3. Usuń pole client_states. Nie jest już potrzebne.
  4. Nie musisz już uwzględniać pól threat_types ani podobnych.

W odpowiedzi należy wprowadzić te zmiany:

  1. Pole minimum_wait_duration zostało usunięte. Klient może w każdej chwili przesłać nowe żądanie w razie potrzeby.
  2. Obiekt v4 ThreatMatch został uproszczony do obiektu FullHash.
  3. Zoptymalizowaliśmy buforowanie, upraszczając je do jednego czasu trwania. Aby dowiedzieć się, jak korzystać z pamięci podręcznej, zapoznaj się z powyższymi procedurami.