Cookie-Whitelist

TL;DR: Die CookieVault-Cookie-Whitelist ist eine Allowlist pro Domain, die vertraute Websites vom Auto-Löschen ausnimmt — sodass du Logins für die Websites behältst, die du täglich nutzt, während alles andere beim Tab-Schließen bereinigt wird. Subdomain-Vererbung, Wildcards und eine Greylist halten die Liste kurz; die lokale Liste ist kostenlos, die geräteübergreifende Synchronisierung ist Pro.

Die Cookie-Whitelist in CookieVault Guardian ist eine Allowlist pro Domain, die das Auto-Löschen außer Kraft setzt, sodass Origins auf der Whitelist ihre Cookies und Website-Daten über Tab-Schließungen hinweg behalten, während jede andere Domain in dem Moment bereinigt wird, in dem ihr letzter Tab schließt. Es ist die moderne Neuimplementierung des klassischen Allowlist-Modells von Cookie AutoDelete, erweitert um Subdomain-Vererbung, Wildcard-Muster und eine Greylist für Websites nur für die Sitzung. In der Praxis ist die Whitelist die wichtigste Einstellung im gesamten Produkt: Sie ist der eine Regler, der entscheidet, welche Logins überleben und welche verschwinden.

Wie die Whitelist funktioniert

Kurz gesagt: Füge eine Domain hinzu, indem du auf der Website auf das Symbol in der Symbolleiste klickst. Die Subdomain-Vererbung ist standardmäßig an, sodass ein Eintrag einen ganzen Dienst abdeckt. Domains auf der Whitelist werden einfach übersprungen, wenn das Auto-Löschen nach dem Schließen des letzten Tabs läuft.

Cookies sind die Art, wie sich Websites zwischen Anfragen an dich erinnern; MDN dokumentiert, dass das Sitzungs-Cookie dich authentifiziert hält¹. Die Whitelist funktioniert, indem sie Guardian anweist, die Cookies einer Domain — und speziell ihr Sitzungs-Cookie — an Ort und Stelle zu lassen, wenn die Bereinigung sonst ausgelöst würde. CookieVault liest und bewahrt diese Einträge über die offizielle Browser-Cookie-API², sodass sich ein Login auf der Whitelist genauso verhält wie ganz ohne installierte Erweiterung.

Sechs Mechaniken, die die Liste handhabbar machen:

• Ein-Klick-Hinzufügen — klicke auf einer beliebigen Website auf das Symbol in der Symbolleiste und wähle “Add to whitelist”
• Subdomain-Vererbung (standardmäßig an) — example.com nimmt auch mail.example.com und app.example.com aus
• Exakter-Host-Modus — schalte die Vererbung ab, um nur die Apex-Domain auf die Whitelist zu setzen und ihre Subdomains zu bereinigen
• Wildcards — *.googleapis.com deckt jede Subdomain eines API- oder CDN-Hosts in einer Regel ab
• Greylist — Ausnahme nur für die Sitzung, die beim nächsten Schließen bereinigt oder automatisch hochstuft
• Lokal unbegrenzt — keine Begrenzung der Einträge in der kostenlosen, lokalen Liste

Ein verlässliches Prinzip für Allowlists ist, sie kurz und bewusst zu halten: Eine kleine, gut gewählte Liste ist leicht zu durchschauen, während eine wuchernde das Datenschutzziel still untergräbt.

Whitelist vs. Greylist

Kurz gesagt: Whitelist bedeutet “nie bereinigen, über Sitzungen hinweg behalten”. Greylist bedeutet “für diese Sitzung behalten, dann beim nächsten Schließen bereinigen oder automatisch hochstufen”. Nutze die Whitelist für dauerhafte Logins und die Greylist für einmalige Besuche.

Die Greylist existiert, weil echtes Surfen nicht binär ist. Manchmal willst du Kontinuität für die nächste Stunde auf einer Website, zu der du nie zurückkehren wirst — die Greylist gibt dir das, ohne deine Whitelist dauerhaft anwachsen zu lassen.

Häufige Whitelist-Fehler

Kurz gesagt: Die zwei Fehlermodi sind, zu viel auf die Whitelist zu setzen (was den Datenschutzgewinn still aufhebt) und die föderierte Login-Domain zu vergessen, von der eine Website abhängt (was dich trotzdem abmeldet). Eine kurze, bewusste Liste und ein Bewusstsein für Identitätsanbieter-Domains beheben beides.

Sechs Fehler, über die neue Nutzer stolpern, und wie du jeden vermeidest:

