Migration From V4

Una mejora significativa de la versión 5 de Navegación segura de Google sobre la versión 4 (específicamente, la API de Update v4) es la actualización y la cobertura de los datos. Dado que la protección depende en gran medida de la base de datos local que mantiene el cliente, la demora y el tamaño de la actualización de la base de datos local son los factores principales que generan la protección omitida. En la versión 4, el cliente típico tarda entre 20 y 50 minutos en obtener la versión más actualizada de las listas de amenazas. Lamentablemente, los ataques de phishing se propagan rápidamente: a partir de 2021, el 60% de los sitios que realizan ataques están activos menos de 10 minutos. Nuestro análisis muestra que entre el 25 y el 30% de la protección contra el phishing que falta se debe a la inactividad de los datos. Además, algunos dispositivos no están equipados para administrar todas las listas de amenazas de Navegación segura de Google, que se siguen ampliando con el tiempo.

Si actualmente usas la API de Update v4, existe una ruta de migración sin problemas de la v4 a la v5 sin tener que restablecer ni borrar la base de datos local. En esta sección, se documenta cómo hacerlo.

Conversión de actualizaciones de listas

A diferencia de la versión 4, en la que las listas se identifican por la tupla de tipo de amenaza, tipo de plataforma y tipo de entrada de amenaza, en la versión 5, las listas solo se identifican por nombre. Esto proporciona flexibilidad cuando varias listas de v5 pueden compartir el mismo tipo de amenaza. Los tipos de plataforma y los tipos de entrada de amenazas se quitaron en la versión 5.

En la versión 4, se usaría el método threatListUpdates.fetch para descargar las listas. En la versión 5, se cambiaría al método hashLists.batchGet.

Se deben realizar los siguientes cambios en la solicitud:

  1. Quita por completo el objeto ClientInfo de v4. En lugar de proporcionar la identificación de un cliente con un campo exclusivo, simplemente usa el encabezado User-Agent conocido. Si bien no hay un formato prescrito para proporcionar la identificación del cliente en este encabezado, te sugerimos que simplemente incluyas el ID de cliente y la versión del cliente originales separados por un espacio o una barra.
  2. Para cada objeto ListUpdateRequest de v4: * Busca el nombre de la lista de v5 correspondiente en la tabla anterior y proporciona ese nombre en la solicitud de v5.
    • Quita los campos innecesarios, como threat_entry_type o platform_type.
    • El campo state en la versión 4 es directamente compatible con el campo versions de la versión 5. La misma cadena de bytes que se enviaría al servidor con el campo state en la v4 se puede enviar en la v5 con el campo versions.
    • Para las restricciones de la versión 4, la versión 5 usa una versión simplificada llamada SizeConstraints. Se deben descartar los campos adicionales, como region.

Se deben realizar los siguientes cambios en la respuesta:

  1. La enum ResponseType de la v4 simplemente se reemplaza por un campo booleano llamado partial_update.
  2. El campo minimum_wait_duration ahora puede ser cero o omitirse. Si es así, se le solicita al cliente que realice otra solicitud de inmediato. Esto solo sucede cuando el cliente especifica en SizeConstraints una restricción menor en el tamaño máximo de actualización que el tamaño máximo de la base de datos.
  3. Se deberá ajustar el algoritmo de decodificación de Rice para números enteros de 32 bits. La diferencia es que los datos codificados se codifican con un orden de bytes diferente. En las versiones 4 y 5, los prefijos hash de 32 bits se ordenan de forma lexicográfica. Sin embargo, en la versión 4, esos prefijos se tratan como little endian cuando se ordenan, mientras que en la versión 5 se tratan como big endian cuando se ordenan. Esto significa que el cliente no necesita hacer ningún orden, ya que el orden lexicográfico es idéntico al orden numérico con formato big endian. Puedes encontrar un ejemplo de este tipo en la implementación de Chromium de la versión 4 aquí. Se puede quitar ese orden.
  4. El algoritmo de decodificación de Rice también se deberá implementar para otras longitudes de hash.

Conversión de búsquedas de hash

En la versión 4, se usaría el método fullHashes.find para obtener hashes completos. El método equivalente en la versión 5 es el método hashes.search.

Se deben realizar los siguientes cambios en la solicitud:

  1. Estructura el código para que solo envíe prefijos de hash que tengan exactamente 4 bytes de longitud.
  2. Quita por completo los objetos ClientInfo de la versión 4. En lugar de proporcionar la identificación de un cliente con un campo exclusivo, simplemente usa el encabezado User-Agent conocido. Si bien no hay un formato prescrito para proporcionar la identificación del cliente en este encabezado, te sugerimos que simplemente incluyas el ID y la versión de cliente originales separados por un espacio o una barra.
  3. Quita el campo client_states. Ya no es necesaria.
  4. Ya no es necesario incluir threat_types ni campos similares.

Se deben realizar los siguientes cambios en la respuesta:

  1. Se quitó el campo minimum_wait_duration. El cliente siempre puede emitir una solicitud nueva según sea necesario.
  2. El objeto ThreatMatch de la versión 4 se simplificó en el objeto FullHash.
  3. La caché se simplificó en una sola duración de caché. Consulta los procedimientos anteriores para interactuar con la caché.