Sorry, keine Cookies

Anfang der 2000er dachten sich einige Jungs:
“Ich schreibe mein eigenes Forum.”

Die coolen Jungs verzichteten damals auf Cookies, weil es damals tatsächlich noch Browser gab, wo Cookies nicht aktiviert waren.

Session-IDs kamen in die URL … bis jemand auf die Idee kam, seinen Beitrag “zu teilen”, also wo anders zu posten.

Und die Nutzer dieses Links waren dann hoch erfreut, als sie plötzlich mit dem Account des Verfassers angemeldet waren.

Das war eine lustige Zeit, wo eine Sicherheitslücke die andere jagte. Aber passiert ist wenig, es ging nur um Forentexte (damals)… nicht um Geld.

Cookies sind eine Missgeburt der Notwendigkeit.
Denn HTTP ist “stateless” (zustandslos), Anfragen haben keinen Bezug zu einander.

Will man sich aber auf einer Seite anmelden, um “als bekannter” Benutzer etwas bestimmtes zu machen, muss es eine Möglichkeit geben, wie der Browser mit dem Server aushandeln kann, dass eben eine bestimmte Anfrage zu einem bestimmten User passt.

So wurde die Session-ID erfunden. Bei einer Anmeldung mit Benutzernamen und Passwort generiert der Server eine ID und sendet sie an den Client (Browser). Der Browser muss diese ID jetzt bei jeder Anfrage mitschicken, damit der Server den User eindeutig erkennt.

Wenn man das wie oben beschrieben über die URL tut, funktioniert das zwar, doch jeder der die URL lesen kann, kann die Session “stehlen”.

Cookies werden auch über HTTP übertragen, sind aber für den Benutzer unsichtbar. Die Idee ist, dass wenn ein Cookie auf einer Seite gesetzt ist, schickt der Browser es bei jeder (und zwar wirklich jeder) Anfrage mit zum Server.

Der Server kann in seiner Antwort per set-cookie Eintrag neue Cookies an den Browser schicken, und wenn dieser sie “annimmt”, werden auch sie bei allen weiteren anfragen wieder an den Server mitgeschickt.
Und im Browser selbst kann man per Javascript die gesetzten Cookies auslesen und ebenfalls neue setzen.

Cookies sind also eigentlich eine reine Browser-interne Sache.

Und das wäre ja alles nicht so schlimm, wenn heute nicht alle Webseiten mit unzähligen Analyse-Scripts und Webelinks zugepflastert wären. Denn diese können über Cookies Zugriffszählungen und einiges mehr umsetzen, die sie dann als Benutzerdaten interpretieren und für gutes Geld weiterverkaufen.
Wird eine Seite das erste mal besucht, wird ein Cookie gesetzt, damit beim nächsten Besuch erkannt wird, dass der User schon einmal hier war … und schon lassen sich Interessensmuster ableiten.

Da Cookies auch das eine oder andere Kilobyte groß werden können und Seiten oft ein Vielzahl an Cookies anlegen, kann es vorkommen, dass Cookies mehr Datenverkehr produzieren, als der eigentlich gewünschte Inhalt … und das ist ärgerlich.

Nachdem die Datenschutzverordnung der EU einige Menschen nervös machte, informieren einem nun alle Seiten, dass sie Cookies nutzen und man das bestätigen soll. Und wo wird diese Bestätigung gespeichert?
Genau, in einem weiteren Cookie.

Wenn man bedenkt, dass HTTP für die Publikation von wissenschaftlichen Ergebnissen erfunden wurde, ist es ziemlich frustrierend zu sehen, wie dieses Protokoll missbraucht wird.

Fazit: Cookies löschen beim Schließen des Browsers!
Im laufenden Betrieb kann man Cookies nicht abdrehen, weil sonst kein Login mehr funktioniert. Doch man kann Browser einstellen, dass alle Cookies (mit der Chronik) beim Beenden gelöscht werden sollen.

Natürlich handelt man sich damit das Komfortproblem ein, dass man sich beim nächsten Browserstart bei Diensten neu anmelden muss.

Doch ich vergönnen der Webefuzzi-Seuche ihr Geschäftsmodel nicht und versuche daher überall wo möglich auf Cookies zu verzichten.

Dieser Blog benutzt KEINE Cookies! KEINE! Wozu denn auch? Hier geht es ja schließlich um Inhalte!


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!