Migration From V4

Atualizações de lista de conversão

Ao contrário da V4, em que as listas são identificadas pela tupla de tipo de ameaça, tipo de plataforma e tipo de entrada de ameaça, na V5, elas são identificadas apenas pelo nome. Isso oferece flexibilidade quando várias listas da v5 podem compartilhar o mesmo tipo de ameaça. Os tipos de plataforma e de entrada de ameaça foram removidos na v5.

Na v4, é usado o método threatListUpdates.fetch para fazer o download de listas. Na v5, é possível mudar para o método hashLists.batchGet.

As seguintes mudanças precisam ser feitas na solicitação:

1. Remova o objeto ClientInfo v4 por completo. Em vez de fornecer a identificação de um cliente usando um campo dedicado, use o cabeçalho User-Agent conhecido. Embora não haja um formato prescrito para fornecer a identificação do cliente nesse cabeçalho, sugerimos incluir o ID do cliente e a versão do cliente originais separados por um espaço ou uma barra.
2. Para cada objeto ListUpdateRequest v4:
   • Procure o nome da lista v5 correspondente em Listas disponíveis e forneça esse nome na solicitação v5.
   • Remova campos desnecessários, como threat_entry_type ou platform_type.
   • O campo state na v4 é diretamente compatível com o campo versions na v5. A mesma string de bytes que seria enviada ao servidor usando o campo state na v4 pode ser enviada na v5 usando o campo versions.
   • Para as restrições da v4, a v5 usa uma versão simplificada chamada SizeConstraints. Campos adicionais, como region, precisam ser descartados.

Faça as seguintes mudanças na resposta:

1. A enum ResponseType da v4 foi substituída por um campo booleano chamado partial_update.
2. O campo minimum_wait_duration agora pode ser zero ou omitido. Se for, o cliente vai precisar fazer outra solicitação imediatamente. Isso só acontece quando o cliente especifica em SizeConstraints uma restrição menor no tamanho máximo da atualização do que o tamanho máximo do banco de dados.
3. O algoritmo de decodificação de Rice para números inteiros de 32 bits precisará ser ajustado. A diferença é que os dados codificados têm uma endianness diferente. Nas versões 4 e 5, os prefixos de hash de 32 bits são classificados lexicograficamente. No entanto, na v4, esses prefixos são tratados como little endian quando classificados, enquanto na v5 eles são tratados como big endian. Isso significa que o cliente não precisa fazer nenhuma classificação, já que a classificação lexicográfica é idêntica à numérica com big endian. Um exemplo dessa classificação na implementação do v4 no Chromium pode ser encontrado aqui. Essa classificação pode ser removida.
4. O algoritmo de decodificação de Rice também precisa ser implementado para outros tamanhos de hash.

Pesquisas de hash de conversão

Na v4, é possível usar o método fullHashes.find para receber hashes completos. O método equivalente na v5 é hashes.search.

As seguintes mudanças precisam ser feitas na solicitação:

1. Estruture o código para enviar apenas prefixos de hash com exatamente 4 bytes de comprimento.
2. Remova todos os objetos ClientInfo da v4. Em vez de fornecer a identificação de um cliente usando um campo dedicado, use o cabeçalho User-Agent conhecido. Embora não haja um formato prescrito para fornecer a identificação do cliente nesse cabeçalho, sugerimos incluir o ID do cliente e a versão do cliente originais separados por um espaço ou uma barra.
3. Remova o campo client_states. Ela não é mais necessária.
4. Não é mais necessário incluir threat_types e campos semelhantes.

Faça as seguintes mudanças na resposta:

1. O campo minimum_wait_duration foi removido. O cliente pode sempre emitir uma nova solicitação conforme necessário.
2. O objeto ThreatMatch v4 foi simplificado no objeto FullHash.
3. O armazenamento em cache foi simplificado em uma única duração. Consulte os procedimentos acima para interagir com o cache.