Cookies gehören zu den ältesten und gleichzeitig missverstandensten Mechanismen des Webs.
Für manche sind Cookies etwas, das man bei jedem Websitebesuch reflexartig „akzeptieren“ muss. Andere verbinden damit ausschließlich Werbung und Überwachung. Technisch betrachtet sind Cookies zunächst wesentlich unspektakulärer: Sie ermöglichen einer Website, kleine Zustandsinformationen im Browser zu speichern und bei späteren HTTP-Anfragen wieder zu erhalten.
Das kann notwendig sein, um zu wissen:
Dieser Browser
↓
gehört weiterhin zu derselben Sitzung
oder:
Dieser Besucher
↓
hat Sprache Deutsch gewählt
oder:
Dieser Warenkorb
↓
enthält drei Produkte
Genau derselbe technische Mechanismus kann jedoch auch verwendet werden, um einen Browser über längere Zeit wiederzuerkennen und dessen Verhalten auszuwerten.
Der entscheidende Grundsatz lautet deshalb:
Ein Cookie ist zunächst eine Technik. Erst sein Zweck und die damit verbundene Verarbeitung entscheiden darüber, ob daraus ein Datenschutz- oder Trackingproblem wird.
Warum Websites überhaupt einen Zustand speichern müssen
HTTP ist grundsätzlich darauf ausgelegt, einzelne Anfragen und Antworten zu übertragen. Der Server erhält eine Anfrage, beantwortet sie und muss ohne zusätzliche Mechanismen nicht automatisch wissen, dass die nächste Anfrage vom selben Browser zur selben Sitzung gehört.
Cookies schaffen eine Möglichkeit, Zustand über mehrere Anfragen hinweg zu erhalten. Der aktuelle IETF-Standard RFC 10025 beschreibt Cookies genau als Mechanismus, mit dem Server über die HTTP-Header Set-Cookie und Cookie Zustand bei einem User Agent speichern und später wiederverwenden können. (auth48-transition.rfc-editor.org)
Vereinfacht:
Browser
↓
GET /shop
↓
Server
Der Server antwortet:
Set-Cookie: session=abc123
Bei einer späteren Anfrage kann der Browser das passende Cookie zurücksenden:
Cookie: session=abc123
Nun kann der Server erkennen:
abc123
↓
gehört zur bestehenden Sitzung
↓
Warenkorb / Loginstatus / Einstellungen
Das Cookie muss also nicht den kompletten Warenkorb enthalten. Häufig enthält es lediglich eine Kennung, über die der Server den zugehörigen Zustand in seiner eigenen Datenbank findet. RFC 10025 beschreibt Session-Identifier ausdrücklich als übliches Modell für solche Zustandsinformationen. (auth48-transition.rfc-editor.org)
Ein Cookie besteht aus Name und Wert
Ein sehr einfaches Cookie könnte technisch etwa so aussehen:
Set-Cookie: language=de
Der Name lautet:
language
und der Wert:
de
Hinzu können Eigenschaften kommen, die beispielsweise bestimmen:
wie lange das Cookie existiert,
für welche Domain es gilt,
für welchen Pfad es gesendet wird,
ob es ausschließlich über sichere Verbindungen übertragen werden soll
oder ob JavaScript darauf zugreifen darf. RFC 10025 definiert dafür unter anderem Expires, Max-Age, Domain, Path, Secure, HttpOnly und SameSite. (auth48-transition.rfc-editor.org)
Ein Cookie kann beispielsweise so aussehen:
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
Damit enthält ein kleiner Textwert bereits mehrere technische Regeln.
Was ist ein Session-Cookie?
Wird keine dauerhafte Lebenszeit definiert, kann ein Cookie als Sitzungscookie behandelt werden und grundsätzlich mit dem Ende der Browsersitzung auslaufen. Die genaue Sitzungshandhabung obliegt dabei dem Browser. RFC 10025 unterscheidet solche Cookies von persistenten Cookies mit definierter Lebensdauer. (auth48-transition.rfc-editor.org)
Ein typischer Zweck könnte sein:
Browser öffnet Shop
↓
Warenkorb entsteht
↓
Besuch dauert an
↓
Session endet
Session-Cookie bedeutet aber nicht automatisch technisch notwendig.
Das ist eine wichtige Trennung.
Session / persistent
→ technische Lebensdauer
notwendig / nicht notwendig
→ rechtliche und funktionale Beurteilung
Ein Trackingcookie kann theoretisch nur kurz existieren. Ein notwendiges Cookie kann umgekehrt länger benötigt werden.
Was ist ein persistentes Cookie?
Ein persistentes Cookie besitzt eine über die aktuelle Sitzung hinausgehende Lebensdauer, beispielsweise über Expires oder Max-Age. Der Browser kann es dann bei einem späteren Besuch erneut verwenden, sofern es nicht vorher gelöscht wird. (auth48-transition.rfc-editor.org)
Ein sinnvoller Anwendungsfall wäre etwa eine dauerhaft gespeicherte Spracheinstellung:
Besuch 1
↓
Deutsch gewählt
↓
Cookie gespeichert
Tage später
↓
Besuch 2
↓
Deutsch wieder verwenden
Die Europäische Kommission verwendet genau solche Spracheinstellungen als typisches Beispiel für Cookies, die Präferenzen speichern. (European Commission)
Was bedeutet First-Party-Cookie?
Ein First-Party-Cookie beziehungsweise Erstanbieter-Cookie gehört zur Website, die der Nutzer gerade besucht.
Besuchst du:
shop.example
und diese Website setzt einen zu ihr gehörenden Cookie, sprechen wir grundsätzlich von einem First-Party-Kontext.
Die Europäische Kommission beschreibt First-Party-Cookies entsprechend als Cookies, die von der besuchten Website selbst gesetzt und kontrolliert werden. (European Commission)
Was bedeutet Third-Party-Cookie?
Eine Website kann Ressourcen anderer Anbieter einbinden.
Zum Beispiel:
Videoplayer,
Werbenetzwerk,
Social-Media-Plugin,
Analysewerkzeug.
Dadurch kann neben der besuchten Website eine weitere Domain beteiligt werden.
website.example
↓
lädt Ressource von
↓
dienst.example
Cookies dieses fremden Dienstes werden traditionell als Third-Party-Cookies beziehungsweise Drittanbieter-Cookies bezeichnet. Auch diese technische Unterscheidung beschreibt die Europäische Kommission entsprechend. (European Commission)
First Party bedeutet nicht automatisch datenschutzfreundlich
Das ist einer der häufigsten Denkfehler.
First Party
≠
automatisch notwendig
Ein Websitebetreiber könnte einen eigenen First-Party-Identifier setzen und damit das Verhalten eines Besuchers über Monate analysieren.
Technisch wäre es ein First-Party-Cookie.
Sein Zweck könnte trotzdem Tracking sein.
Umgekehrt sollte die rechtliche Beurteilung eines Cookies nicht allein aus dem Etikett „Third Party“ abgeleitet werden. Entscheidend ist insbesondere, welche Speicherung beziehungsweise welcher Zugriff erfolgt, ob die Ausnahme für einen ausdrücklich gewünschten Dienst greift und welche anschließende Datenverarbeitung stattfindet. Die österreichische Datenschutzbehörde trennt deshalb ausdrücklich nach technischer Notwendigkeit und nicht schlicht nach First oder Third Party. (Österreichische Datenschutzbehörde)
Ein Cookie ist auch nicht automatisch personenbezogen
Die österreichische Datenschutzbehörde weist ausdrücklich darauf hin, dass die Information in einem Cookie nicht per se personenbezogen oder nicht personenbezogen ist. Entscheidend ist, was gespeichert wird und ob diese Information mit einer bestimmten oder bestimmbaren Person verbunden werden kann. (Österreichische Datenschutzbehörde)
Eine isolierte Spracheinstellung:
language=de
kann beispielsweise keinen Personenbezug besitzen.
Eine eindeutige Kennung:
visitor=550e8400-e29b-41d4-a716-446655440000
kann dagegen dazu dienen, einen Browser wiederzuerkennen und dessen Aktivitäten zusammenzuführen. Wird diese Kennung mit einem Kundenkonto, einer E-Mail-Adresse oder anderen Informationen verbunden, kann ein klarer Personenbezug entstehen. Die DSB nennt solche eindeutigen Online-Kennungen ausdrücklich als relevante Konstellation. (Österreichische Datenschutzbehörde)
Warum Tracking Kennungen braucht
Tracking versucht, mehrere einzelne Ereignisse miteinander zu verbinden.
Ohne Wiedererkennung sieht ein Analysesystem vielleicht:
Seitenaufruf A
Seitenaufruf B
Seitenaufruf C
Es weiß aber nicht zwingend, ob diese Ereignisse zusammengehören.
Mit einer Kennung:
Besucher 4711
├── Startseite
├── Produkt A
├── Produkt B
└── Bestellung
entsteht eine zusammenhängende Nutzungsgeschichte.
Tracking bedeutet daher häufig nicht, dass der Betreiber sofort den bürgerlichen Namen kennt.
Es genügt zunächst:
derselbe Browser
oder
dasselbe Gerät
oder
dasselbe Konto
über mehrere Ereignisse hinweg wiedererkennen zu können.
Die österreichische Datenschutzbehörde weist darauf hin, dass solche Online-Kennungen mit weiteren Informationen kombiniert und beispielsweise mit registrierten Nutzerkonten oder Profilen verknüpft werden können. (Österreichische Datenschutzbehörde)
Tracking kann sehr unterschiedliche Reichweiten haben
Eine einfache Webanalyse könnte nur erfassen:
Besucher 4711
↓
Seite A
↓
Seite B
↓
Seite C
innerhalb derselben Website.
Ein größeres Werbesystem könnte Aktivitäten über mehrere Angebote hinweg verbinden:
Website A
↓
Kennung X
Website B
↓
Kennung X
Website C
↓
Kennung X
Aus vielen einzelnen Ereignissen können anschließend Interessen oder Nutzerprofile abgeleitet werden.
Die österreichische Datenschutzbehörde ordnet insbesondere Dienste, die Nutzerverhalten auf einer oder mehreren Websites beziehungsweise über Geräte hinweg aufzeichnen und auswerten, als technisch nicht notwendige Dienste ein. (Österreichische Datenschutzbehörde)
Tracking ist nicht dasselbe wie Statistik
Eine Website kann wissen wollen:
Wie viele Menschen lesen einen Artikel?
Welche Seite wird häufig verlassen?
Welche Navigation funktioniert schlecht?
Das sind legitime Analysefragen.
Daraus folgt allerdings nicht automatisch, dass dafür jeder Besucher langfristig individuell identifiziert werden muss.
Frage:
Wie oft wurde Artikel A gelesen?
ist etwas anderes als:
Frage:
Was hat Browser 4711
in den letzten sechs Monaten
auf mehreren Websites gemacht?
Die Datenschutz-Grundprinzipien aus Datenschutz verstehen bleiben deshalb relevant: Zweck und benötigte Datenmenge sollten zueinander passen.
Nicht jedes Tracking braucht Cookies
Das ist für modernes Webverständnis entscheidend.
Die ePrivacy-Regel ist keine reine „Cookie-Regel“.
Der Europäische Datenschutzausschuss stellt in seinen finalen Leitlinien 2/2023 ausdrücklich klar, dass Art. 5 Abs. 3 der ePrivacy-Richtlinie nicht ausschließlich Cookies umfasst. Auch andere Technologien können darunter fallen, wenn Informationen auf dem Endgerät gespeichert oder daraus ausgelesen werden. Der EDPB behandelt beispielsweise URL- und Pixeltracking, lokale Verarbeitung, bestimmte IP-basierte Verfahren und eindeutige Kennungen.
Das bedeutet:
Cookies abschalten
≠
Tracking automatisch beendet
Tracking-Pixel
Ein Tracking-Pixel ist häufig eine sehr kleine beziehungsweise unsichtbare Ressource, die in eine Website oder E-Mail eingebunden wird.
Beim Laden entsteht eine Anfrage an einen Server.
Website / E-Mail
↓
Pixel eingebettet
↓
Browser oder Mailclient lädt Pixel
↓
Server erhält Anfrage
Der EDPB beschreibt Tracking-Pixel ausdrücklich als eingebettete Ressourcen, deren Abruf eine zusätzliche Kommunikation zum Host auslösen kann. In E-Mails kann damit beispielsweise erkannt werden, dass eine Nachricht geöffnet wurde; auf Websites können solche Abrufe zur Verhaltensanalyse verwendet werden.
Das Bild selbst ist dabei möglicherweise vollkommen unwichtig.
Relevant ist:
Abruf fand statt
+
Kennung
+
Zeitpunkt
+
Kontext
Tracking-Links
Auch die URL selbst kann eine Kennung enthalten.
Beispielsweise:
produkt.example/?campaign=4711
oder eine nutzerspezifischere Kennung.
Beim Aufruf gelangt der Parameter an den Zielserver.
Der EDPB nennt solche Tracking-Links ausdrücklich und beschreibt unter anderem Affiliate-Marketing als mögliches Einsatzgebiet: Ein Anbieter kann darüber erkennen, welcher Partner einen Besucher beziehungsweise Verkauf vermittelt hat.
Das ist ein gutes Beispiel dafür, warum die Beurteilung nicht bei Cookies enden kann.
Local Storage
Browser bieten neben Cookies weitere Speichermechanismen.
Webanwendungen können beispielsweise Informationen lokal im Browser speichern und später wieder verwenden.
Der EDPB nennt ausdrücklich Browsertechnologien wie Cookies und Local Storage als mögliche auf dem Endgerät gespeicherte Informationen. Entscheidend für Art. 5 Abs. 3 ist nicht der Produktname der Speichertechnik, sondern ob Informationen auf dem Endgerät gespeichert oder von dort zugänglich gemacht werden.
Deshalb ist die Aussage:
Wir verwenden keine Cookies,
nur Local Storage.
rechtlich kein automatischer Ausweg.
Fingerprinting
Beim Device beziehungsweise Browser Fingerprinting versucht ein System, aus Eigenschaften eines Geräts oder Browsers eine möglichst charakteristische Kombination zu bilden.
Konzeptionell:
Eigenschaft A
+
Eigenschaft B
+
Eigenschaft C
+
Eigenschaft D
↓
charakteristisches Muster
Das kann Wiedererkennung ermöglichen, ohne einen klassischen Identifier als Cookie zu speichern.
Der EDPB stellt ausdrücklich klar, dass Fingerprinting grundsätzlich vom technischen Anwendungsbereich von Art. 5 Abs. 3 ePrivacy erfasst sein kann und verweist dazu auf seine bisherigen Leitlinien sowie die frühere Stellungnahme der Artikel-29-Gruppe.
Damit wird ein wichtiger Grundsatz sichtbar:
Cookieverbote dürfen nicht einfach dadurch umgangen werden, dass dieselbe Trackingfunktion mit einer anderen Technik nachgebaut wird.
Tracking nur über die IP-Adresse?
Auch hier ist die Antwort nicht schlicht:
kein Cookie
→ keine ePrivacy-Frage
Die finalen EDPB-Leitlinien untersuchen ausdrücklich Trackinglösungen, die nur IP-Adressen verwenden. Ob Art. 5 Abs. 3 technisch greift, hängt dabei unter anderem davon ab, ob die betreffende Information aus dem Endgerät des Nutzers stammt; der EDPB betont zugleich, dass die technische Anwendbarkeit des Artikels noch nicht automatisch bedeutet, dass in jedem Fall Einwilligung erforderlich ist – die Ausnahmen müssen separat geprüft werden.
Für die Praxis ist daher die sichere Denkweise:
Trackingtechnik ändern
↓
rechtliche Prüfung erneut durchführen
und nicht:
Cookie entfernt
↓
rechtliches Problem gelöst
Server-Side-Tracking ist ebenfalls kein Freibrief
Bei serverseitigem Tracking werden bestimmte Verarbeitungsschritte vom Browser auf eine Serverinfrastruktur verlagert.
Das kann technische, Performance- und Sicherheitsvorteile besitzen.
Rechtlich muss aber weiterhin geprüft werden:
Welche Informationen kommen vom Endgerät?
Was wurde dort gespeichert oder ausgelesen?
Welche personenbezogenen Daten verarbeitet der Server?
Welche Zwecke bestehen?
Welche Empfänger sind beteiligt?
Der EDPB betrachtet ausdrücklich auch Konstellationen, in denen die Stelle, die eine Übermittlung vom Endgerät veranlasst, und die Stelle, die die Informationen letztlich empfängt, nicht identisch sind.
Die Architektur entscheidet also nicht allein über die Rechtmäßigkeit.
Zwei Rechtsebenen müssen getrennt werden
Beim Website-Tracking werden häufig DSGVO und Cookie-Regeln in einen Topf geworfen.
Besser ist eine Trennung.
Ebene 1: Zugriff auf das Endgerät
Hier geht es um:
Information speichern
oder
Information auslesen
auf:
Browser,
Smartphone,
Computer
oder einem anderen erfassten Endgerät.
Diese Ebene stammt insbesondere aus Art. 5 Abs. 3 der ePrivacy-Richtlinie und deren nationaler Umsetzung. Der EDPB betont ausdrücklich, dass der Begriff dort Information lautet und nicht auf personenbezogene Daten begrenzt ist.
Ebene 2: anschließende Verarbeitung personenbezogener Daten
Werden die erhaltenen Informationen anschließend einer Person zugeordnet beziehungsweise als personenbezogene Daten verarbeitet, kommt zusätzlich die DSGVO ins Spiel.
Dann stellen sich beispielsweise Fragen nach:
Zweck,
Rechtsgrundlage,
Empfängern,
Speicherdauer,
Betroffenenrechten,
Drittlandtransfers.
Die österreichische Datenschutzbehörde trennt diese Ebenen ausdrücklich: Ein Verstoß gegen die Endgeräte-Regel und die anschließende Verarbeitung personenbezogener Trackingdaten können unterschiedliche rechtliche Fragestellungen auslösen. (Österreichische Datenschutzbehörde)
Deshalb können Cookie-Regeln auch nicht personenbezogene Informationen schützen
Das wirkt zunächst überraschend.
Ein Cookie enthält möglicherweise überhaupt kein personenbezogenes Datum.
Trotzdem kann der Zugriff auf das Endgerät von Art. 5 Abs. 3 erfasst sein.
Der EDPB stellt ausdrücklich klar, dass die dort verwendete Kategorie „Information“ breiter ist als der DSGVO-Begriff personenbezogener Daten. Der EuGH hat dies ebenfalls im Zusammenhang mit der Endgeräte-Sphäre bestätigt.
Das mentale Modell lautet:
ePrivacy
→ schützt Zugriff auf Endgerät
DSGVO
→ schützt personenbezogene Datenverarbeitung
Beide Ebenen können gleichzeitig relevant sein.
Die österreichische Regel für Cookies
Für Österreich setzt § 165 Abs. 3 TKG 2021 die europäische Vorgabe um. Die österreichische Datenschutzbehörde fasst die praktische Grundregel so zusammen: Ohne vorherige Einwilligung dürfen Cookies beziehungsweise entsprechende Zugriffe insbesondere dann erfolgen, wenn sie unbedingt erforderlich sind, um einen vom Nutzer ausdrücklich gewünschten Dienst bereitzustellen. Für technisch nicht notwendige Cookies ist grundsätzlich vorherige Einwilligung erforderlich. (Österreichische Datenschutzbehörde)
Das ist wesentlich präziser als die oft verwendete Faustregel:
Cookies
→ immer Einwilligung
Denn manche Cookies sind für die verlangte Funktion tatsächlich notwendig.
Was bedeutet „technisch notwendig“?
Die österreichische Datenschutzbehörde nennt beispielsweise als typische notwendige Konstellationen:
notwendige Sitzungsverwaltung,
Warenkorbfunktion während eines Onlinekaufs,
Speicherung des Loginstatus,
mehrseitige Formulare,
bestimmte Speicherung der bereits getroffenen Consent-Entscheidung. (Österreichische Datenschutzbehörde)
Beispiel:
Nutzer legt Produkt
in Warenkorb
↓
Website muss Warenkorb
über weitere Seiten erhalten
Ein dafür erforderlicher Sitzungsmechanismus dient unmittelbar einer vom Nutzer gewünschten Funktion.
„Wir brauchen Werbung zum Geldverdienen“ bedeutet nicht technisch notwendig
Technische Notwendigkeit ist enger als wirtschaftliche Notwendigkeit.
Eine Website kann argumentieren:
Ohne personalisierte Werbung
verdienen wir weniger.
Daraus wird ein Werbetracker jedoch nicht technisch notwendig, um die vom Nutzer angeforderte Websitefunktion bereitzustellen. Die österreichische Datenschutzbehörde weist ausdrücklich darauf hin, dass wirtschaftliche Finanzierungsinteressen die technische Notwendigkeit eines Werbe-Cookies nicht begründen. (Österreichische Datenschutzbehörde)
Das ist eine wichtige Grenze:
geschäftlich erwünscht
≠
technisch unbedingt erforderlich
Analyse ist nicht automatisch notwendig
Ein Betreiber möchte verständlicherweise wissen:
Wie viele Besucher kommen?
Welche Inhalte funktionieren?
Wo springen Nutzer ab?
Das macht Analyse geschäftlich sinnvoll.
Es macht sie jedoch nicht automatisch zu einer technisch unverzichtbaren Funktion des vom Besucher ausdrücklich gewünschten Dienstes.
Die österreichische Datenschutzbehörde ordnet insbesondere Dienste zur Aufzeichnung und Auswertung des Nutzerverhaltens als technisch nicht notwendig ein. (Österreichische Datenschutzbehörde)
Für die konkrete Umsetzung einer Analyselösung muss daher deren tatsächliche Technik und rechtliche Konstruktion geprüft werden.
Wann braucht man überhaupt ein Cookiebanner?
Die Antwort ist einfacher, als die heutige Weblandschaft vermuten lässt.
Die österreichische Datenschutzbehörde sagt ausdrücklich:
Verwendet eine Website ausschließlich technisch notwendige Cookies, ist keine Einwilligung erforderlich und damit auch kein Cookiebanner zur Einholung dieser Einwilligung notwendig. (Österreichische Datenschutzbehörde)
Das bedeutet:
nur notwendige Technik
↓
kein künstliches
„Alle Cookies akzeptieren“
erforderlich
Eine Datenschutzerklärung beziehungsweise notwendige Informationspflichten können natürlich trotzdem bestehen.
Ein Cookiebanner ist kein gesetzliches Dekorationselement
Ein Cookiebanner hat eine konkrete Aufgabe:
Einwilligung benötigt
↓
Nutzer informieren
↓
echte Entscheidung ermöglichen
↓
Entscheidung dokumentieren
Wenn keinerlei einwilligungsbedürftige Technik eingesetzt wird, erzeugt ein Banner möglicherweise nur unnötige Reibung.
Das ist ein gutes Beispiel für Privacy by Design:
Die einfachste Consent-Lösung kann darin bestehen, weniger einwilligungsbedürftige Technik einzubauen.
Erst Zustimmung, dann nicht notwendige Technik
Ein häufiger Implementierungsfehler lautet:
Website lädt
↓
Tracking startet
↓
Cookiebanner erscheint
↓
Nutzer wird gefragt
Die Frage kommt dann zu spät.
Die österreichische Datenschutzbehörde verlangt ausdrücklich, dass technisch nicht notwendige Cookies erst nach der erforderlichen Einwilligung gesetzt beziehungsweise ausgelesen werden. (Österreichische Datenschutzbehörde)
Der richtige Ablauf:
Website lädt
↓
nur notwendige Dienste
↓
Consent-Entscheidung
├── Nein
│ ↓
│ nicht notwendige Dienste bleiben aus
│
└── Ja
↓
freigegebene Dienste starten
Consent Management bedeutet daher technisches Blockieren
Ein Cookiebanner, das nur Text anzeigt, reicht nicht.
Das Consent-System muss technisch steuern können:
Kategorie nicht freigegeben
↓
zugehöriger Dienst startet nicht
Bei Drittanbieter-Videos kann das beispielsweise bedeuten:
Seite lädt
↓
lokales Vorschaubild
↓
externer Player noch nicht geladen
↓
Nutzer gibt passende Freigabe
↓
externer Inhalt wird eingebettet
Auch die Europäische Kommission verwendet auf ihren Websites ein solches Prinzip für bestimmte externe Inhalte: Drittanbieter-Inhalte werden erst nach der entsprechenden Zustimmung geladen. (European Commission)
Eine gültige Einwilligung benötigt eine echte Handlung
Im vorherigen Artikel haben wir die DSGVO-Anforderungen bereits behandelt.
Für Cookie-Consent sind sie besonders praktisch relevant.
Eine Einwilligung muss unter anderem:
freiwillig,
informiert,
spezifisch
und eindeutig
sein und durch eine aktive bestätigende Handlung erfolgen. Vorangekreuzte Kästchen erfüllen diese Anforderungen nicht. (European Commission)
Deshalb ist:
[✓] Marketing
als vorausgewählte Zustimmung problematisch.
Richtig ist grundsätzlich:
[ ] Marketing
und der Nutzer entscheidet aktiv.
Weitersurfen ist keine ausreichende Zustimmung
Ein Banner sagt:
Wenn Sie diese Website weiterverwenden, stimmen Sie allen Cookies zu.
Der Nutzer scrollt.
Damit liegt nicht automatisch eine eindeutige aktive Einwilligung vor.
Die österreichische Datenschutzbehörde stellt ausdrücklich klar, dass bloßes Weitersurfen ohne Interaktion mit dem Banner nicht als unmissverständliche Zustimmung gewertet werden kann. (Österreichische Datenschutzbehörde)
„Akzeptieren“ und „Ablehnen“ müssen echte Optionen sein
Die österreichische Datenschutzbehörde formuliert für Cookiebanner einen besonders klaren Grundsatz:
Die Nichtabgabe einer Einwilligung muss genauso einfach sein wie ihre Abgabe.
Wenn:
Alle akzeptieren
mit einem Klick möglich ist, darf ein Nutzer nicht erst:
Einstellungen
↓
Weitere Einstellungen
↓
Marketing
↓
Analyse
↓
alles einzeln deaktivieren
↓
speichern
müssen, nur um abzulehnen. Die DSB verlangt ausdrücklich, dass eine Ablehnung nicht mehr Interaktionen benötigt als die Zustimmung. Auch die Europäische Kommission beschreibt 2026 das Prinzip, dass „Nein“ genauso einfach sein soll wie „Ja“. (Österreichische Datenschutzbehörde)
Gestaltung darf die Entscheidung nicht manipulieren
Stell dir ein Banner vor:
[ ALLE AKZEPTIEREN ]
groß, farbig und dominant.
Daneben:
Ablehnen
fast unsichtbar in hellgrauer Schrift.
Technisch existieren zwar zwei Möglichkeiten.
Gestalterisch werden sie aber nicht gleichwertig präsentiert.
Die österreichische Datenschutzbehörde warnt ausdrücklich vor solchen unfairen Praktiken beziehungsweise „Nudging“. Ein Ablehnungsbutton darf nicht so gestaltet oder positioniert werden, dass er gegenüber der Zustimmung deutlich weniger wahrgenommen wird. (Österreichische Datenschutzbehörde)
Das verbindet Datenschutz unmittelbar mit UI Design und visueller Hierarchie.
Es gibt keine vorgeschriebene Buttonfarbe
Datenschutzrecht verlangt nicht:
Akzeptieren = grün
Ablehnen = rot
oder umgekehrt.
Die österreichische Datenschutzbehörde stellt klar, dass keine universelle Farbe vorgeschrieben ist. Entscheidend ist, ob die Gestaltung zu einer fairen und freien Entscheidung führt. Ein praktisch unsichtbarer Ablehnungsbutton kann die Gültigkeit der Einwilligung beeinträchtigen. (Österreichische Datenschutzbehörde)
Kategorien müssen verständlich sein
Ein Banner mit:
Notwendig
Statistik
Marketing
Externe Medien
kann übersichtlicher sein als eine Liste aus 74 technischen Cookie-Namen.
Doch die Kategorien müssen tatsächlich erklären, wofür die Einwilligung erfolgt.
Bezeichnungen wie:
Optimierung
oder:
Komfort
können zu unbestimmt sein, wenn dahinter beispielsweise umfangreiches Werbetracking steckt.
Die DSGVO verlangt bei Einwilligung eine spezifische und informierte Entscheidung; die österreichische Datenschutzbehörde verlangt im Banner unter anderem eine genaue Beschreibung der Zwecke sowie Informationen über den Widerruf. (European Commission)
Ein Banner darf Informationen auf mehrere Ebenen verteilen
Das bedeutet nicht, dass der gesamte juristische Datenschutzhinweis in einem 600 Pixel hohen Pop-up stehen muss.
Die österreichische Datenschutzbehörde beschreibt ausdrücklich einen Mehrebenen-Ansatz:
Ebene 1
→ Cookiebanner
→ zentrale Entscheidungsinformationen
Ebene 2
→ Datenschutzerklärung
→ vollständige Details
Auf der ersten Ebene sollten nach Ansicht der Behörde insbesondere Verantwortlicher, Zwecke, Rechtsgrundlage, Widerrufsmöglichkeit und der Weg zum Widerruf erkennbar sein. (Österreichische Datenschutzbehörde)
Das Cookiebanner ersetzt die Datenschutzerklärung nicht
Das Banner erfüllt primär eine Consent- und Kurz-Informationsfunktion.
Die Datenschutzerklärung behandelt die vollständige personenbezogene Datenverarbeitung wesentlich breiter.
Cookiebanner
→ Entscheidung über bestimmte Technologien
Datenschutzerklärung
→ vollständige Information
über relevante Datenverarbeitungen
Eine Website ohne Tracking kann daher trotzdem eine Datenschutzerklärung benötigen.
Und eine Website mit perfektem Cookiebanner kann trotzdem Datenschutzprobleme besitzen.
Einwilligung muss widerrufbar bleiben
Ein Cookiebanner ist kein einmaliger Vertrag für die Ewigkeit.
Wenn die Verarbeitung auf Einwilligung beruht, muss diese wieder widerrufen werden können. Die DSGVO verlangt, dass ein Widerruf möglich ist; die österreichische Datenschutzbehörde betont zusätzlich, dass er so einfach wie die Erteilung sein muss. (European Commission)
Der Nutzer sollte also später einen nachvollziehbaren Weg finden:
Cookie-Einstellungen
↓
Marketing deaktivieren
↓
Entscheidung speichern
Nicht:
E-Mail an Datenschutzabteilung
↓
Formular herunterladen
↓
unterschreiben
↓
zwei Wochen warten
Was passiert nach einem Widerruf?
Mindestens die auf der widerrufenen Einwilligung beruhende weitere Verarbeitung darf nicht einfach fortgesetzt werden.
Technisch bedeutet das bei Website-Tracking beispielsweise:
Marketing-Consent widerrufen
↓
Marketing-Skripte künftig nicht laden
↓
entsprechende weitere Verarbeitung stoppen
Je nach eingesetzter Technologie muss außerdem geprüft werden, wie bereits gesetzte lokale Kennungen beziehungsweise Daten behandelt werden.
Der Widerruf macht die zuvor auf einer gültigen Einwilligung beruhende Verarbeitung nicht rückwirkend unrechtmäßig. (European Commission)
Consent selbst muss gespeichert werden
Das erzeugt eine interessante scheinbare Paradoxie.
Der Nutzer sagt:
Nein zu Tracking.
Die Website muss sich diese Entscheidung möglicherweise merken, damit sie nicht auf jeder Unterseite erneut fragt.
Dafür kann wiederum ein notwendiger Speichermechanismus eingesetzt werden.
Die österreichische Datenschutzbehörde nennt die Speicherung des Einwilligungsstatus grundsätzlich als mögliche technisch notwendige Funktion, solange dabei nicht unnötig eine eindeutige Online-Kennung erzeugt wird. (Österreichische Datenschutzbehörde)
Consent-Cookie
→ merkt sich:
Nein
Ein Cookie kann also gerade dazu dienen, weitere Cookies zu verhindern.
First Party und Third Party nochmals richtig einordnen
Für die Praxis hilft eine Matrix.
| Technische Eigenschaft | Aussage |
|---|---|
| First Party | Cookie gehört zur besuchten Website |
| Third Party | Cookie stammt aus einem anderen eingebundenen Kontext |
| Session | endet grundsätzlich mit der Sitzung |
| Persistent | besitzt längere gespeicherte Lebensdauer |
| Technisch notwendig | für ausdrücklich gewünschte Funktion unbedingt erforderlich |
| Tracking | dient der Wiedererkennung beziehungsweise Verhaltensauswertung |
Diese Eigenschaften können kombiniert auftreten.
Ein Cookie könnte:
First Party
+
persistent
+
Tracking
sein.
Ein anderes:
First Party
+
Session
+
notwendiger Warenkorb
Deshalb kann kein einzelnes Etikett die gesamte rechtliche Beurteilung ersetzen. Die DSB trennt ausdrücklich Lebensdauer, Domainzugehörigkeit und technische Notwendigkeit als unterschiedliche Fragen. (Österreichische Datenschutzbehörde)
Cookies haben auch Sicherheitsfunktionen
Cookies sind nicht nur Datenschutzelemente, sondern häufig Teil der Authentifizierung.
Nach erfolgreichem Login kann eine Website beispielsweise eine Session-ID im Cookie speichern:
Login erfolgreich
↓
Session-ID
↓
Cookie
↓
weitere Seiten erkennen
angemeldete Sitzung
Darum können Cookies selbst sicherheitskritische Zugangsinformationen darstellen.
Secure
Das Attribut:
Secure
weist den Browser an, das betreffende Cookie nur über einen sicheren Kommunikationskanal – typischerweise HTTPS – zu übertragen. RFC 10025 definiert diesen Schutz ausdrücklich. (auth48-transition.rfc-editor.org)
Das verbindet Cookies unmittelbar mit SSL und HTTPS.
HttpOnly
Ein Cookie mit:
HttpOnly
soll nicht über normale nicht-HTTP-Schnittstellen wie typische JavaScript-Cookiezugriffe bereitgestellt werden. Das kann insbesondere für Session-Cookies eine zusätzliche Schutzebene darstellen. (auth48-transition.rfc-editor.org)
Es bedeutet allerdings nicht:
HttpOnly
→ Cookie unstehlbar
Sicherheitsattribute lösen jeweils bestimmte Angriffsklassen.
SameSite
SameSite beeinflusst, in welchen Same-Site- beziehungsweise Cross-Site-Kontexten ein Cookie gesendet werden darf. RFC 10025 definiert die Werte Strict, Lax und None. Das Attribut kann insbesondere als zusätzliche Schutzschicht gegen bestimmte Cross-Site-Angriffe dienen. (auth48-transition.rfc-editor.org)
Wichtig:
SameSite ist primär ein Sicherheitsmechanismus.
Es beantwortet nicht automatisch:
Darf dieses Trackingcookie
datenschutzrechtlich gesetzt werden?
RFC 10025 weist sogar ausdrücklich darauf hin, dass SameSite die allgemeinen Datenschutzprobleme von Cookies nicht als solche löst. (auth48-transition.rfc-editor.org)
Sicherheit und Datenschutz erneut trennen
Ein Cookie kann technisch hervorragend abgesichert sein:
Secure
+
HttpOnly
+
SameSite
und trotzdem für einen Zweck eingesetzt werden, der eine Einwilligung benötigt.
Umgekehrt wäre ein notwendiges Login-Cookie datenschutzrechtlich möglicherweise zulässig, aber technisch schlecht geschützt.
Rechtmäßigkeit
+
Sicherheit
müssen beide stimmen.
Was ist Webanalyse ohne Cookies?
Analyse lässt sich technisch auch ohne klassische persistente Cookies gestalten.
Beispielsweise könnten serverseitig aggregierte Seitenaufrufe ausgewertet oder kurzfristige Informationen verarbeitet werden.
Das bedeutet jedoch nicht automatisch:
cookie-frei
=
DSGVO-frei
Wenn dabei beispielsweise personenbezogene IP-Adressen oder andere Online-Kennungen verarbeitet werden, bleiben Datenschutzfragen bestehen. Auch der EDPB macht deutlich, dass Art. 5 Abs. 3 nicht auf klassische Cookies beschränkt ist und alternative Trackingverfahren separat beurteilt werden müssen.
Datenschutzfreundlichere Analyse beginnt beim Analyseziel
Vielleicht lautet die eigentliche Frage:
Welche unserer 100 Seiten
werden besonders häufig gelesen?
Dafür benötigt man möglicherweise keine sechsmonatige individuelle Besucherhistorie.
Ein sinnvoller Datenschutzprozess fragt deshalb zuerst:
Welche Entscheidung
wollen wir aus den Daten treffen?
und danach:
Welche kleinste Datenmenge
reicht dafür aus?
Das entspricht direkt dem Prinzip der Datenminimierung aus Datenschutz verstehen.
Eingebettete Videos und Karten
Eine Website kann Drittinhalte einbetten:
YouTube,
Karten,
Social Posts,
andere externe Medien.
Technisch kann der Browser dabei bereits beim Laden des eingebetteten Inhalts Kontakt mit dem Drittanbieter aufnehmen.
Website
↓
iframe / externes Script
↓
Browser verbindet sich
mit Drittanbieter
Dadurch können Daten übertragen beziehungsweise Endgerätemechanismen genutzt werden, bevor der Nutzer aktiv mit dem Inhalt interagiert.
Die Europäische Kommission blockiert bestimmte externe Inhalte auf ihren eigenen Seiten deshalb bis zur entsprechenden Zustimmung. (European Commission)
Zwei-Klick-Lösung
Ein datenschutzfreundlicheres Muster kann beispielsweise so aussehen:
Seite lädt
↓
lokales Vorschaubild
↓
„Externes Video laden“
↓
Nutzer entscheidet
↓
erst dann externer Player
Damit wird der Drittanbieter nicht allein deshalb kontaktiert, weil der Besucher eine Seite öffnet, die zufällig ein Video enthält.
Ob für eine konkrete Einbettung tatsächlich Einwilligung erforderlich ist, muss anhand der eingesetzten Technologie und Verarbeitung geprüft werden; das Muster zeigt aber, wie Privacy by Design technisch umgesetzt werden kann.
Social-Media-Buttons
Dasselbe Problem kann bei Social-Media-Plugins entstehen.
Ein sichtbarer Button:
Gefällt mir
kann technisch mehr sein als ein normaler Link.
Wenn bereits beim Seitenaufruf Code des sozialen Netzwerks geladen wird, können Informationen an den Anbieter gelangen.
Die österreichische Datenschutzbehörde nennt Social-Media-Plugins und Werbenetzwerke, deren Einbindung personenbezogene Daten von Websitebesuchern an Dritte übermittelt, ausdrücklich als Beispiele technisch nicht notwendiger Dienste. (Österreichische Datenschutzbehörde)
Eine einfache lokale Verlinkung:
<a href="https://...">Profil öffnen</a>
ist technisch eine andere Architektur als ein voll integriertes Trackingplugin.
Tag Manager löst das Consentproblem nicht
Ein Tag-Management-System hilft, Skripte zentral zu verwalten.
Es kann beispielsweise steuern:
Analytics
Marketing
Conversion
externe Dienste
Dadurch wird Consent technisch leichter umsetzbar.
Aber ein Tag Manager ist keine Rechtsgrundlage.
Consent fehlt
+
Tag Manager vorhanden
=
Consent fehlt weiterhin
Das System muss so konfiguriert werden, dass nicht freigegebene Dienste tatsächlich nicht vorzeitig ausgelöst werden.
Consent Management Platform ist ebenfalls kein Gütesiegel
Eine Website installiert ein bekanntes Consent-Plugin.
Damit ist die Datenschutzprüfung nicht erledigt.
Die österreichische Datenschutzbehörde warnt ausdrücklich davor, Consent-Tools oder Branchenstandards ungeprüft zu übernehmen. Nur weil ein Werkzeug als „Cookie Consent Tool“ angeboten wird, bedeutet das nicht automatisch, dass die konkrete Konfiguration rechtskonform ist. (Österreichische Datenschutzbehörde)
Das ist besonders wichtig bei WordPress:
Plugin installiert
≠
Website automatisch compliant
Denn möglicherweise lädt ein anderes Plugin bereits vor der Consent-Entscheidung externe Skripte.
Die Website muss technisch geprüft werden
Ein sinnvoller Ablauf lautet:
Website mit frischem Browserprofil öffnen
↓
vor Zustimmung Netzwerkverkehr prüfen
↓
Cookies und lokale Speicher prüfen
↓
externe Requests prüfen
↓
ablehnen
↓
erneut prüfen
↓
zustimmen
↓
erneut prüfen
Erst dadurch sieht man, ob die gewünschte Consent-Logik tatsächlich funktioniert.
Die österreichische DSB verweist selbst auf technische Beweismöglichkeiten zur Erfassung gesetzter Cookies und betont, dass technisch nicht notwendige Cookies vor Einwilligung nicht gesetzt werden dürfen. (Österreichische Datenschutzbehörde)
Warum ein leeres Browserprofil wichtig ist
Wenn du dieselbe Website bereits oft besucht hast, liegen möglicherweise alte:
Cookies,
Consent-Einstellungen,
Loginzustände
im Browser.
Dann testest du nicht den Erstbesuch.
Ein sauberer Test verwendet deshalb einen neuen beziehungsweise bereinigten Browserkontext.
So lässt sich beantworten:
Was passiert wirklich
beim allerersten Seitenaufruf?
Was sollte man für jedes Trackingwerkzeug dokumentieren?
Für eine praktische Websiteprüfung reichen einige Kernfragen:
| Frage | Beispiel |
|---|---|
| Was wird geladen? | Analysescript |
| Wer liefert es? | eigener oder externer Server |
| Welche Daten entstehen? | IP, Kennung, Seitenaufruf |
| Wird im Endgerät gespeichert/gelesen? | Cookie, Local Storage etc. |
| Zweck | Reichweitenanalyse |
| Ist es unbedingt notwendig? | prüfen |
| Rechtsgrundlage der Folgeverarbeitung | prüfen |
| Empfänger | Dienstleister / Dritter |
| Speicherfrist | festlegen |
| Drittlandtransfer | gegebenenfalls prüfen |
| Consent nötig? | aus Technik und Zweck ableiten |
So wird aus „Wir haben irgendein Analytics-Plugin“ ein nachvollziehbarer Datenfluss.
Der einfachste Datenschutzgewinn ist oft: Dienst entfernen
Viele Websites sammeln über Jahre immer mehr Technik an.
Analytics A
+
Analytics B
+
Heatmap
+
Werbenetzwerk
+
Social Pixel
+
Chattool
+
Videoanbieter
+
A/B-Test
Irgendwann weiß niemand mehr, welches System tatsächlich noch gebraucht wird.
Datenschutzfreundliche Architektur kann bedeuten:
Brauchen wir das?
↓
Nein
↓
entfernen
Dann entfallen gleichzeitig:
Consent-Komplexität,
Datenübertragung,
Sicherheitsrisiken,
Performancekosten,
Dokumentationsaufwand.
Weniger Tracking kann Websites schneller machen
Jedes zusätzliche externe Script kann:
heruntergeladen,
ausgeführt,
mit weiteren Servern verbunden
werden.
Datenschutz und Website-Performance können deshalb denselben Anreiz erzeugen:
weniger unnötige Drittanbieter
↓
weniger Datenflüsse
+
weniger Abhängigkeiten
+
weniger Ressourcen
Nicht jede Datenschutzverbesserung bedeutet mehr Technik.
Manchmal bedeutet sie weniger.
Cookiebanner dürfen nicht zum UX-Hindernis werden
Ein gutes Consent-Interface muss gleichzeitig:
informieren,
eine echte Wahl ermöglichen
und die eigentliche Website möglichst wenig behindern.
Das ist eine klassische UX-Design-Aufgabe.
Ein Banner sollte nicht versuchen, Datenschutz durch Erschöpfung zu lösen:
47 Schalter
+
9 Untermenüs
+
unklare Begriffe
Der Nutzer braucht zunächst eine verständliche Entscheidung.
Details können auf einer zweiten Ebene verfügbar sein.
Warum „Alles akzeptieren“ so erfolgreich ist
Nicht unbedingt, weil Nutzer Tracking möchten.
Sondern weil es oft die schnellste Möglichkeit ist, das Banner loszuwerden.
Genau deshalb sind manipulative Gestaltungsunterschiede problematisch. Die EU-Kommission bezeichnet 2026 versteckte Ablehnungswege, zusätzliche Klicks für Ablehnung und irreführende Gestaltung ausdrücklich als problematische „dark patterns“ beziehungsweise deceptive design practices. (European Commission)
Eine Einwilligung sollte Ausdruck einer Entscheidung sein.
Nicht das Resultat von Ungeduld.
Typische Fehler bei Cookiebannern
Tracking läuft schon vor dem Banner
Dann wurde keine vorherige Einwilligung eingeholt. (Österreichische Datenschutzbehörde)
Nur „Alle akzeptieren“ ist sofort sichtbar
Ablehnung erfordert mehrere zusätzliche Ebenen. Die österreichische Datenschutzbehörde verlangt grundsätzlich gleich einfache Zustimmung und Nichtabgabe. (Österreichische Datenschutzbehörde)
Ablehnen ist optisch versteckt
Eine stark unterschiedliche visuelle Gewichtung kann die Freiwilligkeit beeinträchtigen. (Österreichische Datenschutzbehörde)
Kategorien sind vorausgewählt
Vorangekreuzte Einwilligungsoptionen sind mit dem Erfordernis einer aktiven eindeutigen Zustimmung nicht vereinbar. (European Commission)
Weitersurfen gilt als Zustimmung
Die österreichische Datenschutzbehörde lehnt dies ausdrücklich als unmissverständliche Einwilligung ab. (Österreichische Datenschutzbehörde)
Widerruf ist versteckt
Die spätere Rücknahme muss grundsätzlich so einfach sein wie die Zustimmung. (Österreichische Datenschutzbehörde)
Das Plugin wird ungeprüft installiert
Eine Consent-Software garantiert keine richtige Websitekonfiguration. (Österreichische Datenschutzbehörde)
First-Party-Analytics wird pauschal als notwendig bezeichnet
First Party beschreibt die technische Domainbeziehung, nicht automatisch die Notwendigkeit.
Local Storage wird als „cookie-frei und damit irrelevant“ behandelt
Der Anwendungsbereich von Art. 5 Abs. 3 geht nach EDPB ausdrücklich über klassische Cookies hinaus.
Fingerprinting wird als Ausweg aus Cookie-Regeln betrachtet
Der EDPB ordnet auch Fingerprinting grundsätzlich in den technischen Anwendungsbereich der ePrivacy-Endgeräte-Regel ein.
Datenschutzerklärung und Consent werden verwechselt
Information allein ersetzt eine erforderliche Einwilligung nicht.
Häufige Irrtümer über Cookies
„Alle Cookies sind Tracking“
Nein.
Ein Cookie kann beispielsweise nur den notwendigen Loginstatus oder Warenkorb erhalten. Die österreichische Datenschutzbehörde nennt solche Funktionen ausdrücklich als Beispiele technisch notwendiger Cookies. (Österreichische Datenschutzbehörde)
„Alle Cookies brauchen Zustimmung“
Nein.
Für unbedingt notwendige Speicherung beziehungsweise Zugriffe existiert die Ausnahme des Art. 5 Abs. 3 ePrivacy. In Österreich ist sie entsprechend in § 165 Abs. 3 TKG 2021 umgesetzt. (Österreichische Datenschutzbehörde)
„First-Party-Cookies brauchen keine Einwilligung“
Zu pauschal.
Entscheidend ist nicht lediglich die Domain, sondern Zweck und Notwendigkeit.
„Third-Party bedeutet automatisch illegal“
Ebenfalls falsch.
Drittanbieter-Einbindungen müssen konkret auf Technik, Zweck, Rechtsgrundlage, Consent und weitere Datenschutzanforderungen geprüft werden.
„Cookie-frei bedeutet tracking-frei“
Nein.
Tracking kann unter anderem über Pixel, URLs, eindeutige Kennungen, Fingerprinting und andere technische Verfahren erfolgen.
„Cookie-frei bedeutet DSGVO-frei“
Nein.
Auch ohne Cookies können personenbezogene Daten wie Online-Kennungen oder IP-Adressen verarbeitet werden.
„HTTPS verhindert Tracking“
Nein.
HTTPS schützt die Übertragung. Es entscheidet nicht, ob die Datenverarbeitung erlaubt oder für den Nutzer wünschenswert ist.
„Ein Cookiebanner macht eine Website DSGVO-konform“
Nein.
Das Banner ist nur ein Teil des Gesamtsystems.
„Wenn ich ablehne, darf die Website gar keine Cookies setzen“
Nein.
Unbedingt notwendige Funktionen können weiterhin entsprechende Speichermechanismen benötigen. (Österreichische Datenschutzbehörde)
„Session-Cookies brauchen nie Zustimmung“
Falsch.
Session beschreibt Lebensdauer, nicht Zweck.
„Persistente Cookies brauchen immer Zustimmung“
Auch das ist zu pauschal.
Ein persistenter Speichermechanismus kann beispielsweise eine vom Nutzer verlangte Einstellung erhalten. Die konkrete Ausnahme muss anhand des Zwecks geprüft werden.
Ein sinnvoller Cookie-Workflow für Websitebetreiber
Der beste Startpunkt ist nicht das Cookiebanner.
Sondern ein technisches Inventar.
Website
↓
Welche externen Dienste?
↓
Welche lokalen Speicher?
↓
Welche Cookies?
↓
Welche Tracking-Pixel?
↓
Welche IDs?
↓
Welche Datenübertragungen?
Danach folgt die funktionale Prüfung:
Wofür brauchen wir
jede einzelne Technik?
Erst danach:
Ist sie unbedingt notwendig?
und anschließend:
Welche Datenschutz-
und Consentanforderungen folgen?
Das verhindert, dass ein Banner versucht, eine unbekannte technische Infrastruktur nachträglich zu legitimieren.
Schritt 1: Website ohne Einwilligung testen
Öffne sie in einem sauberen Browserkontext.
Prüfe:
Cookies,
Local Storage,
externe Netzwerkverbindungen,
eingebettete Dienste.
Die zentrale Frage:
Was startet bereits,
bevor der Nutzer entschieden hat?
Schritt 2: Jeden Dienst einem Zweck zuordnen
Nicht:
Google Script
oder:
Plugin X
sondern:
Zweck:
Warenkorb
Zweck:
Reichweitenanalyse
Zweck:
personalisierte Werbung
Zweck:
externes Video
Rechtliche Beurteilung funktioniert über Zwecke, nicht über Plugin-Namen.
Schritt 3: Notwendigkeit streng prüfen
Frage:
Kann der ausdrücklich gewünschte Dienst
ohne diesen Zugriff
bereitgestellt werden?
Wenn ja, ist die Ausnahme für „unbedingt erforderlich“ nicht allein dadurch erfüllt, dass der Betreiber die Funktion praktisch oder wirtschaftlich hilfreich findet. Die österreichische DSB betont genau diese enge Betrachtung. (Österreichische Datenschutzbehörde)
Schritt 4: Nicht notwendige Technik standardmäßig blockieren
Standard
↓
aus
Erst bei gültiger Zustimmung:
Consent
↓
an
Das entspricht zugleich Privacy by Default.
Schritt 5: Banner einfach gestalten
Erste Ebene beispielsweise:
Alle akzeptieren
Nur notwendige
Einstellungen
Die konkrete Gestaltung muss zum eingesetzten System passen. Entscheidend ist, dass Zustimmung und Nichtabgabe fair, verständlich und gleich einfach erreichbar sind. (Österreichische Datenschutzbehörde)
Schritt 6: Granularität ermöglichen
Wenn tatsächlich unterschiedliche Zwecke bestehen, sollte die Entscheidung entsprechend differenziert möglich sein.
Beispielsweise:
Notwendig
→ immer aktiv
Analyse
→ optional
Marketing
→ optional
Externe Medien
→ optional
Eine pauschale Zustimmung zu völlig unterschiedlichen Zwecken ist nicht automatisch ausreichend; Einwilligung muss spezifisch sein. (Europäischer Datenschutzausschuss)
Schritt 7: Widerruf dauerhaft erreichbar machen
Zum Beispiel über:
Cookie-Einstellungen
im Footer.
Das macht aus einer einmaligen Bannerentscheidung ein tatsächlich kontrollierbares System.
Schritt 8: Datenschutzerklärung synchron halten
Wer einen Dienst entfernt:
Datenschutzerklärung aktualisieren.
Wer einen neuen Dienst einbaut:
Datenfluss und Consent prüfen.
Ein Datenschutztext sollte die reale Website beschreiben.
Nicht eine historische Konfiguration von vor drei Jahren.
Schritt 9: Regelmäßig erneut testen
WordPress-Updates,
neue Plugins,
Themes,
Marketingtools
können neue Datenflüsse erzeugen.
Privacy by Design ist deshalb kein einmaliger Zustand. Auch der EDPB beschreibt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen als fortlaufenden Prozess, der regelmäßige Überprüfung erfordert. (Europäischer Datenschutzausschuss)
Eine datensparsame Website als Zielbild
Man kann Websitearchitektur auch von der anderen Seite denken.
Nicht:
Wir installieren alles
↓
danach bauen wir
ein riesiges Cookiebanner.
Sondern:
Welche Funktionen brauchen wir?
↓
welche können lokal laufen?
↓
welche Daten brauchen wir wirklich?
↓
welche externen Dienste sind notwendig?
↓
erst dann Consent-System
für verbleibende optionale Funktionen
So wird Datenschutz Architektur statt Popup.
Beispiel für eine einfache Unternehmenswebsite
Angenommen, eine Website besitzt nur:
statische Inhalte,
Kontaktformular,
notwendige Serverfunktionen.
Keine:
Werbenetzwerke,
externen Social-Plugins,
einwilligungsbedürftige Analyse,
externen Medien vor Freigabe.
Dann kann die technisch und rechtlich sauberste Lösung tatsächlich sein:
kein Consent-Banner
statt eines Banners mit:
ALLE COOKIES AKZEPTIEREN
obwohl es gar nichts Sinnvolles zu entscheiden gibt.
Die österreichische Datenschutzbehörde bestätigt ausdrücklich, dass bei ausschließlicher Nutzung technisch notwendiger Cookies keine Einwilligung und damit kein Cookiebanner zur Einholung einer solchen Einwilligung erforderlich ist. (Österreichische Datenschutzbehörde)
Beispiel für eine Website mit Analyse
Nun kommt ein Analysesystem hinzu.
Dann muss geprüft werden:
Welche Technik verwendet es?
Welche Kennungen entstehen?
Werden Cookies beziehungsweise andere Endgeräteinformationen gespeichert oder ausgelesen?
Sind Daten personenbezogen?
Wo werden sie verarbeitet?
Wer erhält sie?
Wie lange?
Welche Rechtsgrundlage gilt?
„Analytics“
ist noch keine rechtliche Kategorie.
Beispiel für Werbung
Bei personalisierter Werbung steigt die Eingriffstiefe typischerweise deutlich.
Browser wiedererkennen
↓
Verhalten sammeln
↓
Interessen ableiten
↓
Werbung personalisieren
Die österreichische Datenschutzbehörde nennt Trackingcookies für personalisierte Werbung ausdrücklich als Beispiel technisch nicht notwendiger Cookies, für die eine vorherige Einwilligung erforderlich ist. (Österreichische Datenschutzbehörde)
Beispiel für externe Videos
Statt den Drittanbieter sofort zu laden:
lokales Poster
↓
Hinweis auf externen Inhalt
↓
Nutzer entscheidet
↓
Player laden
Damit bleibt die Seite vor der Entscheidung technisch kontrollierbarer.
Beispiel für Social Media
Statt eines voll eingebetteten Plugins kann ein normaler Link genügen:
Auf LinkedIn ansehen
Der Drittanbieter wird dann erst besucht, wenn der Nutzer bewusst den Link öffnet.
Das ist ein gutes Beispiel für Datenminimierung durch Architektur.
Was du dir über Cookies merken solltest
Ein Cookie ist zunächst ein Zustandsmechanismus des Webs.
Server
↓
Set-Cookie
↓
Browser speichert
↓
spätere Anfrage
↓
Cookie zurück an Server
RFC 10025 standardisiert diesen Mechanismus heute über die HTTP-Header Set-Cookie und Cookie. (auth48-transition.rfc-editor.org)
Cookies können sinnvoll und notwendig sein.
Zum Beispiel für:
Login
Warenkorb
Sprache
Consent-Status
Sie können aber ebenso für langfristige Wiedererkennung und Tracking verwendet werden.
Darum lautet die richtige Frage nicht:
Ist das ein Cookie?
sondern:
Was tut dieses Cookie?
Was du dir über Tracking merken solltest
Tracking bedeutet im Kern:
mehrere Ereignisse
↓
demselben Nutzer,
Browser oder Gerät
zuordnen
Dazu können Cookies dienen.
Aber nicht nur Cookies.
Der EDPB behandelt ausdrücklich auch:
Tracking-Pixel,
Tracking-URLs,
lokale Speicher- und Verarbeitungsmechanismen,
Fingerprinting,
eindeutige Kennungen
und bestimmte IP-basierte Verfahren.
Deshalb gilt:
Cookies
⊂
mögliche Trackingtechniken
und nicht:
Cookies
=
gesamtes Tracking
Was du dir über ePrivacy und DSGVO merken solltest
Es existieren zwei Fragen.
Frage 1:
Darf auf dem Endgerät
Information gespeichert
oder ausgelesen werden?
und:
Frage 2:
Darf die daraus entstehende
personenbezogene Information
weiterverarbeitet werden?
Die erste Frage wird insbesondere durch Art. 5 Abs. 3 der ePrivacy-Richtlinie und dessen nationale Umsetzung geprägt. Die zweite fällt, soweit personenbezogene Daten betroffen sind, in den Bereich der DSGVO. Der EDPB betont ausdrücklich, dass Art. 5 Abs. 3 auch „Information“ erfasst, die nicht personenbezogen sein muss.
Was du dir über notwendige Cookies merken solltest
Entscheidend ist nicht:
First Party?
und auch nicht:
Session Cookie?
Sondern:
Ist diese Speicherung
beziehungsweise dieser Zugriff
unbedingt erforderlich,
um den ausdrücklich gewünschten
Dienst bereitzustellen?
Für solche Vorgänge kann die ePrivacy-Ausnahme greifen. Die österreichische DSB nennt unter anderem notwendige Warenkorb- und Loginsitzungen als Beispiele. (Österreichische Datenschutzbehörde)
Was du dir über Cookiebanner merken solltest
Ein Banner ist nur erforderlich, soweit überhaupt eine entsprechende Einwilligung einzuholen ist.
Wenn sie benötigt wird, muss sie vor der nicht notwendigen Technik erfolgen. (Österreichische Datenschutzbehörde)
Der Nutzer benötigt eine echte Wahl:
Ja
oder
Nein
nicht:
Ja
oder
irgendwo versteckt vielleicht Nein
Die Nichtabgabe muss nach der aktuellen österreichischen DSB-Praxis genauso einfach erreichbar sein wie die Zustimmung. Vorangekreuzte Optionen, bloßes Weitersurfen und manipulative optische Gestaltung passen nicht zu einer freien eindeutigen Einwilligung. (Österreichische Datenschutzbehörde)
Was du dir über Consent-Tools merken solltest
Ein Plugin kann:
Banner anzeigen,
Skripte blockieren,
Entscheidungen speichern.
Es kann aber nicht automatisch wissen:
ob ein Dienst notwendig ist,
welche Rechtsgrundlage passt,
ob sämtliche Skripte korrekt kategorisiert wurden,
ob die Datenschutzerklärung stimmt.
Consent-Tool
→ technisches Werkzeug
nicht:
Consent-Tool
→ automatische Rechtskonformität
Die österreichische Datenschutzbehörde warnt ausdrücklich vor einem ungeprüften Vertrauen in angebotene Consent-Lösungen. (Österreichische Datenschutzbehörde)
Das wichtigste Prinzip für Websitebetreiber
Der sauberste Datenschutzworkflow beginnt nicht mit:
Welches Cookiebanner
sollen wir kaufen?
Sondern mit:
Welche Datenflüsse
brauchen wir überhaupt?
Danach:
Was können wir entfernen?
↓
Was ist unbedingt notwendig?
↓
Was ist optional?
↓
Was braucht Zustimmung?
↓
Wie setzen wir diese Entscheidung
technisch korrekt um?
Damit verschiebt sich Datenschutz vom Banner auf die eigentliche Websitearchitektur.
Der zentrale Merksatz lautet:
Cookies sind nicht grundsätzlich gut oder schlecht, und Tracking beginnt nicht erst bei Third-Party-Cookies. Entscheidend sind Zweck, technische Funktionsweise und die daraus entstehenden Datenflüsse. Eine datenschutzfreundliche Website verwendet nur die Mechanismen, die sie tatsächlich benötigt, startet einwilligungsbedürftige Dienste erst nach einer echten Entscheidung und gestaltet Ablehnung genauso selbstverständlich wie Zustimmung. Das beste Cookiebanner ist deshalb oft dasjenige, das nur sehr wenig verwalten muss – weil die Website von Anfang an datensparsam gebaut wurde.