Genehmigungen für Cookies

Warum werden Cookies gebraucht?1

key.matiq braucht nur funktionale Cookies. Ein Teil ist essenziell, aber es gibt auch Cookies, die optionale Features betreffen, die die Nutzer*in abwählen kann oder die nicht unbedingt erforderlich sind. Solche funktionalen Cookies sind genehmigungspflichtig. Es geht um folgende Features:

• Erkennung der zuletzt angemeldeten Box und des zuletzt angemeldeten Tickets vor einer erneuten Anmeldung (Cookies "box_id", "ticket_id"). Damit ist möglich:
  • Auf Sicherheitsvorkehrungen gegen Ausforschungsangriffe kann verzichtet werden. (Derzeit handelt es sich bei den Vorkehrungen um ein einfaches Captcha, aber sie könnten je nach Bedrohungslage verschärft werden und damit höheren Aufwand für die Benutzer*in bedeuten. Es geht darum, diesen höheren Aufwand nur im Ausnahmefall (man meldet sich an einem neuen Gerät an oder wechselt die Anmeldung von einer Box an eine andere) entstehen zu lassen.
  • Bei Boxen kann mit einer Willkommensmeldung, die bei existierendem "box_id"-Cookie angezeigt wird, die Anmeldeseite personalisiert werden. Dies bedeutet Schutz vor Phishing-Angriffen: Eine gefälschte Seite kann (ohne Diebstahl des "box_id"-Cookie oder eines Screenshot der Anmeldeansicht) nicht die Willkommensmeldung wissen und damit diese nicht anzeigen. Die Fälschung würde also auffallen und die Nutzer*in würde gewarnt.
  • Infoseiten (z. B. "Wichtige Meldung", "News", "Blog", "Handbuch") können hervorgehoben werden, wenn die Nutzer*in diese noch nicht oder nicht in der neuesten Fassung gelesen hat). Damit kann die Nutzer*in besser geführt werden.
• Wiedererkennung eines Geräts (Cookie "device_id"). Damit ist die Implementierung einer unaufdringlichen Zwei-Faktor-Authentisierung möglich: Im Regelfall erkennt key.matiq einfach: Die Benutzer*in war schon einmal an diesem Gerät mit dieser Box angemeldet. Nur wenn das nicht der Fall ist, sind aufwändigere alternative Methoden zur Überprüfung erforderlich.
• Sperrung der automatischen Ausfüllung (durch den Passwortmanager des Browsers) von Anmelde- oder Entsperrformularen nach Timeouts (Cookie "autocomplete"). Diese Sperrung ist leider nicht 100-prozentig, erschwert aber in der Regel den Zugriff durch jemand anders, falls man abgelenkt wurde, den Arbeitsplatz ungeschützt verlassen hatte oder das Smartphone in angemeldeten Zustand im Zug hat liegen lassen.
• Infoseiten, Tooltips oder andere Infos entsprechend des benutzten Geräts. Dann heisst es "Klicken" bei der Maus, "Tippen" bei einem Touchscreen, "Mausrechtsklick" für das Kontextmenü bei einer Rechtshänder*in, aber "Mauslinksklick" bei einer Linkshänderin. Und eine Voreinstellung für eine Vergrößerung der Ansichten für Sehbehinderte (ständiges Spreizen bei Touchscreens ist da kein Ersatz). Im Cookie "device" werden diese Einstellungen gespeichert.
• Wird für einen Browser ein mögliche Inkompatibilität mit key.matiq vermutet, sollte ein Hinweis erfolgen. Aber auch nur einmal und dann erst nach einiger Zeit wieder. Damit sich die Benutzer*in dessen bewusst ist und bleibt, aber nicht ständig gestört wird. (Vielleicht funktioniert der Browser ja doch mit key.matiq.) Das dafür benötigte Cookie heißt "browser_tested". Es ist aber nicht unbedingt nötig, Ohne die Genehmigung für das Cookie, könnte z. B. das Testen des Browsers auf die Startseite begrenzt werden und dort immer erfolgen. (Dumm ist dann nur, wenn die Nutzer*in gar nicht erst auf die Startseite geht.)

Essenzielle Cookies

