Migration From V4

Преобразование обновлений списка

В отличие от версии 4, где списки идентифицируются по кортежу типа угрозы, типа платформы и типа записи угрозы, в версии 5 списки идентифицируются просто по имени. Это обеспечивает гибкость, когда несколько списков версии 5 могут использовать один и тот же тип угроз. Типы платформ и типы записей об угрозах удалены в версии 5.

В версии 4 для загрузки списков можно было использовать метод ThreatListUpdates.fetch . В версии v5 можно было бы переключиться на метод hashLists.batchGet .

В запрос необходимо внести следующие изменения:

1. Полностью удалите объект ClientInfo версии 4 . Вместо того, чтобы предоставлять идентификацию клиента с помощью специального поля, просто используйте известный заголовок User-Agent . Хотя не существует предписанного формата для предоставления идентификатора клиента в этом заголовке, мы предлагаем просто включать исходный идентификатор клиента и версию клиента, разделенные пробелом или косой чертой.
2. Для каждого объекта ListUpdateRequest версии 4 : * Найдите соответствующее имя списка версии 5 в таблице выше и укажите это имя в запросе версии 5.
   • Удалите ненужные поля, такие как threat_entry_type или platform_type .
   • Поле state в версии 4 напрямую совместимо с полем versions 5. Ту же строку байтов, которая будет отправлена ​​на сервер с использованием поля state в версии 4, можно просто отправить в версии 5 с использованием поля versions .
   • Для ограничений версии 4 версия 5 использует упрощенную версию под названием SizeConstraints . Дополнительные поля, такие как region , следует удалить.

В ответ необходимо внести следующие изменения:

1. ResponseType версии 4 просто заменяется логическим полем с именем partial_update .
2. Поле minimum_wait_duration теперь может быть нулевым или опущено. Если это так, клиенту предлагается немедленно сделать еще один запрос. Это происходит только тогда, когда клиент указывает в SizeConstraints меньшее ограничение на максимальный размер обновления, чем максимальный размер базы данных.
3. Алгоритм декодирования Райса для 32-битных целых чисел необходимо будет скорректировать. Разница в том, что закодированные данные кодируются с другим порядком байтов. И в версии 4, и в версии 5 32-битные хеш-префиксы сортируются лексикографически. Но в версии 4 эти префиксы при сортировке обрабатываются как с прямым порядком байтов, тогда как в версии 5 эти префиксы при сортировке обрабатываются как с прямым порядком байтов. Это означает, что клиенту не нужно выполнять какую-либо сортировку, поскольку лексикографическая сортировка идентична числовой сортировке с прямым порядком байтов. Пример такого рода в реализации Chromium v4 можно найти здесь . Такую сортировку можно убрать.
4. Алгоритм декодирования Райса необходимо будет реализовать и для других длин хеша.

Преобразование хэш-поиска

В версии 4 для получения полных хешей можно было бы использовать метод fullHashes.find . Эквивалентным методом в v5 является метод hashes.search .

В запрос необходимо внести следующие изменения:

1. Структурируйте код так, чтобы отправлять только хэш-префиксы длиной ровно 4 байта.
2. Полностью удалите объекты ClientInfo v4 . Вместо того, чтобы предоставлять идентификацию клиента с помощью специального поля, просто используйте известный заголовок User-Agent . Хотя не существует предписанного формата для предоставления идентификатора клиента в этом заголовке, мы предлагаем просто включать исходный идентификатор клиента и версию клиента, разделенные пробелом или косой чертой.
3. Удалите поле client_states . В этом больше нет необходимости.
4. Больше нет необходимости включать threat_types и подобные поля.

В ответ необходимо внести следующие изменения:

1. Поле minimum_wait_duration было удалено. Клиент всегда может отправить новый запрос по мере необходимости.
2. Объект ThreatMatch версии 4 был упрощен до объекта FullHash .
3. Кэширование было упрощено до одной продолжительности кэширования. См. описанные выше процедуры взаимодействия с кэшем.