Summary

  • Dès 2015, le W3C décrit le ménage compliqué d’un site : des données dispersées dans plusieurs réserves du navigateur, dont certaines échappent aux scripts de la page.
  • Le projet de 2017 donne à la réponse HTTP un en-tête Clear-Site-Data. Il nomme les compartiments à vider : cache, cookies, storage, executionContexts, ou l’ensemble avec *.

Une application vous souhaite une bonne soirée. Son bouton de déconnexion s’éteint, mais le navigateur conserve peut-être encore un cookie, une base locale, des images dans le cache et un onglet qui continue de travailler. Le mot « terminé » paraît beaucoup plus convaincant sur le bouton que dans les entrailles de la machine.

Le premier projet public du W3C, daté d’août 2015, part de ce désordre. JavaScript sait retirer certaines traces. Il ne peut pas lire un cookie HttpOnly : cette barrière protège justement le cookie contre les scripts. Pour l’expirer, le serveur doit répondre avec les bons en-têtes et connaître les cookies qu’il avait créés. Le stockage local et le cache suivent chacun une autre procédure. Une sortie propre devenait un inventaire de déménagement.

La proposition changeait l’adresse de la demande. Le site indique, dans une réponse HTTP, ce qu’il veut faire effacer. Le navigateur exécute le ménage parce qu’il possède les tiroirs. Le serveur sait pourquoi la session doit finir ; le navigateur sait où s’accumulent les restes. Il manquait une phrase commune entre les deux.

Le projet de novembre 2017 lui donne une grammaire. Clear-Site-Data transporte une liste de noms entre guillemets. "cookies" vise les cookies, "storage" les espaces de stockage, "cache" les ressources gardées en réserve. "executionContexts" s’occupe des pages et des travailleurs encore actifs. L’astérisque "*" demande tout ce que cet en-tête sait couvrir, y compris de futurs types. Quatre petits mots, et une ambition de femme de ménage d’hôtel : rien sous le lit.

Le cas banal est la déconnexion. Une réponse peut demander "cookies", "storage". L’identité de session et les données locales partent dans le même mouvement. Le projet imagine aussi une journée moins banale : après une compromission, le site veut purger ce qui a pu rester sur les machines de ses visiteurs. Il demande alors un balayage plus large, avec cache et contextes actifs. Le navigateur reçoit un ordre organisé au lieu de laisser chaque page improviser sa propre chasse au trésor.

Ce ménage a des frontières différentes selon le tiroir. Le stockage se rattache à l’origine de la réponse. Les cookies traversent les sous-domaines : la procédure du projet s’étend donc au domaine enregistré. Le cache réseau est examiné par hôte. Le texte de 2017 exige aussi une réponse authentifiée et sûre avant d’engager l’opération. Un site qui sort ses propres affaires ne reçoit pas un passe-partout pour vider celles du voisin.

Le tiroir des contextes actifs donne tout son sens au dispositif. Effacer un cookie pendant qu’un onglet continue à tourner peut laisser cet onglet agir sur un état dépassé, voire réécrire une donnée effacée. Le projet prépare les contextes concernés, vide les catégories demandées, puis recharge les pages lorsque "executionContexts" figure dans la liste. Le ménage doit atteindre les programmes encore debout, pas seulement les placards.

La largeur de l’ordre compte. Vider le cache imposera de recharger des ressources lors de la prochaine visite. Supprimer les cookies peut déconnecter plusieurs services installés sur des sous-domaines d’un même domaine enregistré. Effacer le stockage peut emporter ce qui permettait de travailler hors ligne. Le projet offre des noms distincts pour que le site demande le coup de balai adapté à l’incident. Il évite de transformer chaque sortie ordinaire en grand nettoyage de printemps.

L’historique de publication du W3C retrace trois projets publics entre 2015 et 2017. Ils saisissent un changement du Web : le navigateur était devenu un meuble de rangement. Un simple « au revoir » ne suffisait plus ; il fallait désigner les tiroirs.