• Alles “für alle Fälle” auf die Whitelist setzen — eine aufgeblähte Liste bedeutet, dass fast nichts je bereinigt wird; setze nur das auf die Whitelist, bei dem du wirklich angemeldet bleibst
• Den Identitätsanbieter vergessen — eine Website, die sich über accounts.google.com oder einen SSO-Host authentifiziert, braucht auch diese Anbieter-Domain auf der Whitelist, sonst geht der Login trotzdem kaputt
• Den Apex auf die Whitelist setzen, aber eine Subdomain brauchen — bestätige, dass die Subdomain-Vererbung an ist, oder füge die spezifische Subdomain hinzu
• Zu breite Wildcards — *.com ist keine Regel; beschränke Wildcards auf einen einzelnen Dienst wie *.googleapis.com
• Die Greylist als dauerhaft behandeln — Websites auf der Greylist werden beim nächsten Schließen trotzdem bereinigt, verschiebe langfristige Logins also auf die echte Whitelist
• Eine Website auf die Whitelist setzen, um clientseitigen Zustand wiederherzustellen — die Whitelist verhindert künftige Bereinigung; sie kann bereits gelöschte Daten nicht wiederherstellen

Die mit Abstand häufigste Support-Frage ist “Warum hat mich diese Website abgemeldet, obwohl ich sie auf die Whitelist gesetzt habe?” — und die Antwort ist fast immer eine fehlende föderierte Login- oder SSO-Domain. Im Zweifel setze sowohl die App-Domain als auch den jeweiligen Konto-Host auf die Whitelist, über den der Login umleitet.

Wie sich CookieVault mit einem manuellen Ansatz vergleicht

Kurz gesagt: Du könntest Cookies manuell löschen und dich neu anmelden oder die Cookie-Einstellungen pro Website des Browsers nutzen, aber keines davon gibt dir eine Ein-Klick-, synchronisierbare, Wildcard-fähige Allowlist, die an die automatische Tab-Schließ-Bereinigung gebunden ist.

Die ehrliche Anmerkung: Die browsereigenen Cookie-Steuerungen pro Website sind völlig in Ordnung, wenn dir nur ein paar Websites wichtig sind und du nie den Browser wechselst. Die Whitelist verdient sich ihren Platz, wenn du automatische Bereinigung von allem willst, dem du nicht ausdrücklich vertraust, plus dieselben Regeln auf jedem Gerät.

Free vs. Pro

Kurz gesagt: Die lokale Whitelist — unbegrenzte Einträge, Greylist, Wildcards — ist für immer kostenlos. Pro (4 USD/Monat oder 36 USD/Jahr) ergänzt verschlüsselte geräteübergreifende Synchronisierung, sodass deine Liste vertrauter Websites dir überallhin folgt.

Die Synchronisierung ist der einzige kostenpflichtige Teil, und sie nutzt denselben Zero-Knowledge-Stack, der auf der Seite verschlüsselte Cloud-Sync beschrieben ist — deine Liste vertrauter Websites wird auf dem Gerät verschlüsselt, und der Server sieht nur Geheimtext. Siehe die Preisseite für die vollständige Aufschlüsselung.

Wie du deine Whitelist aufbaust

1. Installiere CookieVault Guardian von der Download-Seite und hefte sein Symbol in der Symbolleiste an
2. Besuche dein primäres E-Mail-Konto (Gmail, Outlook, Proton) und klicke auf das Symbol → “Add to whitelist”
3. Besuche deinen Code-Host (GitHub, GitLab) und setze ihn auf die gleiche Weise auf die Whitelist
4. Setze deine Arbeitstools auf die Whitelist — die, bei denen du den ganzen Tag angemeldet bleibst
5. Setze deine Bank und die Web-UI deines Passwort-Managers auf die Whitelist
6. Füge Wildcards hinzu für jeden API- oder CDN-Host, der viele Subdomains nutzt, etwa *.googleapis.com
7. Setze einmalige Websites auf die Greylist, die du nur für die aktuelle Sitzung willst
8. Überprüfe die Liste unter Einstellungen → Whitelist und entferne alles, was du nicht mehr brauchst

Alles, was nicht auf der Liste steht, wird standardmäßig beim Tab-Schließen bereinigt. Für eine geführte Version mit Screenshots und Sonderfällen siehe die Anleitung zum Whitelisting von Cookies.

Siehe auch

• CookieVault Guardian — die Auto-Löschen-Erweiterung, die die Whitelist steuert
• Cookies beim Tab-Schließen automatisch löschen — was mit nicht gelisteten Websites passiert
• Anleitung zum Whitelisting von Cookies — Schritt-für-Schritt-Einrichtung mit Sonderfällen
• Cookies löschen, aber angemeldet bleiben — der Workflow, den die Whitelist ermöglicht
• Verschlüsselte Cloud-Sync — wie die Whitelist-Synchronisierung Zero-Knowledge bleibt
• Preise — Aufschlüsselung Free / Pro / Team