Für essenzielle Cookies bedarf es keiner Genehmigung, aber diese werden auch immer erst eingesetzt, wenn ihr Einsatz unumgänglich wird. So ist zum Beispiel für einen Besuch von reinen Infoseiten (also ohne jede Anmeldung) erforderlich, die Größe des Viewports (ggf. auch angegebene Geräte-Eigenschaften) von Ansicht zu Ansicht weiter zu geben. Aber dies kann auch über die Weitergabe von HTML-Parametern erfolgen, ohne dass bereits "Sitzungsdaten" angelegt werden müssen.

Erst wenn Box- oder Ticketanmeldungen (oder Registrierungen) ins Spiel kommen, ist ein Datensatz mit Sitzungsdaten und ein dazugehöriges Cookie "session_id" zwingend erforderlich.

Für die Verwaltung von Cookie-Genehmigungen, wie sie im Folgenden beschrieben wird, ist das Cookie "cookie_approvals" nötig, auch dann, wenn keine der optionalen Cookies erlaubt werden.2

Das dritte essenzielle Cookie ist "guest" und verwaltet den Gastzugang, wenn die Besitzer*in eines Gerät jemand anders erlaubt, dieses für eine Anmeldung an key.matiq zu benutzen.3

Definition "Gerät"

Für das Folgende ist zu beachten: Als "Gerät" wird nicht das physikalische Gerät, sondern das logisch unterscheidbare Gerät angesehen, d. h. in der Regel die Kombination von physikalischem Gerät, Benutzer*in an diesem Gerät und benutztem Browser. Für jedes solche "Gerät" können nämlich eigene Cookies angelegt werden. Und nur diese sind für key.matiq sichtbar.

Außerdem: Nach Löschung aller Cookies erscheint das Gerät als "neues Gerät". (Siehe auch Glossar).

Hierarchische Genehmigungen

Um die Genehmigungen für die Nutzer*innen so einfach wie möglich zu gestalten, werden die Cookies in Cookie-Gruppen eingeordnet, und es wird der Nutzer*in ermöglicht, sowohl für alle Cookies, als auch für einzelne Cookie-Gruppen, als auch für einzelne Cookies Genehmigungen bzw. Ablehnungen auszusprechen.

Genehmigungen für Gerät, Box und Ticket

Am Einfachsten (zu implementieren) wäre es, für jedes Gerät einzeln die Cookies genehmigen oder ablehnen zu lassen. Benutzungsfreundlicher ist es jedoch, die Cookie-Einstellungen für eine Box (auch für ein Ticket) festzulegen, die dann nach einer Anmeldung auf einem neuen Gerät für dieses übernommen werden.

Allerdings gibt es auch Cookies ("device" und "browser_tested"), die bereits außerhalb einer Anmeldung relevant sind und daher auch schon vorher akzeptiert werden könnten.

Daraus können sich konkurrierende Einstellungen ergeben:

• Einstellungen die auf Geräte-Ebene getroffen wurden (außerhalb einer Anmeldung, oder mit expliziter Angabe innerhalb einer Anmeldung, dass die Einstellungen nur dieses Gerät betreffen)
• Einstellungen, die in einer Box-Anmeldung getroffen wurden
• Einstellungen, die in einer anderen Box, die vom selben Gerät aus verwaltet wird, getroffen werden

Hinzu kommen, dass es Sinn macht, bei einzelnen Einstellungen (wie z. B. der Eintragung einer Willkommensmeldung oder Anschalten der Zwei-Faktor-Authentisierung) die dafür nötigen Cookies genehmigen zu lassen. Denn hier wird deren Sinn der Benutzer*in besonders deutlich. In diesem Fall ist aber zu anderen Cookies keine Aussage erforderlich.

Lösung

Wir wenden das Prinzip der geringsten Überraschung (Principle of Least Surprise, POLS4) an:

Die letzte Einstellung, die eine Nutzer*in verfügt ist, sticht frühere Entscheidungen.

Damit muss aber für jede Cookie-Entscheidung auch ein Timestamp gespeichert werden:

