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 permanecieron 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 la conversión 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 se identifican simplemente por su nombre. Esto proporciona flexibilidad cuando varias listas de la versión 5 podrían 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, haz lo siguiente:
    • 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. 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 realizar ninguna ordenación, ya que la ordenación lexicográfica es idéntica a la ordenación numérica con big endian. Puedes encontrar un ejemplo de este tipo de ordenamiento en la implementación de v4 de Chromium aquí. Se puede quitar ese tipo de ordenamiento.
  4. El algoritmo de decodificación de Rice también deberá implementarse para otras longitudes 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é.