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

Aktualizacje list konwertujących

W przeciwieństwie do wersji 4, w której listy są identyfikowane przez krotkę typu zagrożenia, typu platformy i typu wpisu o zagrożeniu, 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 usunięto typy platform i typy 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: * wyszukaj 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, należy pominąć.

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. Logika dekodowania skrótów zakodowanych za pomocą algorytmu Rice-Golomb wymaga 2 głównych zmian:
    • Kolejność bajtów i sortowanie: w wersji 4 zwracane hasze były sortowane jako wartości little-endian. W wersji 5 są one traktowane jako wartości big-endian. Sortowanie leksykograficzne ciągów bajtów jest równoważne sortowaniu numerycznemu wartości big-endian, więc klienci nie muszą już wykonywać specjalnego kroku sortowania. Niestandardowe sortowanie little-endian, takie jak w implementacji Chromium w wersji 4, można usunąć, jeśli zostało wcześniej wdrożone.
    • Zmienne długości skrótu: algorytm dekodowania musi zostać zaktualizowany, aby obsługiwać różne długości skrótu, które mogą być zwracane w polu HashList.compressed_additions, a nie tylko 4-bajtową długość skrótu używaną w wersji 4. Długość skrótów zwracanych w odpowiedzi można określić na podstawie wartości HashList.metadata.hash_length zwróconej przez hashLists.list. Nazwa żądanej listy skrótów wskazuje też oczekiwane rozmiary skrótów zwracanych przez listę. Więcej informacji o listach skrótów znajdziesz na stronie Lokalna baza danych.

Wyszukiwania z haszem prowadzące do konwersji

W wersji 4 do uzyskania 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 powyżej.