• Bei Cookie-Entscheidungen auf Geräte-Ebene wird im Cookie "cookie_approvals" unter "at=\" der Zeitpunkt der letzten Entscheidung über alle Cookies gespeichert und unter "at_device=\" der (abweichende) Zeitpunkt einer Entscheidung über das "device"-Cookie gespeichert.
• Bei Cookie-Entscheidungen auf Box- oder Ticket-Ebene werden in den Box- bzw. Ticket-Daten die Zeitpunkte für Entscheidungen über alle Cookies, aber auch davon abweichende Zeitpunkte für Einzel-Entscheidungen (wie z. B. über die Cookies "autocomplete", "box_id", "device_id", "ticket_id".

Nach einer Anmeldung (an Box oder Ticket) werden Genehmigungen, die auf Box- oder Ticket-Ebene getroffen wurden, auf die Geräte-Ebene übernommen, sofern diese nach der Entscheidung (für das betreffende Cookie) getroffen wurden.

Ablehnungen können jedoch nicht einfach von einer Box- oder Ticket-Ebene auf die Geräte-Ebene übernommen werden. Denn: Es ist ja möglich, dass eine andere Box oder ein anderes Ticket ebenfalls von dem gleichen Gerät aus verwaltet wird. Deren Funktionieren darf aber nicht von außen beeinflusst werden.

In der umgekehrten Richtung hat dann aber auch für eine Box oder ein Ticket innerhalb einer Anmeldung eine Ablehnung auf Box- oder Ticket-Ebene ein höheres Gewicht als eine Genehmigung auf Geräte-Ebene, wenn es sich um ein box- bzw. ticketspezifisches Cookie handelt. Dies wird im folgenden Abschnitt behandelt.

Prioritäten

Nach einer Anmeldung an eine Box oder ein Ticket und der Übernahme von Genehmigungen, die auf Box- bzw. Ticket-Ebene zuvor getroffen wurden, in das Cookie "cookie_approvals" gelten die betroffenen Cookies als "genehmigt". ABER: Die Box (bzw. das Ticket) muss die Genehmigung ja nicht nutzen. Wann aber wird sie sie nutzen?

Das Problem ist, dass Genehmigungen in "cookie_approvals" enthalten sein könnnen, die nicht von der angemeldeten Box (bzw. dem angemeldeten Ticket) übernommen wurden und dort auch gar nicht gegeben wurden.5

Bei gerätespezifischen Cookies ("device", "browser_tested") kann getrost eine solche Genehmigung mit benutzt weden. Daraus resultierende Anzeigen und Informationen sollten einheitlich für das Gerät erfolgen, egal an welche Box oder welches Ticket man angemeldet ist oder ob man überhaupt angemeldet ist. Nur so kann für diese Cookies das POLS-Prinzip eingehalten werden.

Anders sieht es bei Cookies aus, die mit der Anmeldung an eine Box oder an ein Ticket zu tun haben (bei Boxen "box_id", "device_id" und "autocomplete", bei Tickets "ticket_id" und wiederum "device_id" und "autocomplete"). Hier sollten Box oder Ticket nur solche Genehmigungen nutzen, die auch auf Box- oder Ticket-Ebene für diese Box (dieses Ticket) genehmigt wurden. Nur mit dieser Selbstbeschränkung kann erreicht werden, dass das Verhalten für eine Box (ein Ticket) auf allen Geräten, auf denen an diese Box (dieses Ticket) angemeldet wird, gleich ist. Alles andere würde dem POLS-Prinzip widersprechen.

Übernahme von Genehmigungen nach der Anmeldung

Es ist nicht ganz einfach, rechtlich sauber genehmigen zu lassen, dass eine Genehmigung für ein Cookie für eine Box nach einer späteren Anmeldung an ein anderes Gerät automatisch für dieses übernommen wird.

Das würde eine saubere Formulierung erfordern, die dann vielleicht etwas kompliziert wirkt und damit die Zustimmung der Benutzer*in eher erschwert.

Einfacher ist es, die eigentliche Genehmigung erst bei der Übernahme abzurufen. Das passiert dann zwar bei jedem neuen Gerät, aber dort auch nur einmal. Und es ist nur ein Klick. (Denn die Auswahl der zu übernehmenden Cookies wurde ja schon getroffen.) Natürlich besteht das Risiko, dass dann die Benutzer*in es sich anders überlegt. Aber dass lässt sich handhaben, siehe nächster Abschnitt.

Übernahme von Genehmigungen auf der Box- bzw. Ticket-Ebene

Wenn (über die Einstellungsseite oder auch bei der Registrierung) Genehmigungen auf der Box- bzw. Ticket-Ebene gegeben werden, sollten diese auch auf dem momentaen Gerät wirksam werden. Verbote auf der Box- bzw. Ticket-Ebene sollten dagegen nicht unmittelbar für das Gerät übernommen werden (da diese das Verhalten von anderen Boxen oder Tickets, die auf dem gleichen Gerät verwaltet werden beeinflussen würde).

Lebenszeit von Cookies

Für das "_session_id"-Cookie wird kein Ablaufzeitpunkt angegeben, was heißt, dass es mit dem "Ende der Browser-Sitzung" (was immer der Browser darunter versteht) als abgelaufen gilt. (Die Einschränkung "was immer der der Browser darunter versteht" hat damit zu tun, dass die Browser zulassen, kürzlich geschlossene Tabs wieder zu öffnen.) Auf jeden Fall wird das Cookie serverseitig als "abgelaufen" markiert6, wenn ein Timeout der serverseitigen Sitzung bemerkt wird. Die Timeout-Spanne hierfür ist z. T. benutzungsseitig einstellbar, beträgt aber jedenfalls maximal acht Stunden.

Für die übrigen Cookies (wir nennen sie "persistente Cookies") wird ein Ablaufzeitpunkt angegeben. Dafür wird eine Lebenszeit benötigt. Diese Lebenszeit ist sehr vom Nutzungsverhalten abhängig, das auch von Gerät zu Gerät unterschiedlich sein kann.

Die Ablaufzeitpunkte der persistenten Cookies werden bei jedem HTML-Zugriff auf die key.matiq-Domain entsprechend der Lebenszeit neu gesetzt. D. h. sie laufen nur dann ab, wenn die Zeitspanne zwischen zwei Zugriffen die Lebenszeit überschritten hat.

Die Lebenszeit von Cookies kann nur über die Einstellungsseite von der Nutzer*in eingestellt werden7. Solange dies nicht erfolgt ist, werden persistente Cookies mit der Lebenszeit von einem Jahr ausgestattet.

Da die Lebenszeit gerätespezifisch sein sollte, wird sie mit Priorität in dem "cookie_approvals"-Cookie (also auf Geräte-Ebene) festgehalten. Auch wenn bei den Einstellungen die "Box-Ebene" oder "Ticket-Ebene" gewählt wird, so wird bei diesem Punkt die Lebenszeit auf der "Geräte-Ebene" eingestellt.

Nur wenn auf einem Gerät, für das auf Geräte-Ebene noch nicht explizit die Lebenszeit festgelegt wurde, eine Anmeldung erfolgt, auf der Box- bzw. Ticket-Ebene eine solche Festlegung aber schon geschehen ist, wird diese für das Gerät (in das "cookie_approvals"-Cookie) übernommen.

Im Ergebnis hat also die Festlegung auf Geräte-Ebene die Priorität, danach die auf der Box- bzw. Ticket-Ebene und schließlich der allgemeine Vorbelegungswert von einem Jahr.

Verbleibende Probleme

Es kann sein, dass eine Genehmigung für ein Cookie, das auf Box-Ebene genehmigt wurde, auf ein Gerät nicht übernommen werden kann, weil nach der Genehmigung auf der Box-Ebene, auf dem Gerät die Cookie-Einstellungen verändert wurden (mit Verbot für das betreffende Cookie). Denn dann ist das Verbot später als die Genehmigung erfolgt und genießt daher Priorität. Es wird gar nicht für die Übernahme angeboten.

Es kann aber auch sein, dass die Benutzer*in die Übernahme der dafür vorgesehenen Cookies verweigert. (Siehe vorheriger Abschnitt.)

Unproblematisch sind diese Fälle, soweit es sich um gerätespezifische Cookies wie "device" oder "browser_tested" handelt, aber bei anderen Cookies ist dann gleiches Verhalten der Box auf verschiedenen Geräten nicht möglich.

Die Lösung ist: Nach der Anmeldung wird die Benutzer*in auf die Diskrepanz hingewiesen und ihr die Möglichkeit gegeben, der Genehmigung explizit Priorität gegenüber dem Verbot zu erteilen.

Gesamtverhalten

Man sieht: Diese Implementierung ist keineswegs trivial, aber sie bietet im Regelfall für die Benutzer*in deutliche Vorteile:

• Es wird nicht fahrlässig versäumt, die Benutzer*in zur Genehmigung von Cookies, die ihr ja bei key.matiq8 nur Vorteile bieten, zu motivieren. Es wäre schade, ihr Schaden, wenn wir die Möglichkeiten zur Erhöhung von Sicherheit, Bedienbarkeit und Bequemlichkeit verspielen würden, weil wir der Angewohnheit sicherheitsbewusster Benutzer*innen, optionale Cookies abzulehnen (was ja bei vielen Diensten völlig berechtigt ist) nicht im Fall von key.matiq begründet entgegentreten würden.
• Der Benutzer*in werden die Vorteile nicht nur allgemein, sondern immer auch konkret mit Bezug auf die vom jeweiligen Cookie unterstützten Features dargestellt.
• Die Benutzer*in hat minimalen Aufwand, sich damit zu beschäftigen, da sie (bis auf das Cookie "device") nicht für jedes Gerät einzeln genehmigen muss, sondern bereits Box-ebene die Auswahl der zu genehmigenden Cookies treffen und auch auf derselben Ebene Veränderungen vornehmen kann. Auch die Ticket-Erstellung und -Bearbeitung wird entsprechend einfach gehalten.
• Der Normalfall wird jeweils einfach gehalten. Nur die Ausnahmen werden gesondert behandelt.

1) Dieser Abschnitt überschneidet sich inhaltlich mit dem Artikel Web-Speicher. Doch dort werden nur die Cookies als solche sachlich beschrieben, während es hier um die Motivation geht, das Verfahren für die Cookies optimal zu halten: Hier wird daher ausführlicher argumentiert, warum es wichtig ist, der Benutzer*in nicht einfach nur die Cookies anzubieten, sondern auch zu empfehlen, warum das Genehmigungsverfahren daher für die Benutzer*in möglichst einfach, aber auch zielgerichtet gehalten werden sollte. Ohne dieses Verständnis würde wohl kaum klar, warum key.matiq den für die Cookie-Genehmigungen beschriebenen Aufwand betreibt. Siehe auch den Blog-Artikel "Die leidigen Cookies".

