Summary

  • El primer borrador público del W3C, de 2015, abordó un problema de limpieza: los datos de un sitio vivían en depósitos distintos del navegador, y el script de la página no podía vaciarlos todos.
  • El borrador de 2017 definió Clear-Site-Data, una cabecera de respuesta que pide al navegador actuar sobre cache, cookies, storage, executionContexts o *.

Una sesión termina en la pantalla y puede continuar, por trozos, en el aparato. El servidor revoca una credencial. El navegador conserva otra pista: un recurso en caché, una base local o código abierto en otra pestaña. El cartel de «hasta luego» no barre por sí solo el suelo de la casa.

El W3C puso ese desorden por escrito en agosto de 2015. JavaScript ofrecía algunas escobas, pero ninguna abría todos los armarios. La marca HttpOnly mantiene ciertas cookies fuera de su alcance por una buena razón. Para eliminarlas mediante respuestas HTTP, el sitio tenía que conocer cada cookie que había establecido y enviar las instrucciones adecuadas. Al mismo tiempo, el almacenamiento local y la caché vivían bajo otras reglas. Una sola despedida implicaba varios inventarios.

La propuesta fue hacer que la respuesta del servidor llevara el encargo. El sitio conoce el momento de cerrar o reparar; el navegador conoce sus depósitos. Una cabecera HTTP podía conectar esas dos piezas. La versión de noviembre de 2017 concretó el vocabulario: nombres entre comillas para "cookies", "storage", "cache" y "executionContexts". La opción "*" abarcaba todas las categorías reconocidas, incluidas las que se añadieran después. El servidor pasaba una lista; el navegador hacía el trabajo doméstico.

La lista permite graduar el gesto. Al cerrar sesión, un servicio puede pedir que se limpien cookies y almacenamiento. Se van tanto las llaves de identificación como los datos locales que acompañaban al usuario. Si el sitio descubre que un atacante pudo dejar estado hostil en los navegadores, el borrador ofrece un ejemplo más severo: limpiar también caché y contextos de ejecución. La misma puerta de salida sirve para dos circunstancias muy distintas, porque el encargo nombra los cajones.

No todos los cajones tienen la misma cerradura. El almacenamiento pertenece al origen de la respuesta. Las cookies pueden circular entre subdominios, y el procedimiento de 2017 llega al dominio registrado. Las entradas de la caché de red se seleccionan por host. El navegador interpreta esas reglas cuando recibe una respuesta segura y autenticada. La cabecera no otorga a una web un mando sobre los recuerdos de sitios ajenos; pone al navegador a gestionar el ámbito que corresponde al emisor.

"executionContexts" es el detalle que salva la escena del teatro. Borrar una cookie mientras otra pestaña sigue viva puede dejar código trabajando con un mundo que acaba de cambiar. Un trabajador en segundo plano también puede conservar actividad. El borrador prepara esos contextos, borra las categorías indicadas y recarga los contextos afectados cuando así se solicita. La limpieza alcanza a quienes siguen dentro del edificio.

El borrado amplio tiene costes visibles. La próxima visita puede necesitar descargar de nuevo recursos retirados de la caché. Una política de cookies que alcanza todo el dominio registrado puede cerrar sesiones en varios subdominios. El almacenamiento local que hacía útil una aplicación sin conexión desaparece si se incluye "storage". Por eso la cabecera habla en plural: el sitio selecciona lo que necesita en vez de golpear siempre el botón rojo de «todo».

La cronología oficial del W3C recoge borradores públicos en 2015, 2016 y 2017. Aquella discusión retrató una realidad creciente: el navegador ya era una pequeña oficina con archivo, despensa y empleados de guardia. Un botón de salida requería instrucciones para toda la oficina.