Migration From V4

Una mejora significativa de la versión 5 de Navegación Segura de Google en comparación con la versión 4 (específicamente, la API de Update de la versión 4) 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 principales factores que contribuyen a la falta de protección. 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: en 2021, el 60% de los sitios que realizan ataques estuvieron activos durante menos de 10 minutos. Nuestro análisis muestra que entre el 25% y el 30% de la protección contra phishing faltante se debe a la obsolescencia de los datos. Además, algunos dispositivos no están equipados para administrar la totalidad de las listas de amenazas de la Navegación segura de Google, que siguen creciendo con el tiempo.

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

Actualizaciones de listas de usuarios que generaron conversiones

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 se identifican simplemente por su nombre. Esto proporciona flexibilidad cuando varias listas de la versión 5 pueden compartir el mismo tipo de amenaza. En la versión 5, se quitaron los tipos de plataformas y los tipos de entradas de amenazas.

En la versión 4, se usaría el método threatListUpdates.fetch para descargar 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 la versión 4. En lugar de proporcionar la identificación de un cliente con un campo dedicado, simplemente usa el conocido encabezado User-Agent. Si bien no hay un formato prescrito para proporcionar la identificación del cliente en este encabezado, 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 la versión 4, busca el nombre de la lista correspondiente de la versión 5 en las listas disponibles y proporciona ese nombre en la solicitud de la versión 5.
    • Quita los campos innecesarios, como threat_entry_type o platform_type.
    • El campo state de 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 versión 4 se puede enviar en la versión 5 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. El enum ResponseType de la versión 4 se reemplaza simplemente por un campo booleano llamado partial_update.
  2. Ahora, el campo minimum_wait_duration puede ser cero o se puede omitir. 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. La lógica para decodificar los hashes codificados con Rice-Golomb requiere dos ajustes principales:
    • Orden de bytes y ordenamiento: En la versión 4, los hashes que se devolvían se ordenaban como valores little-endian. En la versión 5, se tratan como valores big-endian. Dado que la ordenación lexicográfica de las cadenas de bytes es equivalente a la ordenación numérica de los valores big-endian, los clientes ya no necesitan realizar un paso de ordenación especial. Si se implementó anteriormente, se puede quitar la ordenación personalizada little-endian, como la que se encuentra en la implementación de Chromium v4.
    • Longitudes de hash variables: Se debe actualizar el algoritmo de decodificación para admitir varias longitudes de hash que se podrían devolver en el campo HashList.compressed_additions, no solo la longitud de hash de cuatro bytes que se usa en la versión 4. La longitud de los hashes que se muestran en la respuesta se puede determinar según el HashList.metadata.hash_length que se muestra en hashLists.list. De forma alternativa, el nombre de la lista de hashes solicitada también indica los tamaños de hash esperados que se devuelven de la lista. Consulta la página Base de datos local para obtener más detalles sobre las listas de hash.

Cómo convertir 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 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 dedicado, simplemente usa el conocido encabezado User-Agent. Si bien no hay un formato prescrito para proporcionar la identificación del cliente en este encabezado, sugerimos que simplemente incluyas el ID de cliente y la versión del 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 nueva solicitud según sea necesario.
  2. El objeto ThreatMatch de la versión 4 se simplificó en el objeto FullHash.
  3. El almacenamiento en caché se simplificó en una sola duración de caché. Consulta los procedimientos anteriores para interactuar con la caché.