2) Werden für eine Box z. B. bestimmte optionale Cookies erlaubt, will die Nutzer*in dies aber für ein Gerät verbieten, muss, um diese kokurrierende Einstellung richtig zu handhaben, in dem Cookie "cookie_approvals" ein Timestamp enthalten sein, wann die optionalen Cookies für das Gerät verboten wurden. Nur so kann key.matiq feststellen, welche der beiden konkurrierenden Einstellungen jüngeren Datums ist und damit die Prioriät genießt.

3) Damit nicht unnötig der Gast Informationen über die Besitzer*in erhält, werden Cookies wie "box_id" und "ticket_id" gelöscht, Genehmigungen (im Cookie "cookie_approvals") aber gerettet. Bei Beendigung des Gastzugangs werden die (im Cookie "guest" geretteten) Genehmigungen wieder restauriert, und die Cookies "box_id" und "ticket_id" des Gastes gelöscht.
Während eines Gastzugangs kann der Gast eigene Genehmigungen erteilen, ist aber bezüglich Verboten eingeschränkt: Das Cookie "device_id" darf er nicht verbieten, da dieses für eine evtl. Zwei-Faktor-Authentisierung der Eigentümerin des Geräts erhalten bleiben sollte.

4) Es wird im englischen Sprachraum auch "Principle of least astonishment" (POLA) genannt.

5) Sie können z. B. außerhalb der Anmeldung auf Geräte-Ebene gegeben worden sein. Sie können auch von einer anderen (früheren) Anmeldung an eine andere Box (an ein anderes Ticket) stammen, bei der Genehmigungen von dieser anderen Box (diesem anderen Ticket) in die Genehmigungen des Geräts übernommen wurden.

6) Das geschieht durch Angabe eines Ablaufzeitpunkts, der in der Vergangenheit liegt.

7) Alles andere wäre schädlich: Es gibt zwar viele Stellen, wo Cookies außerhalb der Einstellungsseite genehmigt werden können, aber dort liegt der Fokus jeweils auf der Funktionalität (dem Zweck, dem das Cookie dienen soll). Eine Bestimmung der Lebenszeit an diesen Stellen würde davon ablenken.

8) Wir verwenden bei key.matiq ausschließlich funktionelle Cookies, also nur solche, die die Funktionalität erhöhen. Cookies für Statistik, Marketing-Zwecke etc. brauchen wir nicht.