Migration From V4

Jedną z największych 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. Ponieważ ochrona zależy w dużej mierze od bazy danych lokalnej zarządzanej przez klienta, opóźnienie i rozmiar aktualizacji lokalnej bazy danych są głównymi czynnikami wpływu na brak ochrony. W wersji 4.0 pobranie najnowszej wersji list zagrożeń przez typowego klienta zajmuje od 20 do 50 minut. Ataki phishingowe rozprzestrzeniają się niestety 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 kasowania lokalnej bazy danych. Z tej sekcji dowiesz się, jak to zrobić.

Konwertowanie aktualizacji listy

W przeciwieństwie do wersji 4, w której listy są identyfikowane przez kolumnę typu zagrożenia, typu platformy i typu wpisu zagrożenia, w wersji 5 są one po prostu identyfikowane według nazwy. Daje to elastyczność w przypadku, 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 pierwotnego identyfikatora klienta i wersji klienta oddzielonych spacjami lub znakiem ukośnika.
  2. W przypadku każdego obiektu v4 ListUpdateRequest:
*   Look up the corresponding v5 list name from the [available
    lists](/safe-browsing/reference/Local.Database#available-lists) and
    supply that name in the v5 request.
*   Remove unneeded fields such as `threat_entry_type` or `platform_type`.
*   The `state` field in v4 is directly compatible with the v5 `versions`
    field. The same byte string that would be sent to the server using the
    `state` field in v4 can simply be sent in v5 using the `versions` field.
*   For the v4 constraints, v5 uses a simplified version called
    [`SizeConstraints`](/safe-browsing/reference/rest/v5/SizeConstraints).
    Additional fields such as `region` should be dropped.

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 mniejsze ograniczenie maksymalnego rozmiaru aktualizacji niż maksymalny rozmiar bazy danych.
  3. Algorytm dekodowania Rice’a dla 32-bitowych liczb całkowitych będzie musiał zostać dostosowany. Różnica polega na tym, że zakodowane dane są kodowane z użyciem innego endian. 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 sortowane, podczas gdy w wersji 5 są traktowane jako duże i sortowane. 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 tego typu 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 użyć metody fullHashes.find, aby uzyskać pełne wartości skrótu. Odpowiednią metodą w wersji 5 jest metoda hashes.search.

Wprowadź w prośbie te zmiany:

  1. Ustrukturyzuj kod tak, aby wysyłać tylko prefiksy skrótów o długości dokładnie 4 bajty.
  2. Usuń wszystkie obiekty 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 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.