Obtén seguridad y privacidad mediante la partición de la caché

Eiji Kitamura
Eiji Kitamura

En general, el almacenamiento en caché puede mejorar el rendimiento, ya que almacena los datos para que las solicitudes futuras para los mismos datos se entreguen más rápido. Por ejemplo, un recurso almacenado en caché de la red puede evitar un recorrido de ida y vuelta al servidor. Un resultado de procesamiento almacenado en caché puede omitir el tiempo para realizar el mismo cálculo.

En Chrome, el mecanismo de la caché se usa de varias maneras, y la caché HTTP es un ejemplo.

Cómo funciona la caché HTTP de Chrome actualmente

A partir de la versión 85, Chrome almacena en caché los recursos recuperados de la red y usa sus respectivas URL de recursos como la clave de caché. (Se usa una clave de caché para identificar un recurso almacenado en caché).

En el siguiente ejemplo, se muestra cómo una sola imagen se almacena en caché y se trata en tres contextos diferentes:

Clave de caché: https://x.example/doge.png
Clave de caché: { https://x.example/doge.png }

Un usuario visita una página (https://a.example) que solicita una imagen (https://x.example/doge.png). La imagen se solicita desde la red y se almacena en caché con https://x.example/doge.png como clave.

Clave de caché: https://x.example/doge.png
Clave de caché: { https://x.example/doge.png }

El mismo usuario visita otra página (https://b.example), que solicita la misma imagen (https://x.example/doge.png). El navegador verifica su caché HTTP para ver si ya tiene este recurso almacenado en caché, usa la URL de la imagen como clave. El navegador encuentra una coincidencia en su caché, por lo que usa la versión almacenada en caché del recurso.

Clave de caché: https://x.example/doge.png
Clave de caché: { https://x.example/doge.png }

No importa si la imagen se carga desde un iframe. Si el usuario visita otro sitio web (https://c.example) con un iframe (https://d.example) y este solicita la misma imagen (https://x.example/doge.png), el navegador aún puede cargar la imagen desde su caché, ya que la clave de caché es la misma en todas las páginas.

Este mecanismo funciona bien desde la perspectiva del rendimiento durante mucho tiempo. Sin embargo, el tiempo que tarda un sitio web en responder a solicitudes HTTP puede revelar que el navegador accedió al mismo recurso en el pasado, lo que lo abre a ataques de seguridad y privacidad, como los siguientes:

  • Detectar si un usuario visitó un sitio específico: Un adversario puede detectar el historial de navegación de un usuario verificando si la caché tiene un recurso que podría ser específico de un sitio o una cohorte de sitios en particular.
  • Ataque de búsqueda en sitios cruzados: Un adversario puede detectar si una string arbitraria aparece en los resultados de la búsqueda del usuario verificando si una imagen "sin resultados de la búsqueda" que usa un sitio web en particular está en la caché del navegador.
  • Seguimiento entre sitios: La caché se puede usar para almacenar identificadores similares a cookies como un mecanismo de seguimiento entre sitios.

Para mitigar estos riesgos, Chrome particionará su caché HTTP a partir de Chrome 86.

¿Cómo afectará la partición de caché a la caché HTTP de Chrome?

Con el particionamiento de la caché, se asignará a los recursos almacenados en caché una "Clave de aislamiento de red" además de la URL del recurso. La clave de aislamiento de red se compone del sitio de nivel superior y el sitio del marco actual.

Observa de nuevo el ejemplo anterior para ver cómo funciona la partición de caché en diferentes contextos:

Clave de caché { https://a.example, https://a.example, https://x.example/doge.png}
Clave de caché: { https://a.example, https://a.example, https://x.example/doge.png }

Un usuario visita una página (https://a.example) que solicita una imagen (https://x.example/doge.png). En este caso, la imagen se solicita desde la red y se almacena en caché mediante una tupla que consiste en https://a.example (el sitio de nivel superior), https://a.example (el sitio del marco actual) y https://x.example/doge.png (la URL del recurso) como clave. (ten en cuenta que cuando la solicitud de recursos es del marco de nivel superior, el sitio de nivel superior y el sitio del marco actual en la clave de aislamiento de red son los mismos).

Clave de caché { https://a.example, https://a.example, https://x.example/doge.png}
Clave de caché: { https://b.example, https://b.example, https://x.example/doge.png }

El mismo usuario visita una página diferente (https://b.example) que solicita la misma imagen (https://x.example/doge.png). Aunque se cargó la misma imagen en el ejemplo anterior, dado que la clave no coincide con ella, no será un acierto de caché.

La imagen se solicita desde la red y se almacena en caché mediante una tupla que se compone de https://b.example, https://b.example y https://x.example/doge.png como clave.

Clave de caché { https://a.example, https://a.example, https://x.example/doge.png}
Clave de caché: { https://a.example, https://a.example, https://x.example/doge.png }

Ahora, el usuario vuelve a https://a.example, pero esta vez la imagen (https://x.example/doge.png) está incorporada en un iframe. En este caso, la clave es una tupla que contiene https://a.example, https://a.example y https://x.example/doge.png, y se produce un acierto de caché. (Ten en cuenta que cuando el sitio de nivel superior y el iframe son el mismo sitio, se puede usar el recurso almacenado en caché con el marco de nivel superior.

Clave de caché { https://a.example, https://a.example, https://x.example/doge.png}
Clave de caché: { https://a.example, https://c.example, https://x.example/doge.png }

El usuario está de vuelta en https://a.example, pero esta vez la imagen está alojada en un iframe de https://c.example.

En este caso, la imagen se descarga de la red porque no hay ningún recurso en la caché que coincida con la clave que consta de https://a.example, https://c.example y https://x.example/doge.png.

Clave de caché { https://a.example, https://a.example, https://x.example/doge.png}
Clave de caché: { https://a.example, https://c.example, https://x.example/doge.png }

¿Qué sucede si el dominio contiene un subdominio o un número de puerto? El usuario visita https://subdomain.a.example, que incorpora un iframe (https://c.example:8080), que solicita la imagen.

Debido a que la clave se crea según "scheme://eTLD+1", se ignoran los subdominios y los números de puerto. Por lo tanto, se produce un acierto de caché.

Clave de caché { https://a.example, https://a.example, https://x.example/doge.png}
Clave de caché: { https://a.example, https://c.example, https://x.example/doge.png }

¿Qué sucede si el iframe se anida varias veces? El usuario visita https://a.example, que incorpora un iframe (https://b.example), que incorpora otro iframe (https://c.example), que finalmente solicita la imagen.

Debido a que la clave se toma del fotograma superior (https://a.example) y del fotograma inmediato que carga el recurso (https://c.example), se produce un acierto de caché.

Preguntas frecuentes

¿Ya está habilitada en mi Chrome? ¿Cómo puedo verificarlo?

La función se lanzará a finales de 2020. Para comprobar si tu instancia de Chrome ya es compatible, sigue estos pasos:

  1. Abre chrome://net-export/ y presiona Iniciar registro en el disco.
  2. Especifica dónde guardar el archivo de registro en tu computadora.
  3. Navega por la Web en Chrome durante un minuto.
  4. Regresa a chrome://net-export/ y presiona Detener registro.
  5. Ve a https://netlog-viewer.appspot.com/#import.
  6. Presiona Elegir archivo y pasa el archivo de registro que guardaste.

Verás el resultado del archivo de registro.

En la misma página, busca SplitCacheByNetworkIsolationKey. Si va seguida de Experiment_[****], la partición de la caché HTTP está habilitada en Chrome. Si está seguida de Control_[****] o Default_[****], no está habilitada.

¿Cómo puedo probar la partición de la caché HTTP en mi Chrome?

Para probar la partición de la caché HTTP en Chrome, debes iniciar el navegador con una función experimental de línea de comandos: --enable-features=SplitCacheByNetworkIsolationKey. Para aprender a iniciar Chrome con una marca de línea de comandos en tu plataforma, sigue las instrucciones que se indican en Cómo ejecutar Chromium con marcas.

Como desarrollador web, ¿hay alguna acción que deba tomar en respuesta a este cambio?

Este cambio no es rotundo, pero puede imponer consideraciones de rendimiento para algunos servicios web.

Por ejemplo, aquellos que entregan grandes volúmenes de recursos que pueden almacenarse en caché en muchos sitios (como fuentes y secuencias de comandos populares) pueden experimentar un aumento en su tráfico. Además, quienes consumen esos servicios pueden depender más de ellos.

Hay una propuesta para habilitar las bibliotecas compartidas de una manera que preserva la privacidad, llamada bibliotecas compartidas en la Web (video de presentación), pero aún se está considerando.

¿Cuál es el impacto de este cambio de comportamiento?

La tasa de errores de caché general aumenta en aproximadamente un 3.6%, los cambios en el FCP (First Contentful Paint) son moderados (alrededor del 0.3%) y la fracción general de bytes cargados desde la red aumenta en un 4%. Puedes obtener más información sobre el impacto en el rendimiento en la explicación de la partición de caché HTTP.

¿Está estandarizado? ¿Otros navegadores se comportan de manera diferente?

Las “particiones de caché HTTP” están estandarizadas en la especificación de recuperación, aunque los navegadores se comportan de manera diferente:

  • Chrome: Usa el elemento de nivel superior scheme://eTLD+1 yframe scheme://eTLD+1.
  • Safari: Usa eTLD+1 de nivel superior.
  • Firefox: Planean implementar con el esquema de nivel superior://eTLD+1 y están considerando incluir una segunda clave, como Chrome.

¿Cómo se trata la recuperación de trabajadores?

Los trabajadores dedicados usan la misma clave que su marco actual. Los service workers y los trabajadores compartidos son más complicados, ya que se pueden compartir entre varios sitios de nivel superior. Actualmente, se está debatiendo la solución para ellos.

Recursos