Cookies, Gerätezugriffe und Einwilligungen technisch untersuchen

Ein Banner ist noch kein Nachweis für den tatsächlichen Ablauf

Ob eine Webseite vor einer Auswahl bereits optionale Ressourcen lädt, lässt sich am sichtbaren Banner allein nicht erkennen. Entscheidend sind die tatsächlich ausgeführten Zugriffe, gespeicherten Informationen und übermittelten Anfragen. Dieser Beitrag untersucht dafür einen vollständig eigenen kleinen Browserablauf. Er trennt die Oberfläche der Entscheidung von ihren technischen Folgen und hält die Ergebnisse vor einer Auswahl, nach Ablehnung, nach Zustimmung und nach Widerruf fest.

Das Beispiel hat genau einen optionalen Messzweck. Eine erlaubte JavaScript-Datei legt einen bekannten Cookie und einen bekannten Eintrag im Browserspeicher an. Erst eine ausdrücklich ausgelöste Beispielaktion sendet den festen Text demo-click an einen eigenen Versuchsdienst. Es sind keine Analyseanbieter, Werbenetzwerke oder wirklichen Besucherprofile eingebunden. Diese Begrenzung macht die Ursache jedes beobachteten Ereignisses nachvollziehbar.

Die 71 tatsächlich ausgeführten Bedingungen prüfen diesen konkreten Entwurf in Edge. Dazu gehören helle und dunkle Darstellung, schmale Ansichten, gespeicherte Entscheidungen sowie bewusst verzögerte Anfragen. Die Ergebnisse sind keine pauschale Freigabe einer beliebigen Einwilligungsplattform. Sie zeigen eine überprüfbare Arbeitsweise, die sich anschließend mit den tatsächlichen Diensten und Zwecken einer konkreten Webseite verbinden lässt.

Gerätezugriff und weitere Verarbeitung getrennt beurteilen

§ 25 TDDDG betrifft das Speichern von Informationen in einer Endeinrichtung und den Zugriff auf dort bereits gespeicherte Informationen. Der gesetzliche Ausgangspunkt ist die informierte Einwilligung. Die beiden Ausnahmen betreffen die reine Nachrichtenübertragung sowie die unbedingte Erforderlichkeit für einen ausdrücklich gewünschten digitalen Dienst. Der Name eines Cookies oder die eigene Domain entscheidet diese Einordnung nicht. Maßgeblich bleibt der konkrete Vorgang mit seinem tatsächlichen Zweck.

Die DSGVO ist zusätzlich zu prüfen, wenn personenbezogene Daten verarbeitet werden. Eine technisch unauffällige Anfrage kann trotzdem solche Daten übermitteln. Umgekehrt erschöpft sich der Schutz der Endeinrichtung nicht in personenbezogenen Cookies. Die Orientierungshilfe der Datenschutzkonferenz erläutert die unterschiedlichen Anwendungsbereiche. Für die Bestandsaufnahme bedeutet das: technische Speicherstellen, Übertragungswege und rechtliche Bewertung werden verbunden, aber nicht zu einer einzigen ungenauen Cookie-Liste verkürzt.

Unser Messzweck wird bewusst erst nach Zustimmung aktiviert. Daraus folgt keine Aussage, jede beliebige Messung sei bei gleicher Beschriftung rechtmäßig. Informationen über Anbieter, Empfänger, Zwecke, Speicherdauer und weitere Verarbeitung müssen zum wirklichen Einsatz passen. Der Beispielcode enthält diese produktbezogene Dokumentation nicht. Er beantwortet die engere technische Frage, ob die ausdrücklich beschriebene Freigabe im kontrollierten Ablauf tatsächlich das Laden und Starten steuert.

Mit einem wirklich frischen Browserzustand beginnen

Eine Prüfung startet in einem neuen Browserkontext ohne vorhandene Entscheidungen und Messwerte. Ein bereits gespeichertes Ja würde sonst einen unmittelbaren Start erklären, obwohl der erste Besuch anders funktioniert. Der Versuch erfasst zunächst alle Cookies dieses Kontextes, die Einträge in localStorage und die Anfragen an den eigenen optionalen Dienst. Alle drei Bestände sind vor der ersten Auswahl leer.

