Cookie whitelist

TL;DR: The CookieVault cookie whitelist is a per-domain allowlist that exempts trusted sites from auto-delete — so you keep logins for the sites you use daily while everything else is cleaned on tab close. Subdomain inheritance, wildcards, and a greylist keep the list short; the local list is free, and cross-device sync is Pro.

The cookie whitelist in CookieVault Guardian is a per-domain allowlist that overrides auto-delete behavior, so whitelisted origins keep their cookies and site data across tab closes while every other domain is cleaned the moment its last tab closes. It is the modern reimplementation of the classic Cookie AutoDelete allowlist model, extended with subdomain inheritance, wildcard patterns, and a greylist for session-only sites. In practice the whitelist is the most important setting in the whole product: it is the single dial that decides which logins survive and which disappear.

How the whitelist works

In short: Add a domain by clicking the toolbar icon on the site. Subdomain inheritance is on by default, so one entry covers a whole service. Whitelisted domains are simply skipped when auto-delete runs after the last tab closes.

Cookies are how sites remember you between requests; MDN documents that the session cookie is what keeps you authenticated¹. The whitelist works by telling Guardian to leave a domain’s cookies — and its session cookie specifically — in place when cleanup would otherwise fire. CookieVault reads and preserves those records through the official browser cookie API², so a whitelisted login behaves exactly as it would with no extension installed.

Six mechanics that make the list manageable:

• One-click add — click the toolbar icon on any site and choose “Add to whitelist”
• Subdomain inheritance (default on) — example.com also exempts mail.example.com and app.example.com
• Exact-host mode — turn inheritance off to whitelist only the apex and clean its subdomains
• Wildcards — *.googleapis.com covers every subdomain of an API or CDN host in one rule
• Greylist — session-only exemption that cleans or auto-promotes on the next close
• Unlimited locally — no cap on entries in the free, local list

A reliable principle for allowlists is to keep them short and intentional: a small, well-chosen list is easy to reason about, while a sprawling one quietly defeats the privacy goal.

Whitelist vs greylist

In short: Whitelist means “never clean, keep across sessions.” Greylist means “keep for this session, then clean or auto-promote on the next close.” Use the whitelist for permanent logins and the greylist for one-off visits.

The greylist exists because real browsing is not binary. Sometimes you want continuity for the next hour on a site you will never return to — the greylist gives you that without permanently growing your whitelist.

Common whitelist mistakes

In short: The two failure modes are whitelisting too much (which quietly cancels the privacy benefit) and forgetting the federated-login domain a site depends on (which logs you out anyway). A short, deliberate list and an awareness of identity-provider domains fix both.

Six mistakes that trip up new users, and how to avoid each:

• Whitelisting everything “just in case” — a bloated list means almost nothing ever cleans; whitelist only what you genuinely stay logged into
• Forgetting the identity provider — a site that authenticates through accounts.google.com or an SSO host needs that provider domain whitelisted too, or the login still breaks
• Whitelisting the apex but needing a subdomain — confirm subdomain inheritance is on, or add the specific subdomain
• Over-broad wildcards — *.com is not a rule; scope wildcards to a single service such as *.googleapis.com
• Treating the greylist as permanent — greylisted sites still clean on the next close, so move long-term logins to the real whitelist
• Whitelisting a site to recover client-side state — the whitelist prevents future cleanup; it cannot restore data already deleted

The single most common support question is “why did this site log me out even though I whitelisted it?” — and the answer is almost always a missing federated-login or SSO domain. When in doubt, whitelist both the app domain and whichever account host the login redirects through.

How CookieVault compares to a manual approach

In short: You could manually clear cookies and re-login, or use the browser’s per-site cookie settings, but neither gives you a one-click, syncable, wildcard-capable allowlist tied to automatic tab-close cleanup.

The honest note: the browser’s own per-site cookie controls are perfectly fine if you only ever care about a couple of sites and never switch browsers. The whitelist earns its keep when you want automatic cleanup of everything you did not explicitly trust, plus the same rules on every device.

Free vs Pro

In short: The local whitelist — unlimited entries, greylist, wildcards — is free forever. Pro ($4/month or $36/year) adds encrypted cross-device sync so your trusted-sites list follows you everywhere.

Sync is the only paid part, and it uses the same zero-knowledge stack described on the encrypted cloud sync page — your list of trusted sites is encrypted on-device and the server sees only ciphertext. See the pricing page for the full breakdown.

How to build your whitelist

1. Install CookieVault Guardian from the download page and pin its toolbar icon
2. Visit your primary email (Gmail, Outlook, Proton) and click the icon → “Add to whitelist”
3. Visit your code host (GitHub, GitLab) and whitelist it the same way
4. Whitelist your work tools — the ones you stay logged into all day
5. Whitelist your bank and your password manager’s web UI
6. Add wildcards for any API or CDN host that uses many subdomains, such as *.googleapis.com
7. Greylist one-off sites you want only for the current session
8. Review the list under Settings → Whitelist and trim anything you no longer need

Everything not on the list cleans on tab close by default. For a guided version with screenshots and edge cases, see the whitelist cookies how-to.

See also

• CookieVault Guardian — the auto-delete extension the whitelist controls
• Auto-delete cookies on tab close — what happens to non-whitelisted sites
• Whitelist cookies how-to — step-by-step setup with edge cases
• Clear cookies but stay logged in — the workflow the whitelist enables
• Encrypted cloud sync — how whitelist sync stays zero-knowledge
• Pricing — Free / Pro / Team breakdown