Migration From V4

Como converter atualizações de listas

Ao contrário da V4, em que as listas são identificadas pelo conjunto de tipo de ameaça, tipo de plataforma e tipo de entrada de ameaça, na V5, as listas 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ças foram removidos da v5.

Na v4, o método threatListUpdates.fetch era usado para fazer o download de listas. Na v5, você precisaria mudar para o método hashLists.batchGet.

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

1. Remova o objeto ClientInfo do v4. Em vez de fornecer a identificação de um cliente usando um campo dedicado, basta usar o cabeçalho User-Agent conhecido. Não há um formato prescrito para fornecer a identificação do cliente neste cabeçalho. Sugerimos incluir o ID e a versão do cliente originais separados por um espaço ou um caractere de barra.
2. Para cada objeto ListUpdateRequest do v4: * Consulte o nome da lista v5 correspondente na tabela acima 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 é compatível com o campo versions da 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 excluídos.

As seguintes mudanças devem ser feitas na resposta:

1. O tipo enumerado ResponseType da v4 é simplesmente substituído por um campo booleano chamado partial_update.
2. O campo minimum_wait_duration agora pode ser zero ou omitido. Se for, o cliente precisa fazer outra solicitação imediatamente. Isso só acontece quando o cliente especifica em SizeConstraints uma restrição menor no tamanho máximo de 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 precisa ser ajustado. A diferença é que os dados codificados são codificados com um endian diferente. Na v4 e na v5, os prefixos de hash de 32 bits são classificados lexicograficamente. Mas, 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 lexicografica é idêntica à classificação numérica com big endian. Confira aqui um exemplo desse tipo na implementação do Chromium da v4. Essa classificação pode ser removida.
4. O algoritmo de decodificação de Rice também precisa ser implementado para outras extensões de hash.

Conversão de pesquisas de hash

Na v4, o método fullHashes.find é usado para receber hashes completos. O método equivalente na v5 é o método 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.
2. Remova todos os objetos ClientInfo do v4. Em vez de fornecer a identificação de um cliente usando um campo dedicado, basta usar o cabeçalho User-Agent conhecido. Não há um formato prescrito para fornecer a identificação do cliente neste cabeçalho. Sugerimos incluir o ID e a versão do cliente originais separados por um espaço ou um caractere de 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.

As seguintes mudanças devem ser feitas 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 do v4 foi simplificado no objeto FullHash.
3. A armazenagem em cache foi simplificada em uma única duração. Consulte os procedimentos acima para interagir com o cache.