Auch die gewöhnliche Beispielaktion wird in diesem Zustand betätigt. Sie bleibt bedienbar, erzeugt jedoch keine Messanfrage. Damit wird nicht bloß ein verborgenes Fenster fotografiert. Es wird ein tatsächlicher Bedienweg ausgeführt, bei dem die optionale Wirkung ausbleiben soll. Erst danach folgt eine Entscheidung. Jeder weitere Schritt besitzt somit einen klaren Ausgangspunkt und einen konkreten erwarteten Unterschied zum vorherigen Zustand.

Bei einer wirklichen Webseite kommen weitere Speicherformen, eingebettete Dokumente, Service Worker, Weiterleitungen und abhängige Ressourcen hinzu. Die hier gewählten drei Inventare decken diesen größeren Bestand nicht vollständig ab. Sie reichen für den ausdrücklich kleinen eigenen Versuch. Eine spätere Untersuchung erweitert die Erfassung anhand der tatsächlichen Architektur, statt aus einem leeren Cookie-Fenster vorschnell auf eine vollständig zugriffsfreie Webseite zu schließen.

Jede Ressource einem Zweck und Auslöser zuordnen

Für jede optionale Ressource werden Quelle, Auslöser und Wirkung festgehalten. Im Beispiel ist die Quelle eine Moduldatei des zweiten Versuchsdienstes. Der Auslöser ist ausschließlich eine gespeicherte oder gerade erteilte Freigabe. Die Wirkung beginnt erst durch den ausdrücklichen Aufruf ihrer Startfunktion. Die bloße Dateistruktur versteckt deshalb keine bereits beim Import ausgeführten Speicherzugriffe.

Diese Trennung ist entscheidend für die spätere Prüfung. Ein vermeintlich gesperrter Startaufruf hilft wenig, wenn schon der Import fremden Code ausführt und Informationen übermittelt. Hier enthält die optionale Datei auf oberster Ebene nur ihre Funktionsdefinition. Der Test prüft trotzdem den tatsächlichen Netzwerkabruf. Auch ein Modul ohne eigene Startwirkung muss zunächst übertragen werden und erscheint daher in der Ressourcenbilanz.

Eine produktive Bestandsaufnahme hält zusätzlich nachgeladene Abhängigkeiten und deren wechselnde Adressen fest. Nicht jeder sichtbare Request besitzt dieselbe Funktion. Deshalb werden Namen nicht automatisch als Messung, Sicherheit oder notwendiger Betrieb eingeordnet. Ein technischer Befund beschreibt zunächst, was nach welchem Auslöser passiert. Die begründete Bewertung des Zwecks baut auf dieser nachprüfbaren Beschreibung auf.

Zwei Ports sind unterschiedliche Ursprünge, aber kein fremdes Internetangebot

Die Versuchsanordnung verwendet zwei HTTP-Dienste auf 127.0.0.1 mit unterschiedlichen Ports. Für den Browser sind dies unterschiedliche Origins. Beide gehören jedoch zum selben Host und zur selben Site. Der Versuch ist ausdrücklich kein Test tatsächlicher Drittanbieter-Cookies und kein Nachweis über Browserblockaden zwischen unterschiedlichen Internetseiten. Diese Unterscheidung ist wichtig, weil die Begriffe im Alltag häufig ungenau vermischt werden.

Der importierte Code läuft im Dokument, das ihn aufruft. Seine localStorage-Zugriffe betreffen daher den Speicher dieses Dokumentursprungs. Der Abruf von einem anderen Port verschiebt den Speicherzugriff nicht automatisch zum Ursprung der Quelldatei. Der Cookie wird ebenfalls über das Dokument gesetzt. Der Versuch zeigt diese konkreten Werte im Browserinventar und beschreibt keine fremde Anbieterinstallation.

Der eigene Sammler erhält nur den festen Demonstrationstext. Fetch verwendet credentials omit, sodass diese Anfrage keine Browserzugangsdaten mitsendet. Daraus folgt keine allgemeine Datenfreiheit von Netzwerkanfragen. Die beteiligten eigenen Server sehen weiterhin die für die Verbindung benötigten technischen Informationen. Für eine reale Einbindung werden Zielsysteme, Protokollierung und tatsächliche Nutzlast gesondert aufgenommen.

