与第 4 版（尤其是 第 4 版 Update API）相比，Google 安全浏览第 5 版的一项重大改进是数据的新鲜度和覆盖面。由于保护高度依赖于客户端维护的本地数据库，因此本地数据库更新的延迟和大小是导致保护缺失的主要原因。在 v4 中，典型客户端需要 20 到 50 分钟才能获取最新版本的威胁列表。遗憾的是，钓鱼式攻击的传播速度很快：截至 2021 年，60% 的攻击网站的存活时间不到 10 分钟。我们的分析表明，大约 25-30% 的钓鱼式攻击防护缺失是由于此类数据过时造成的。此外，某些设备无法管理 Google 安全浏览威胁列表的全部内容，而该列表会随着时间的推移而不断扩大。
如果您目前使用的是 v4 Update API，则可以从 v4 无缝迁移到 v5，而无需重置或清除本地数据库。本部分介绍了如何执行此操作。
转换列表更新
与 V4 不同的是，V4 中的列表是通过威胁类型、平台类型、威胁条目类型的元组来标识的，而 V5 中的列表仅通过名称来标识。这样一来，当多个 v5 列表可能共享同一威胁类型时，便可灵活应对。在 v5 中，平台类型和威胁条目类型已被移除。
在 v4 中，可以使用 threatListUpdates.fetch 方法下载列表。在 v5 中，用户可以改用 hashLists.batchGet 方法。
应针对请求进行以下更改：
- 完全移除 v4
ClientInfo对象。您只需使用众所周知的 User-Agent 标头，即可提供客户的身份信息，而无需使用专用字段。虽然此标头中没有规定提供客户端标识的格式，但我们建议您仅包含原始客户端 ID 和客户端版本，并用空格字符或斜杠字符分隔。 - 对于每个 v4
ListUpdateRequest对象：- 从可用列表中查找相应的 v5 列表名称，并在 v5 请求中提供该名称。
- 移除不需要的字段，例如
threat_entry_type或platform_type。 - v4 中的
state字段与 v5 中的versions字段直接兼容。使用 v4 中的state字段发送到服务器的相同字节字符串只需使用 v5 中的versions字段即可发送。 - 对于 v4 限制，v5 使用了一个简化版本，称为
SizeConstraints。应舍弃region等其他字段。
应在回答中进行以下更改：
- v4 枚举
ResponseType已被一个名为partial_update的布尔值字段取代。 minimum_wait_duration字段现在可以为零或省略。如果为 1，则要求客户端立即发出另一个请求。只有当客户端在SizeConstraints中指定的最大更新大小限制小于最大数据库大小时，才会发生这种情况。- 需要调整 32 位整数的 Rice 解码算法。不同之处在于，编码后的数据采用不同的字节序进行编码。在 v4 和 v5 中，32 位哈希前缀均按字典顺序排序。但在 v4 中，这些前缀在排序时会被视为小端，而在 v5 中，这些前缀在排序时会被视为大端。这意味着客户端无需进行任何排序，因为字典顺序排序与大端字节序的数字排序相同。点击此处可查看 Chromium 实现的 v4 中的此类示例。您可以移除此类排序。
- 还需要针对其他哈希长度实现 Rice 解码算法。
转化哈希搜索
在 v4 中，可以使用 fullHashes.find 方法获取完整哈希。在 v5 中，等效方法是 hashes.search 方法。
应针对请求进行以下更改：
- 调整代码结构，使其仅发送长度正好为 4 个字节的哈希前缀。
- 完全移除 v4
ClientInfo对象。您只需使用众所周知的 User-Agent 标头，即可提供客户的身份信息，而无需使用专用字段。虽然此标头中没有规定提供客户端标识的格式，但我们建议您仅包含原始客户端 ID 和客户端版本，并用空格字符或斜杠字符分隔。 - 移除
client_states字段。不再需要此函数。 - 不再需要包含
threat_types和类似字段。
应在回答中进行以下更改：
- 已移除
minimum_wait_duration字段。客户端可以随时根据需要发出新请求。 - v4
ThreatMatch对象已简化为FullHash对象。 - 缓存已简化为单个缓存时长。如需了解如何与缓存互动，请参阅上述程序。