Migration From V4

Jednym z najważniejszych ulepszeń Bezpiecznego przeglądania Google w wersji 5 w porównaniu z wersją 4 (a konkretnie interfejsem Update API w wersji 4) jest aktualność i zakres danych. Ponieważ ochrona w dużej mierze zależy od lokalnej bazy danych utrzymywanej przez klienta, opóźnienie i rozmiar aktualizacji lokalnej bazy danych są głównymi czynnikami wpływającymi na brak ochrony. W wersji 4 typowy klient potrzebuje od 20 do 50 minut, aby uzyskać najnowszą wersję list zagrożeń. Niestety ataki phishingowe szybko się rozprzestrzeniają: w 2021 r. 60% witryn, które przeprowadzają ataki, działało krócej niż 10 minut. Z naszych analiz wynika, że około 25–30% brakującej ochrony przed phishingiem wynika z nieaktualności danych. Niektóre urządzenia nie są też przystosowane do zarządzania wszystkimi listami zagrożeń Bezpiecznego przeglądania Google, które z czasem stają się coraz większe.

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 ani usuwania lokalnej bazy danych. W tej sekcji znajdziesz instrukcje, jak to zrobić.

Aktualizacje list konwersji

W przeciwieństwie do wersji 4, w której listy są identyfikowane przez krotkę typu zagrożenia, typu platformy i typu wpisu zagrożenia, w wersji 5 listy są identyfikowane po prostu przez nazwę. Zapewnia to elastyczność, gdy wiele list w wersji 5 może mieć ten sam typ zagrożenia. W wersji 5 usunęliśmy typy platform i rodzaje zagrożeń.

W wersji 4 do pobierania list używa się metody threatListUpdates.fetch. W wersji 5 przełącza się na metodę hashLists.batchGet.

W żądaniu należy wprowadzić te zmiany:

  1. Całkowicie usuń obiekt ClientInfo v4. Zamiast podawać identyfikator klienta w odpowiednim polu, użyj znanego nagłówka User-Agent. Nie ma określonego formatu podawania identyfikatora klienta w tym nagłówku, ale sugerujemy po prostu podanie oryginalnego identyfikatora klienta i wersji klienta oddzielonych spacją lub ukośnikiem.
  2. Dla każdego obiektu ListUpdateRequest w wersji 4:
    • Znajdź odpowiednią nazwę listy w wersji 5 na liście dostępnych list i podaj ją w żądaniu w wersji 5.
    • 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 byłby wysyłany na serwer w polu state w wersji 4, można po prostu wysłać w wersji 5 w polu versions.
    • W przypadku ograniczeń w wersji 4 w wersji 5 używana jest uproszczona wersja o nazwie SizeConstraints. Dodatkowe pola, takie jak region, powinny zostać pominięte.

W odpowiedzi należy wprowadzić te zmiany:

  1. Wersja 4 wyliczenia ResponseType jest po prostu zastępowana polem logicznym o nazwie partial_update.
  2. Pole minimum_wait_duration może teraz mieć wartość zero lub zostać pominięte. Jeśli tak jest, klient jest proszony o natychmiastowe przesłanie kolejnego żądania. Dzieje się tak tylko wtedy, gdy klient określi w SizeConstraints mniejsze ograniczenie maksymalnego rozmiaru aktualizacji niż maksymalny rozmiar bazy danych.
  3. Algorytm dekodowania Rice dla 32-bitowych liczb całkowitych będzie wymagał dostosowania. Różnica polega na tym, że zakodowane dane są zakodowane z inną kolejnością bajtów. Zarówno w wersji 4, jak i w wersji 5 32-bitowe prefiksy skrótu są sortowane leksykograficznie. W wersji 4 te prefiksy są traktowane jako little endian podczas sortowania, a w wersji 5 – jako big endian. Oznacza to, że klient nie musi niczego sortować, ponieważ sortowanie leksykograficzne jest identyczne z sortowaniem numerycznym w formacie big endian. Przykład takiego kodu w implementacji v4 w Chromium znajdziesz tutaj. Takie sortowanie można usunąć.
  4. Algorytm dekodowania Rice’a będzie musiał być zaimplementowany również w przypadku innych długości skrótu.

Konwertowanie wyszukiwań haszów

W wersji 4 do pobierania pełnych skrótów używa się metody fullHashes.find. Odpowiednikiem tej metody w wersji 5 jest metoda hashes.search.

W żądaniu należy wprowadzić te zmiany:

  1. Skonstruuj kod tak, aby wysyłać tylko prefiksy skrótu o długości dokładnie 4 bajtów.
  2. Całkowicie usuń obiekty ClientInfowersji 4. Zamiast podawać identyfikator klienta w odpowiednim polu, użyj znanego nagłówka User-Agent. Nie ma określonego formatu podawania identyfikatora klienta w tym nagłówku, ale sugerujemy po prostu podanie oryginalnego identyfikatora klienta i wersji klienta oddzielonych spacją lub ukośnikiem.
  3. Usuń pole client_states. Nie jest już potrzebny.
  4. Nie musisz już uwzględniać pola threat_types ani podobnych pól.

W odpowiedzi należy wprowadzić te zmiany:

  1. Pole minimum_wait_duration zostało usunięte. Klient może w razie potrzeby zawsze wysłać nowe żądanie.
  2. Obiekt v4 ThreatMatch został uproszczony do obiektu FullHash.
  3. Buforowanie zostało uproszczone do jednego czasu trwania pamięci podręcznej. Aby dowiedzieć się, jak korzystać z pamięci podręcznej, zapoznaj się z procedurami opisanymi powyżej.