Ablehnung als echten gespeicherten Zustand behandeln

Die Schaltfläche Ohne optionale Messung legt die eigene Entscheidung deny mit ihrer Versionsnummer ab. Sie lädt kein optionales Modul und erzeugt keinen Messwert. Beim Neuladen erkennt der Entwurf diesen Stand wieder. Die weitere Bedienung bleibt möglich. Ablehnung ist somit eine wirkliche Auswahl mit technischem Verhalten und kein bloßes Schließen einer weiterhin aktiven Messoberfläche.

Der Entscheidungsspeicher ist selbst ein Speicherzugriff. Er wird in der Bestandsaufnahme ausdrücklich mitgeführt. Seine rechtliche Einordnung hängt ebenfalls von Funktion und konkretem Einsatz ab. Der Beitrag behauptet nicht, jeder als Präferenz bezeichnete Eintrag sei automatisch von einer Einwilligung ausgenommen. Im eigenen Entwurf dient der kleine versionierte Wert ausschließlich der Wiederaufnahme dieser Auswahl und enthält keine Kennung für ein Besucherprofil.

Beide anfänglichen Auswahlmöglichkeiten verwenden dieselbe farbliche Behandlung. Ihre Reihenfolge und der sichtbare Tastaturfokus werden geprüft. Gleiches CSS bestätigt jedoch nicht allein Freiwilligkeit, ausreichende Information oder die Rechtmäßigkeit einer vollständigen Oberfläche. Die technische Untersuchung und die inhaltliche Gestaltung der Entscheidung ergänzen sich. Ein bestandener Darstellungsfall darf nicht stellvertretend alle anderen Voraussetzungen als erledigt markieren.

Eine Zustimmung erst nach ihrer erfolgreichen Vorbereitung anwenden

Bei Zustimmung versucht der Entwurf zunächst, den neuen Entscheidungsstand zu speichern. Schlägt dieser konkrete Schritt fehl, bleibt das optionale Modul ungeladen. Der kontrollierte Fehlerfall ersetzt die Speicherfunktion gezielt durch eine auslösende Ausnahme. Tatsächlich entsteht danach weder die Modulanforderung noch der eigene Messcookie. Die sichtbare Meldung erklärt, dass die Auswahl nicht gespeichert werden konnte.

Bei erfolgreicher Vorbereitung wird die Moduldatei angefordert und anschließend ihre Startfunktion aufgerufen. Erst diese Funktion erzeugt demo_metric im Browserspeicher und demo_measurement als Cookie. Eine weitere Beispielaktion erreicht danach den eigenen Sammler. Das gespeicherte Empfangsprotokoll enthält genau den vorgesehenen Text. Damit verbindet der Versuch die Freigabe mit einem beobachteten Ergebnis, statt nur auf einen internen booleschen Wert zu vertrauen.

Weitere Klicks auf Zustimmung sollen keine mehrfachen Listener an derselben Schaltfläche erzeugen. Der Entwurf behält deshalb die laufende Startfunktion und das bereits aufgelöste Modul. Der Browserversuch wiederholt die Zustimmung mehrfach und löst anschließend eine einzige Aktion aus. Genau eine zusätzliche Messanfrage erreicht den Versuchsdienst. Das ist eine Aussage über diesen konkreten Ablauf und keine universelle Garantie für fremde Skripte.

Widerruf muss die wirksame Ausführung erreichen

Die sichtbare Schaltfläche Optionale Messung stoppen führt unmittelbar in den ausgeschalteten Zustand. Der Entwurf entfernt den eigenen Aktionslistener über seinen AbortController, löscht den bekannten Messspeichereintrag und lässt den eigenen Messcookie ablaufen. Anschließend speichert er deny. Eine neue Beispielaktion erzeugt keine weitere Sammleranfrage. Nach Neuladen bleibt das optionale Modul weiterhin aus.

Die DSGVO verlangt, dass ein Widerruf so einfach wie die Erteilung ist. Die Leitlinien des Europäischen Datenschutzausschusses erläutern diese praktische Anforderung. Unser eigener Versuch bietet dafür einen direkt erreichbaren einzelnen Bedienweg. Er bildet keine vollständige Verwaltung mehrerer Anbieter oder wechselnder Zwecke ab. Eine wirkliche Oberfläche muss ihre tatsächlichen Freigaben und deren Rücknahme entsprechend verständlich erreichbar machen.

