Have a container tab defined, add a greylist rule "✱.google.com" (obviously with a normal ascii asterisk and no quotes) to it.
You have a container tab with one rule (greylist, above), open a tab in that container, visit google.com search for "wiki", visit wikipedia, close the tab. (you will need other windows open to keep Firefox open). Note that the cookies for wikipedia were deleted and the cookies for google.com were not.
Repeat with both google and wikipedia on the greylist, note that now it doesn't delete cookies for EITHER site!
firefox-container-1
en.wikipedia.org (WMF-Last-Access): Clean because en.wikipedia.org is not in the White/Grey lists
wikipedia.org (WMF-Last-Access-Global, GeoIP): Clean because wikipedia.org is not in the White/Grey lists
NOTE google visited but missing
Enable Automatic Cleaning? Delay Before Cleaning: YES, 0
Enable Cleanup on Domain Change? NO
Enable Cleanup Log and Counter? YES (purely for diagnostic purposes, normally off)
Show Number of Cookies for that Domain? YES (I don't usually look at this)
Show Notification After Cookie Cleanup Second(s)? Yes, 5 (for diagnostic purposes, usually off)
Clean Cookies from Open Tabs on Startup? NO (with my Firefox settings there should NEVER be any tabs from previous sessions)
Enable Support for Firefox's Container Tabs? YES
Localstorage Cleanup (Firefox 58+)? YES
What's supposed to happen to cookies that match no rules? I would think that CAD would leave cookies it has no instructions for alone, but it seems to delete them right away for some reason.
Maybe you are confusing what the greylist does?
https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/wiki/FAQ:-Common-Questions-and-Issues#what-do-all-the-cleanup-options-mean
What's supposed to happen to cookies that match no rules? I would think that CAD would leave cookies it has no instructions for alone, but it seems to delete them right away for some reason.
That's how Self Destructing Cookies works and this extension is an inspiration from that with some enhancements.
https://www.ghacks.net/2013/01/15/self-destructing-cookies-for-firefox/
In a nutshell, it acts as a new cookie policy that basically automates keeping cookies for a site as long as that site is open. Once you close all instances of a website, all cookies from that website are gone provided you haven't white/grey listed them.
I think I am understanding the current design (not that it is working out for me)
Whitelist = don't delete at all (overrides all other rule, evaluated first, all action stop here if matched)
Greylist = delete later
No matching rule = delete right away
So how do I set the program NOT to touch cookies for websites I will encounter in the future?
What if I want to set it to delete all cookies from site example.com (either at browser launch or site exit) but no other sites?
Basically it's deleting ALL cookies from ALL site (ignore the effect of using Firefox containers feature for this example), so I whitelist ✱, now nothing is deleted (not even what I want to be deleted). So I need to whitelist every site I visit that I don't want to delete all cookies for (not practical).
I want it to delete cookies for certain websites on startup and leave everything else alone, but I can't seem to find a combination of settings that permits this. If I could edit the "No matching rule" action, or reorder my greylist entries to be evaluated first (followed by a whitelist ✱ rule) it would solve everything.
What i usually do for future sites if I want to keep them is to BEFORE the tab closes, go to the icon and grey/white list the site.
Otherwise for your needs, this webextension may not be the right one for you. Note the extension title cookie AUTOdelete.
Yes autodelete, but I wouldn't think that means to auto-delete things I didn't ask for. It's not auto-delete-everything-with-explicit-exceptions. It would be really nice to specify what to do when no rule is matched.
auto-delete-everything-with-explicit-exceptions -VS- auto-delete-just-exactly-what-I-want
automatically act: good
automatically act but the user can't fully control it: bad
current setup:
whitelist: if matched don't delete and stop evaluating rules (whitelist evaluated first)
greylist: lazy delete later
no match: aggressive auto delete (more aggressive than greylist)
preferred setup 1a:
whitelist: if matched don't delete and stop evaluating rules (whitelist evaluated first)
greylist: lazy delete later
no match: user has choice of "do nothing"(whitelist-like), greylist, or "aggressive auto delete"(default option to match current behavior)
preferred setup 1b (rules evaluated in configured order):
whitelist: if matched don't delete and stop evaluating rules
greylist: lazy delete later and stop evaluating rules
no match: aggressive auto delete (as currently)
1a seems to be the simplest, just give the user control of what happens when there is no match.
preferred setup 1a:
whitelist: if matched don't delete and stop evaluating rules (whitelist evaluated first)
greylist: lazy delete later
no match: user has choice of "do nothing"(whitelist-like), greylist, or "aggressive auto delete"(default option to match current behavior)
What's the point for no match? If you don't check the webextension while you're still on that page then perhaps turn off the ability to auto-clean, and click the clean button yourself when you deem it's time. Within the popup, regardless of match/no match, you're still given the option to greylist and/or whitelist if need be.
preferred setup 1b (rules evaluated in configured order):
whitelist: if matched don't delete and stop evaluating rules
greylist: lazy delete later and stop evaluating rules
no match: aggressive auto delete (as currently)
What's the difference on the greylist? lazy delete later = delete upon browser restart if no open tabs for that site. Technically once it hits greylist it doesn't delete until browser restart, unlike no match.
1a seems to be the simplest, just give the user control of what happens when there is no match.
Perhaps so, but then what's the point of trying to mimic 'self-destructing cookies' then - it is not 'self-destructing' at all if it requires user-intervention first...
I can't tell if this issue is a duplicate of #501 or not at this point based on the comments in each issue.
Also crunching this up to feature request blacklist. I think the options for blacklist will be per domain - i.e. blacklist - remove asap, remove on tab close, remove on domain change, remove on browser restart. as part of the options.
Blacklist request is now duplicate of #134