Summary

  • Der erste öffentliche W3C-Entwurf von 2015 beschrieb das Aufräumproblem hinter dem Abmelden: Eine Website hinterließ Daten in mehreren Bereichen des Browsers, die ein Seitenskript nicht gemeinsam leeren konnte.
  • Der Arbeitsentwurf von 2017 formulierte mit Clear-Site-Data eine Bitte in der HTTP-Antwort. Sie konnte cache, cookies, storage, executionContexts oder per * alle bekannten Bereiche nennen.

Auf dem Bildschirm ist die Sache erledigt. Im Gerät kann dieselbe Sitzung jedoch noch Spuren hinterlassen: eine lokale Datenbank für den Offlinebetrieb, zwischengespeicherte Skripte, Cookies und ein geöffneter Tab. Das Schild „Feierabend“ hat im Lager noch nie selbst die Regale geräumt.

Der erste öffentliche W3C-Entwurf vom August 2015 benannte diese Unordnung. JavaScript konnte manche Daten löschen, doch HttpOnly-Cookies waren ihm absichtlich entzogen. Für deren Entfernung brauchte die Website HTTP-Antworten und eine vollständige Vorstellung davon, welche Cookies sie zuvor gesetzt hatte. Andere Browserbereiche verlangten wiederum andere Verfahren. Ein einzelner Abmeldeknopf musste eine Liste von Schlüsseln und Besen verwalten.

Die vorgeschlagene Lösung verlegte den Auftrag in die HTTP-Antwort. Die Website entscheidet, wann sie lokale Spuren räumen lassen will. Der Browser, dem die Speicherbereiche gehören, führt den Auftrag aus. Wer den Anlass kennt, muss nicht selbst in jedem Fach herumstochern; wer die Fächer kennt, braucht eine brauchbare Anweisung.

Im Arbeitsentwurf vom November 2017 erhielt diese Anweisung eine Liste. Der Header Clear-Site-Data nennt Werte in Anführungszeichen: "cookies", "storage", "cache" und "executionContexts". Mehrere Werte können zusammenstehen. "*" fordert alle Typen an, die der Mechanismus kennt, auch später hinzugefügte. Das Sternchen ist die große Kehrmaschine; die einzelnen Namen sind die passenden Werkzeuge für den gewöhnlichen Dienstag.

Beim normalen Abmelden könnte eine Antwort Cookies und Speicher nennen. Sitzungsmerkmale und lokale Daten verlassen gemeinsam das Gerät. Der Entwurf beschreibt auch den Ernstfall: Hat eine kompromittierte Website möglicherweise schädlichen Zustand in den Browsern ihrer Besucher hinterlassen, kann sie Cache und laufende Ausführungskontexte in die Räumung einbeziehen. Derselbe Header lässt unterschiedlich große Aufträge zu. Die Entscheidung wird an der Liste sichtbar.

Jede Schublade hat eine andere Grenze. storage wird der Herkunft der Antwort zugeordnet. Cookies werden zwischen Subdomains geteilt; ihre Löschung greift im Entwurf deshalb auf die registrierte Domain. Einträge im Netzwerk-Cache werden nach Host ausgewählt. Die Antwort muss über eine sichere, authentifizierte Verbindung kommen, bevor der Vorgang beginnt. Der Browser nimmt den Auftrag entgegen und bewahrt gleichzeitig die Grenzen zwischen verschiedenen Websites.

Besonders wichtig sind die Räume, in denen noch jemand arbeitet. Ein geöffneter Tab kann mit altem Zustand fortfahren, nachdem ein Cookie verschwunden ist. Auch ein Worker kann weiterlaufen. Der Entwurf bereitet betroffene Ausführungskontexte vor, löscht die gewünschten Kategorien und lädt bei "executionContexts" die betroffenen Ansichten neu. Sonst wischt der Hausmeister den Boden, während der Kollege die Asche wieder hineinschüttet.

Ein breiter Auftrag ist spürbar. Nach dem Leeren des Caches müssen Ressourcen erneut geladen werden. Das Löschen von Cookies einer registrierten Domain kann Sitzungen auf mehreren Subdomains beenden. Wird "storage" geräumt, verliert eine Offlineanwendung möglicherweise ihr lokales Arbeitsmaterial. Die Auswahl einzelner Kategorien ist daher kein Schmuck am Header. Sie macht die Reichweite der Entscheidung sichtbar.

Die W3C-Veröffentlichungschronik führt öffentliche Entwürfe von 2015, 2016 und 2017 auf. Sie erzählen von einem Browser, der vom flüchtigen Fenster zum Archiv wurde. Wer sich aus einem Archiv abmeldet, muss an mehr denken als an die Tür.