Das Löschen ist bewusst auf die eigenen bekannten Messwerte begrenzt. Der Entwurf verspricht weder das Entfernen aller Cookies noch eine rückwirkende Löschung beliebiger fremder Daten. Auch die gespeichert gehaltene Entscheidung bleibt im Inventar sichtbar. Ihre Aufgabe unterscheidet sich vom Messwert. Für zusätzliche Speicherorte und Anbieter braucht es eigene belastbare Rücknahmewege und einen überprüften Umgang mit bereits vorhandenen Informationen.

Ein später ankommender Import darf die Rücknahme nicht überholen

Asynchroner Code kann eine zuvor richtige Entscheidung später wieder überschreiben. Der Versuch verzögert deshalb die Antwort auf die Modulanforderung gezielt. Die Zustimmung startet den Abruf. Noch bevor die Datei ankommt, wird die Freigabe zurückgenommen. Der Netzwerkabruf selbst ist bereits begonnen. Entscheidend ist nun, ob der nachfolgende Programmabschnitt trotzdem noch die Messfunktion startet.

Jede Auswahl erhöht im Entwurf eine Revisionsnummer. Der wartende Aufruf behält seine frühere Nummer. Sobald die Datei vorliegt, vergleicht er sie mit dem aktuellen Stand. Nach dem inzwischen erfolgten Widerruf passt die Nummer nicht mehr. Die Startfunktion wird nicht aufgerufen. Der tatsächliche Test findet danach weder Messcookie noch Messwert noch einen aktiven Sammlerlistener.

Diese Prüfung schützt den ausdrücklich entwickelten eigenen Startpfad. Sie kann keine unbekannten Seiteneffekte eines fremden Moduls rückgängig machen. Eine nachgeladene Datei, die schon beim Import selbstständig arbeitet, hätte andere Voraussetzungen. Deshalb gehören Quellverhalten, Ladezeitpunkt und Abhängigkeiten zur technischen Auswahl eines Dienstes. Die Revisionsnummer ist ein hilfreicher Mechanismus innerhalb dieses Vertrags und kein allgemeiner Schutzschalter für beliebigen Drittcode.

Bereits übertragene Informationen lassen sich nicht zurückrufen

Ein zweiter kontrollierter Zeitfall verzögert die Antwort des Sammlers. Die Messanfrage wird zuvor tatsächlich angenommen und protokolliert. Danach erfolgt der Widerruf. Der AbortController beendet den noch offenen Browserweg und verhindert spätere Aktionsanfragen. Das bereits beim eigenen Dienst eingegangene Ereignis bleibt jedoch in dessen Empfangsprotokoll vorhanden. Genau dieser Unterschied wird im Versuch ausdrücklich erhalten.

Ein abgebrochener Fetch ist daher kein Beleg dafür, dass der Empfänger keine Daten bekommen hat. Ebenso bedeutet ein fehlendes sichtbares Ergebnis nicht automatisch eine ausgebliebene Übertragung. Für eine reale Bestandsaufnahme werden Browseransicht und passende serverseitige Nachweise gemeinsam ausgewertet. Der Versuch führt keine externe Löschung aus und behauptet keine Rückholung bereits übertragener Informationen.

Die Aufgabe nach einem Widerruf betrifft somit mehrere Ebenen. Künftige optionale Ausführung wird gestoppt. Bekannte eigene Speicherwerte werden nach dem entwickelten Vertrag behandelt. Der Umgang mit bereits verarbeiteten Informationen richtet sich nach dem tatsächlichen Datenbestand und den einschlägigen Pflichten. Diese Ebenen verdienen getrennte Prüfergebnisse. Eine einzige grüne Meldung mit dem Wort deaktiviert würde die Unterschiede verbergen.

HttpOnly zeigt die Grenze von document.cookie

Für einen gesonderten Versuch setzt der eigene Server ausdrücklich einen Cookie mit HttpOnly über den HTTP-Antwortheader. Dieser Probezugriff gehört nicht zum gewöhnlichen ersten Seitenaufruf und wird nicht als notwendiger Dienst eingeordnet. Das vollständige Cookie-Inventar des Browserkontextes zeigt anschließend seinen Namen und sein HttpOnly-Merkmal. Ein Lesen von document.cookie zeigt denselben Cookie dagegen nicht.

Damit ist eine häufige Fehlinterpretation konkret widerlegt. Eine leere JavaScript-Zeichenfolge beweist keinen leeren Cookie-Bestand. Die Messbereinigung des Beispiels behauptet auch nicht, diesen zusätzlichen Servercookie löschen zu können. Er bleibt nach Ablehnung sichtbar, bis die ausdrücklich dafür entwickelte Serverroute ihn mit einem passenden Ablaufheader entfernt. Dieser Unterschied wird in beiden Darstellungen tatsächlich ausgeführt.

Für die reale Prüfung werden deshalb Browserwerkzeuge, HTTP-Antworten und die verschiedenen Speicheransichten zusammengeführt. Die MDN-Dokumentation beschreibt die Rolle von document.cookie und die Einschränkung bei HttpOnly. Namen und Sichtbarkeit allein geben jedoch noch keine vollständige rechtliche Einordnung. Auch dieser Probeversuch liefert zunächst einen technischen Befund mit bekanntem Erzeugungsweg.

Ungültige alte Entscheidungen nicht als neue Freigabe verwenden

Eine gespeicherte Version null mit dem Wert allow wird im Test ausdrücklich nicht übernommen. Ebenso bleibt ein beschädigter JSON-Wert ohne optionale Wirkung. Der Entwurf erkennt ausschließlich seine bekannte Version und die beiden definierten Werte an. Eine fehlende oder unverständliche Entscheidung wird nicht beiläufig als Zustimmung behandelt. Die gewöhnliche Beispielaktion bleibt weiterhin verfügbar.

Eine Versionsnummer beschreibt hier nur das eigene Datenformat. Sie kann nicht automatisch bestätigen, dass geänderte Zwecke oder Anbieter noch von einer älteren Entscheidung umfasst sind. Für eine wirkliche Einwilligungsverwaltung müssen die tatsächlichen Informationen und die Bedeutung des gespeicherten Stands nachvollziehbar bleiben. Der Entwurf verwendet keine erfundene allgemeine Gültigkeitsdauer und behauptet keine unbegrenzte Fortgeltung.

Zusätzliche Ausfallzustände verdienen eigene Fälle. Der gezeigte Speicherfehler betrifft ausdrücklich die Vorbereitung der Zustimmung. Andere Browserbeschränkungen, mehrere offene Tabs, defekte externe Module und ein nicht dauerhaft speicherbarer Widerruf sind dadurch nicht vollständig untersucht. Der Testbericht nennt seinen Umfang, damit die Zahl bestandener Bedingungen nicht als Aussage über nie ausgeführte Situationen missverstanden wird.

71 ausgeführte Browserbedingungen auswerten

Der Prüfbericht enthält tatsächliche Cookie-Inventare, Speichereinträge und das Empfangsprotokoll der eigenen Dienste. Helle und dunkle Darstellung werden jeweils mit frischem Zustand geprüft. Ansichten bei 320, 390 und 1440 Pixeln bleiben ohne waagerechten Seitenüberlauf. Die erste Tastaturwahl erreicht die Ablehnung mit sichtbarem Fokus. Diese Ergebnisse beschreiben den ausgeführten Entwurf und seine dokumentierten Testbedingungen.

Die beiden folgenden Abbildungen zeigen unveränderte Browserpixel nach Zustimmung und nach Rücknahme. Die ergänzende Matrix stammt aus den gespeicherten tatsächlichen Ergebnissen. Die Grafik erfindet keine Messkurve und keine Erfolgsquote. Ihre Aufgabe ist die Zuordnung sichtbarer Entscheidung, vorhandener Werte und erreichter Netzwerkwirkung. So lässt sich der Ablauf auch ohne Durcharbeiten jeder einzelnen Codezeile verstehen.

Für die Abnahme einer echten Webseite wird derselbe Grundgedanke auf ihre konkreten Komponenten übertragen. Ein Prüfprotokoll nennt Browser, Zeitpunkt, Ausgangszustand, ausgeführten Bedienweg und beobachtete Wirkung. Spätere Änderungen an Einbindungen oder Zwecken benötigen neue passende Prüfungen. Eine einmalige Aufnahme kann keine stillen Änderungen eines entfernten Dienstes dauerhaft abdecken.

Den vollständigen kleinen Entwurf nachvollziehen

Die folgenden vier Dateien zeigen die tatsächliche HTML-Oberfläche, ihre Gestaltung, die Steuerung der Auswahl und das optionale Modul. Im isolierten Versuch setzt der eigene Hauptserver das Attribut data-optional-origin auf die Adresse seines zweiten Dienstes. Dieser liefert die Moduldatei mit passender Freigabe für den ursprungsübergreifenden Abruf. Die Versuchsanordnung verarbeitet ausschließlich die beschriebenen Demonstrationswerte.

Für eine Übernahme werden Quelladressen, Berechtigungen und Sicherheitsrichtlinien der wirklichen Webseite ausdrücklich eingerichtet. Es genügt nicht, einen unbekannten Messanbieter an die Moduladresse zu setzen. Ebenso fehlt hier eine vollständige Dokumentation und Verwaltung mehrerer rechtlicher Zwecke. Der Nutzen des kleinen Codes liegt in seiner lesbaren Ausführungsgrenze: Ohne erkannte Freigabe gibt es keinen optionalen Import und ohne weiterhin aktuelle Freigabe keinen Start.

Die zentrale Frage der technischen Untersuchung bleibt für jedes zusätzliche Modul gleich: Was geschieht wirklich vor der Auswahl, nach Ablehnung, nach Freigabe und nach Rücknahme? Erst ein belegter Ablauf verbindet den sichtbaren Entscheidungsdialog mit den tatsächlichen Zugriffen. Die Rechtsgrundlagen und die konkreten Informationen zum Dienst werden darauf aufbauend passend beurteilt.

example.html

<main><h1>Gerätezugriffe im Beispiel untersuchen</h1>
<p>Der separate Demo-Dienst wird erst nach Ihrer Auswahl geladen. Es sind keine realen Messanbieter eingebunden.</p>
<section aria-labelledby="choice-title"><h2 id="choice-title">Optionale Demo-Messung</h2>
<p>Das Modul setzt ein Demo-Cookie und einen Eintrag im Browserspeicher. Beim Auslösen der Beispielaktion übermittelt es nur den Text demo-click an den separaten lokalen Demo-Dienst.</p>
<div class="actions"><button id="deny" type="button">Ohne optionale Messung</button><button id="allow" type="button">Optionale Messung erlauben</button></div>
<p id="choice-status" role="status">Noch keine Auswahl. Die optionale Messung bleibt aus.</p>
<button id="withdraw" type="button">Optionale Messung stoppen</button></section>
<section><h2>Eine Aktion ausführen</h2><button id="demo-action" type="button">Beispielaktion ausführen</button><p>Die Schaltfläche bleibt auch ohne Messung bedienbar.</p></section></main>

example.css

*{box-sizing:border-box}body{margin:0;background:#f8f2e8;color:#202428;font:18px/1.5 Arial,sans-serif}main{max-width:50rem;margin:auto;padding:2rem}h1{font-size:2rem;line-height:1.2}section{border-top:5px solid #cd0712;padding:1rem 0;margin:1.5rem 0}.actions{display:flex;gap:1rem;flex-wrap:wrap}button{font:inherit;min-height:48px;padding:.75rem 1rem;border:1px solid #c90713;border-radius:4px;background:#c90713;color:#fff;max-width:100%}:focus-visible{outline:3px solid #ce0713;outline-offset:4px}#choice-status{font-weight:bold}@media(max-width:450px){main{padding:1.2rem}h1{font-size:1.65rem}.actions{display:grid}}@media(prefers-color-scheme:dark){body{background:#1d2225;color:#faf1e4}:focus-visible{outline-color:#ff9d92}}

gate.mjs

const choiceKey='demo-choice-v1',version=1;
const origin=document.documentElement.dataset.optionalOrigin;
const status=document.querySelector('#choice-status');
let current=null,revision=0,modulePromise=null,stop=null;
function readChoice() {
 try {
  const saved=JSON.parse(localStorage.getItem(choiceKey));
  return saved?.version===version&&['allow','deny'].includes(saved.choice)?saved.choice:null;
 }catch{return null;}
}
function storeChoice(choice) {
 try{localStorage.setItem(choiceKey,JSON.stringify({version,choice}));return true;}
 catch{return false;}
}
async function choose(choice,persist=true) {
 const ticket=++revision;
 if(choice==='deny') {
  current='deny';stop?.();stop=null;
  document.cookie='demo_measurement=; Path=/; Max-Age=0; SameSite=Lax';
  try{localStorage.removeItem('demo_metric');}catch{}
  const stored=!persist||storeChoice('deny');
  status.textContent=stored?'Optionale Messung ist aus.':'Messung gestoppt. Die Auswahl konnte nicht gespeichert werden.';
  return;
 }
 if(persist&&!storeChoice('allow')){status.textContent='Die Auswahl konnte nicht gespeichert werden. Messung bleibt aus.';return;}
 current='allow';status.textContent='Das erlaubte Demo-Modul wird geladen.';
 try {
  modulePromise??=import(origin+'/tracker.mjs');
  const module=await modulePromise;
  // A later withdrawal invalidates this earlier asynchronous continuation.
  if(ticket!==revision||current!=='allow')return;
  stop??=module.startMeasurement({collector:origin+'/collect'});
  status.textContent='Optionale Demo-Messung ist aktiv.';
 }catch{status.textContent='Das optionale Demo-Modul konnte nicht geladen werden.';}
}
document.querySelector('#allow').addEventListener('click',()=>choose('allow'));
document.querySelector('#deny').addEventListener('click',()=>choose('deny'));
document.querySelector('#withdraw').addEventListener('click',()=>choose('deny'));
const initial=readChoice();if(initial)choose(initial,false);

tracker.mjs

// No storage access or requests at module top level.
export function startMeasurement({collector}) {
 const controller=new AbortController();
 localStorage.setItem('demo_metric','1');
 document.cookie='demo_measurement=1; Path=/; SameSite=Lax';
 document.querySelector('#demo-action').addEventListener('click',()=>{
  fetch(collector,{method:'POST',credentials:'omit',headers:{'Content-Type':'text/plain'},
    body:'demo-click',signal:controller.signal}).catch(()=>{});
 },{signal:controller.signal});
 return ()=>controller.abort();
}

Zustände im eigenen Versuch

Checkliste für die technische Bestandsaufnahme

• Mit frischem Zustand und dokumentiertem Browser beginnen.
• Vor Auswahl Ressourcen, Speicher und mögliche Übertragungen erfassen.
• Jeden Zugriff seinem tatsächlichen Zweck und Auslöser zuordnen.
• Gerätezugriff nach TDDDG und personenbezogene Verarbeitung getrennt beurteilen.
• Ablehnung, Zustimmung und Rücknahme tatsächlich bedienen.
• Nach Neuladen und bei ungültigen alten Entscheidungen erneut prüfen.
• Verspätete Initialisierung nach Widerruf gezielt ausführen.
• Bereits übertragene Daten nicht mit gestoppten künftigen Anfragen verwechseln.
• HttpOnly und weitere Speicherformen nicht über document.cookie beurteilen.
• Änderungen an Diensten, Zwecken und Informationen neu bewerten.

Primärquellen und Prüfstand

Quellen am 09.11.2026 geprüft. Normativer Rahmen: § 25 TDDDG, DSGVO und verlinkte Aufsichtsleitlinien. Die technische Untersuchung ist ein eigener enger Versuch mit 71 ausgeführten Edge-Bedingungen. Zwei Ports desselben Loopback-Hosts bilden unterschiedliche Origins, aber keinen wirklichen Drittanbieter-Cookie-Versuch. Keine vollständige Einwilligungsverwaltung oder Freigabe eines fremden Dienstes.

• § 25 TDDDG
• DSGVO / GDPR: Art. 4, 6, 7
• DSK: OH Digitale Dienste, Version 1.2, November 2024
• EDPB: Guidelines 05/2020 on consent
• MDN: document.cookie
• MDN: localStorage
• MDN: AbortController.abort