Cookie-autodelete: Gray list enhancement or additional option (Deny all cookies/Allow with Exception)

[bendover22]

Describe the Bug/Feature

More of feature request, or explanation of expected behavior.

Screenshot in which the bug can be seen

Steps for anyone to reproduce the bug

Your settings

• OS/version: Linux Mint 18.1
• Browser/version: Fx 54.0.1 64bit
• Cookie AutoDelete version: 1.4.1

Best I can tell, Cookie Auto Del. (we calling it CAD?) gray list cookies & exceptions are only deleted when browser closes, or if for each "gray" site, you check "Clean after tab closes?" Is there a possibility to add a sub-option, where gray list items would automatically delete when all tabs for the "gray" URL are closed (maybe a user-set delay, in case of accidental closing)?
Cookie Monster (R.I.P.) had separate options to clear session cookies (leave exceptions), or temporary cookies & exceptions when those tabs closed. Many seemed to like it.

1. User is probably setting a gray exception ("temporary" in Cookie Mgr) because they don't fully trust it, nor want cookies set on any drive by. Personally, if I set a gray exception & cookie, it'd be rare to want them until the browser closed.

2. Sites are owned or operated by the same entity; sites could also agree to trade info on visitors - I'd be very surprised if many don't. A lot of tracking can go on by the time you close the browser. For users not employing NoScipt, uBlocko / AdBlock, etc., then I imagine 3rd parties might see some 1st party cookies, in some situations.

3. Yes, there's a manual "Cookie Cleanup (Ignore Open Tabs)" in CAD. I know I & many users will often forget to manually cleanup gray cookies.
   IMO, it'd be desirable to have an option to delete gray cookies / exceptions when tabs close , OR wait till browser closes. Those options in Cookie Mgr seemed well received.

[ke-d]

This request confuses me but I'll try to answer the best I can.

Is there a possibility to add a sub-option, where gray list items would automatically delete when all tabs for the "gray" URL are closed (maybe a user-set delay, in case of accidental closing)?

Do you mean the greylist in C-AD options or cookie items?

User is probably setting a gray exception ("temporary" in Cookie Mgr) because they don't fully trust it, nor want cookies set on any drive by. Personally, if I set a gray exception & cookie, it'd be rare to want them until the browser closed.

What you are asking is a deny-all cookies approach right? Instead of the allow-all approach that SDC and C-AD has currently.

[bendover22]

Thanks for prompt reply.
I'm asking little of both, I suppose.
C-AD may do it this way, but I just don't get allowing every site visited to set even 1st party cookies. Is there a point I'm missing?
So yes, I'd very much like to see users have the option to allow 1st party cookies on all sites (if they have some reason), or deny all by default & give (temporary) permission selectively, as in Cookie Monster. Of course, users will keep an exceptions list for sites they always want to allow (either session or permanent cookies - users' choice).

Some sites require cookies for a page to load, but not many. In Cookie Monster - for years - I've had "block all cookies by default" set, and really never had a problem.

In the few out of 1000's of sites visited that I don't have exceptions saved to "always allow session (or permanent) cookies for Example.com", for the few I needed to allow temporary cookies to navigate a site, it's literally 2 clicks to allow "temporary cookies" for that domain.

And (if you choose) those get deleted when those tabs close. Or, had the option not to delete the temporary (gray) cookies & their exceptions, until closed the browser. Or if important, you could selectively delete specific cookies - which C-AD can do.

Personally, if I did allow cookies (or I'm forced to) for a site I've never visited & likely won't again, I'd prefer to delete them ASAP - not wait 2 or 8 hrs.

Now, C-AD gray cookies don't delete automatically until browser closes, or you remember to manually delete them.
I was (also) asking about an additional option to automatically delete gray cookies when their tabs close (again, maybe w/ some delay - for accidental closings). Not wait till end of session.

One reason I don't like allowing cookies on all sites is, they often start showing you only "things" based on what you've already looked at. Just like Google & other search engines filter bubble concept, but not limited to search engines.

[ke-d]

So yes, I'd very much like to see users have the option to allow 1st party cookies on all sites (if they have some reason), or deny all by default & give (temporary) permission selectively

Hmm, it's not out of the question for that feature to be implemented. I'll have to look and see if "block all cookies" can be done with WebExtensions.

C-AD may do it this way, but I just don't get allowing every site visited to set even 1st party cookies. Is there a point I'm missing?

SDC does it this way because it's less micromanagement on the user as like you said

some sites do require cookies, but not many.

Personally, if I did allow cookies (or I'm forced to) for a site I've never visited & likely won't again, I'd prefer to delete them ASAP - not wait 2 or 8 hrs.

Isn't that the default cookie popup setting Clean after tab close?

Now, C-AD gray cookies don't delete automatically until browser closes, or you remember to manually delete them.

Some gray cookies won't delete unless you enable Clean Cookies from Open Tabs on StartUp

[bendover22]

Yes, of course "Clean after tab close" works. It's great for users that don't want to be bothered about anything. But even browsers provide an easy way to toggle rejecting or accepting all 1st & 3rd party cookies, instead of "you MUST accept all 1st party cookies, while a site's tab is open."

Since Firefox allows rejecting all cookies, maybe webext addons could also?

I assume browser devs gave users this option because many are interested in blocking all cookies (at least sometimes).

Don't misunderstand - you have an excellent product, especially considering it's very new. An outstanding job so far.
A thought: maybe consider adding to C-AD's description - "all 1st party cookies are accepted by default, which can't be turned off if using C-AD (at this time)." Then the explanation how gray cookies can be deleted.

I think many users are surprised to find there's no option to block all cookies, as the browser allows.
Thanks!

[ke-d]

I think many users are surprised to find there's no option to block all cookies, as the browser allows.

I think that most of C-AD's users are coming from Self Destructing Cookies which is C-AD is based on.

[monkeymagic29]

Yeah, it does sound similar.
The (arguable) difference is:
I'm not necessarily asking you to implement CAD into an all-block. Firefox already internally does it with its cookie manager. With SDC, in Android, it simply gives a simple GUI for me to whitelist it (seems like Fennec always had the built-in capability for it, just without GUI for users). In desktop, SDC only opens Firefox cookie manager for whitelisting (which I believe was mirror to what was done in Fennec). What I want is probably just that: to maintain add-on as such that it maintains servility (at least on how SDC used to be) to Firefox internal cookie manager.

@bendover22, maintaining two features like that is somewhat gonna cost more resources, I think. The way I've been maintaining that cookie management is with separated profiles; 'strict' for browsing with red httpse, no js, no cookie, no single whitelisted UBO; 'banking' with only UBO, js, and cookies allowed for banks; shopping, testing, and lenient browsing. I believe separate profiles will protect you much better from tracking, especially if you dig even deeper with proxies, user agents, other addons, and other settings. That way you can safely whitelist sites on their designated profiles, and you can browse shady sites without any concerns of tracking based on cookies. Remember, those crucial banking cookies aren't your friend, just necessary evil. They, too, may track you, so whitelisting them and then browse something else on the same profile isn't as protected as browsing on separated profiles.

So, to be honest, I don't think people even need SDC or CAD to maintain cookies on desktop, just an extra reinforcement that'd be nice to have. For mobile platform like Android, however, where one could not easily access Firefox cookie manager nor ProfileManager... Here's where CAD should come to rescue.

[ke-d]

If I ever implement a blacklist list type under 2.X.X+, then I think it would be possible to use a wildcard in the blacklist to do something similar to "Deny all cookies". It's still a while before I consider this as an option.

[bendover22]

I don't think people even need SDC or CAD to maintain cookies on desktop, just an extra reinforcement that'd be nice to have.

I disagree. The popularity of cookie related addons indicates otherwise. Firefox's "cookie manager" is so lame, slow & "all or nothing." You have to manually copy / type in exceptions (whitelist or blacklist; permanent or session). Can't selectively highlight multiple cookies & delete. It's a joke.
I'm obviously missing something if very many people [that know about or care about privacy, tracking, etc.] think Fx cookie mgr is just fine.
Kenny:

If I ever implement a blacklist list type under 2.X.X+, then I think it would be possible to use a wildcard in the blacklist to do something similar to "Deny all cookies". It's still a while before I consider this as an option.

Again, I wasn't suggesting a black list, though some users may like that & use it.
I realize it's early in C-AD development & things take time. What I'm not sure we agree on, is why users want to block 1st & 3rd cookies, by default? You showed earlier you have 3rd party cookies enabled. That's a personal choice.

I'm not trying to insult or anger anyone, just explain a different view of millions of users.
Clearly, you aren't concerned about trackers. So, perhaps it's a foregone conclusion you may not put a high priority on maximum privacy in handling cookies? Don't know. I'd be surprised if you don't know all about trackers (cookies or not) & why many users are keen on preventing most trackers and not allowing all cookies by default.

If you really don't know all the data trackers can collect & what they are doing w/ it (even tie it to real names, home addresses, emails, personal medical history, political interests, religion - on & on), I'll send you some links - only if you want. [FYI - I can't remember a site ever breaking by blocking 3rd party cookies, but I haven't seen every site. I've never allowed 3rd party cookies, back to Netscape.]

It was an ENORMOUS, huge, huge deal, when Google was caught bypassing [read: hacking] Safari's & IE's cookie settings blocking cookies. https://www.wired.com/2012/02/google-tricks-internet-explorer-into-accepting-tracking-cookies-microsoft-claims/

Why _was_ it such a huge deal to the browsers devs & their users?" The answer is, because many users & devs are - not - fine allowing them for no reason, then making sure they get deleted, if & when tabs close.

What I'm suggesting is, users wanting C-AD's features, not constantly go between Fx cookie mgr & C-AD (or any other cookie mgr) to manage cookies. Sometime. Because Fx cookie mgr is sad.
If I'm forced to use Fx cookie mgr, I may as well use Tor Browser or an ER or a fork, that allows legacy addons.

AFAIK, Fx 57 still has much the same cookie mgr interface & (limited) features. One is blocking cookies totally. I'm guessing that a webext addon can't use that feature. And (in the little research so far), maybe the cookies API doesn't have a "block all cookies" option, even though Fx 57's cookie mgr allows blocking all? Does that sum it up?

Of users that even know what (any) cookies are & care, a large % of those likely turn off cookies by default. Not, "accept all cookies, then worry about deleting them." If Mozilla thought no users blocked all cookies by default, they'd likely remove that option.

A problem is, if a tab doesn't get closed, cookies aren't deleted by C-AD.
If you have 20 - 40 tabs open (may go back), that's 20 - 40 sites of cookies. It's entirely possible some of those are run by the same person or company. Or, sites share data & it's getting more likely all the time. It happens ALL the time in business - sharing data. "You scratch my back..."

Many of those sites didn't need cookies, to work at a basic level. So why set cookies w/o a need?
Sites may not share your real name, but fingerprinting browsers technology is becoming more advanced. Allowing all cookies by default may only make their job easier, if anything.

Companies like Google (many others) don't care about "laws," on what they can / can't do with cookies, or anything else. They've shown that time & again. If companies - making tons of $ - get caught, they pay a fine & go back to making money. It's naive to think it's impossible or illegal for sites to share cookie data with other sites or trackers & therefore, they won't.

Getting late. If I misspoke, insulted anyone, etc., send me a polite PM & I'll apologize.
Thanks.

[ke-d]

@bendover22

You showed earlier you have 3rd party cookies enabled. That's a personal choice.

Only for visited sites which are different than accepting them all together. I remember this solved a problem with the LastPass extension and site back when I still used it.

Again, I wasn't suggesting a black list, though some users may like that & use it.

In 2.X.X, there's an option of setting a wildcard. So for something like #131 , adding '*' in the greylist would suffice. Something similar would happen _if_ I implement a blacklist type. It's so that I don't have to add a separate setting.

I'd be surprised if you don't know all about trackers (cookies or not) & why many users are keen on preventing most trackers and not allowing all cookies by default.

I understand those people, but there are those who still don't want to micromanage everything. This is probably why SDC as a cookie extension has over 200k+ users.

[ElhemEnohpi]

SDC actually supports "default deny" cookie policy by setting an about:config preference. I've been using it for years and it works perfectly!

I find that it gives better protection from tracking cookies when many tabs are open, without much "micromanaging" necessary. Most websites work fine without cookies. Maybe a few times a week I have to click one button to temporarily allow self-destructing cookies for a broken site. For me, it's worth the peace of mind.

From the SDC FAQ:

Q: I have configured Firefox to block all cookies by default. Can I still use SDC?
A: There is an unsupported hidden setting that changes the behaviour of the "yellow" whitelist level from allow-for-session to allow-while-open. To enable it, create a boolean key in your about:config named "extensions.[email protected]" (without the quotes), set it to true and restart your browser. You can now use the "yellow" setting for sites whose cookies you would like to accept, but still have them self-destruct.

In order for C-AD to support this, it would require at least:

• a method to block all cookies by default, such as a blacklist with "*" in it
• a method to greylist (well, that's taken, let's call it "greenlist") sites, to allow them to set self-destructing / clean-on-close cookies
• a method to temporarily greenlist a one-off site visit without cluttering the list; cleared on browser restart

Here's the too-long explanation for reference, feel free to don't read:

The way it works in SDC, in legacy Firefox, is:

1. In Firefox Preferences, uncheck "Accept cookies from websites". By default, no site will be allowed to set any cookies.
2. Click "Exceptions", and add an "allow" exception for any site you want to whitelist to keep cookies for permanently, for example if you always want to be logged in to some site. These cookies are never touched by SDC.
3. Add an "allow for session" exception for any site you want to have cookies allowed only while the tab is open, and self-destruct when it's closed. (Because the Firefox built-in "allow for session" permission is repurposed for this, it's not possible to have true session cookies; in this mode, session cookies are always self-destructed.)
4. As SDC doesn't have a temporary permission function, an additional add-on is necessary in order to give temporary "allow for session" permission to sites that you may only visit once, but don't work without cookies. This lets you avoid having thousands of "allow for session" exceptions build up in the exceptions list. "CS Lite (mod)", "CookieShield", and "Cookie Controller" can all do this.
5. Sometimes it's necessary to temporarily allow cookies for all sites, which can be done with Cookie Controller. But I also use the "Cookie Whitelist with Buttons" addon (mentioned in #210), it has a button that enables "Accept cookies from websites", keeps track of what cookies are set, and then removes them all when the button is clicked again.

Some of this is actually possible with C-AD in Firefox 57, by doing this:

1. In Firefox Preferences, uncheck "Accept cookies from websites". By default, no site will be allowed to set any cookies.
2. Click "Exceptions", and add an "allow" exception for any site you want to whitelist to keep cookies for permanently, for example if you always want to be logged in to some site. Also add the site to C-AD's whitelist so that it won't be touched.
3. In "Exceptions" add an "allow for session" exception for any site you want to have cookies allowed only while the tab is open, and self-destruct when it's closed. (Adding an "allow" exception would also work).
4. Unfortunately temporary permission is difficult because there's no API for WebExtensions to control built-in cookie permissions, and therefore no real cookie managers. So you would have to do this manually. Go to "Exceptions" (or Page Info - Permissions), and set an "allow for session" exception for the site. Then remember to remove it when you're done with the site.
5. See 4. - manually enable "Accept cookies" temporarily, then clean them up.

In order to fully support this on its own, C-AD would need to offer:

1. A setting to block all cookies by default (or at least to remove them immediately, if that's all that's possible). A blacklist with "*" in it should also work.
2. Nothing needed, whitelist already exists.
3. Probably another list - a greenlist? - for sites that are allowed to have cookies that are cleaned when the tab is closed. I suppose the Greylist could be repurposed for this, the way SDC does, but it should be easy enough just to add another list. Or, some other method I haven't thought of...
4. A button to temporarily greenlist a site, without actually adding it to the list. Cleared on browser restart.
5. I think the "Auto Clean (dis)Enabled" button does this, though I'm not sure if it automatically cleans everything when it gets re-enabled.

[drcheap]

This is a bit of a "me too" post, but I just want to show my support...

As a long time user of Cookie Monster I have been really hunting around for a WebExtensions based replacement. C-AD is really the closest thing I can find, but the only one thing it's really missing is the default-deny aspect that it has. The "temporary allow" feature is nice, too, but I could very well live without that compared to the powerful default deny ability

The whole point of all this is that the cookies should not even be stored in the first place, unless they are explicitly allowed. In other words, to be in control of one's cookies means only you decide which ones are accepted. Some call this "micromanagement" but really it's not that big of a deal to perform 2 extra clicks at a new site to greylist/whitelist, then you don't have to worry about it again. And this is only on sites you intend to use more deeply or more often -- most work just fine w/o any cookies anyway.

[bendover22]

@mrdokenny - you mentioned a while back, "blocking all cookies" and "micromanagement" in the same sentence. It's your project & I respect that, but I can't think of many browser functions that are less "micro" than things that "block all..." or "Allow all...". Blocking all cookies is the opposite of micromanagement.

@ ElhemEnohpi - a good, detailed post. I don't know if it'd work - maybe, but hopefully it gives mrdokenny some ideas to work with.
@ drcheap, I agree in general, but the web ext API for cookies doesn't specifically have a "block all cookies" option (at this time), so it's not the dev's fault. Something like ElhemEnohpi wrote might work, or users could start hounding Mozilla relentlessly to add a deny all cookies option to the API.

I question Mozilla's true intent about doing / not doing a number of things over the yrs.
Like taking way too long to fix things (5, 10+ yrs) that were privacy related or things that made it easier for trackers. They were in bed w/ Google a long time. "Locking Firefox down tight" while getting 100's of millions from Google - who thrives on collecting private data, wasn't in Mozilla's best interest.

And now Mozilla's basically copied many of Chrome's APIs for Firefox (it says so on the API description page), so it doesn't surprise me at all that there's not a "block all cookies" API option. Do we really expect Google's APIs to be privacy focused?

I suspect Mozilla will be swamped with requests to add API options, and they will add or ignore the ones best serving the companies that pay them, or will increase their own revenue from ads, etc. Like any other company or politician, they promise a lot. Mozilla - the browser may be a non-profit, but the company that owns them is not. :D

[ElectricFeet]

@mrdokenny : "SDC does it this way because it's less micromanagement on the user as like you said"

@bendover22 : "Blocking all cookies is the opposite of micromanagement."

Agree wholeheartedly. This is what I'm really missing since the demise of Cookie Monster. Cookie Monster allowed you to:

1. Block everything by default (from Firefox Preferences); and then
2. Allow cookies if you need them on a particular site — whitelist (allow) or greylist (allow for session); and
3. (as needed) Temporarily allow them on a particular site (generally when the site broke without cookies).

[Cookie Monster also allowed a "revoke all temporary" permissions option, but this is obviated by Cookie Auto-Delete's automatic cleaning on tab close.]

To give a concrete example: with Cookie Monster, google could never set any cookies on my machine (I don't use gmail, so there really is no need). BUT, if I wanted to login to webmaster tools and do some work, I could temporarily allow and then revoke when I'd finished (revoking deleted the cookies too). Ditto shopping sites: no cookie to browse, but allow temporarily for active buying.

It would be great if the option to block all cookies by default could be added. And even greater if a "temporarily allow" could be added as well.

p.s. Is Self Destroying Cookies using this code base with a different GUI?

[jstetten]

@ElectricFeet has most precisely described what many of us are seeking. I feel like there are a lot of us out there who love to return to this workflow.

I'm just a user of your great add-on, but to me the above seems well within the possibility and scope of C-AD.

[ke-d]

I'm setting this as a limitation of the API for right now as there's no way to do a "true" blocking of cookies.

Additionally, localstorage cleaning support (that I'm testing internally now) requires cookies to be set since the browsingData API requires a list of domains to be passed in (which is convenient since cookie cleanup provides this).

[ElhemEnohpi]

I don't think you need to do a "true" blocking of cookies, do you? Isn't just deleting them as soon as they're set good enough?

[grenzor]

Looks like functionality to do this landed in Nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1363860

[ElhemEnohpi]

No, that just lets web extensions control the preferences setting for the blanket "accept cookies from websites". Since there's no functionality to control the setting per-website, and since C-A-D is meant to replace the built-in cookie permissions system anyway, that functionality isn't of any help at all.

[bendover22]

The comments on bug 1363860 go back & forth. The change for Fx 59 is too long to read right now.
Unless sites or trackers could still glean info about users or their system by setting cookies which are immediately deleted (one proposal) it doesn't matter to me if they're immediately deleted or outright denied.

I would very much like the option to temporarily allow cookies - per site, for ONE time, then all traces are deleted.

It sounds like one way or another, users or addons will be able to set deny all cookies as a default.
I don't know if they'll allow "temporary" cookies on Example.com for that session, but never again, unless users choose give another temporary permission in the future.

The fact that Firefox - maybe other browsers - think users should only have limited choices for handling cookies sounds very "Google-ish" to me. A little like, "We know best what cookie options users need." Personal usage & personal data is big business. I doubt Mozilla wants sites to start blocking Firefox or make it difficult to use such sites, if too much info from the browser is kept from the sites.

I wonder how brick & mortar store shoppers would react, when they walk in a device is "set on them," that monitors their every move. If you don't want to wear it, you probably won't be able to see lots of things in the store. I'm pretty sure I know the answer. Yes, they have security cameras, but they don't know everything you read or even look at for 3.274 seconds.

[ke-d]

This would most likely conflict with #44 for the case where a site uses only localstorage and no cookies. The way CAD is implemented currently is to set a temp cookie for that site. Then when cleanup happens, CAD can just send the hostnames to the browsingData API.

So the only way to do a blacklist AND have localstorage cleanup is to persistently store which hostnames have not been cleaned yet in the extension which could have some privacy problems of its own. Also, it would take a while to code that as well.

Now one thing I am wondering if it works is if you block cookies globally (either manually or using the API in 1363860), then if the cookies.onChanged event would still work?

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/cookies/onChanged

If it does then a blacklist/deny all cookies could be implemented.

[bendover22]

Been a good while since we 1st discussed a feature / concept of "delete cookies on a gray list immediately after they're set," instead of when tabs or the browser are closed. Assuming that Deny All Cookies by default isn't possible Are we getting any closer to this ability being added?

There have been some changes in the cookie API, but do they allow gray list cookies to be deleted more easily / more quickly, after they're set?

I'm still using Firefox ESR, until some important functions of legacy addons are possible in web ext addons.

[bendover22]

It's been even longer now. :) Is there a chance that for sites where users don't want to whitelist or graylist cookies, that cookies on all other sites could either be denied, or deleted immediately after they are set, rather than waiting till tabs for a site are closed? The latter option was discussed after some changes in the cookie API.

Will the current cookie API not allow a user to UNcheck "Accept cookies and site data" (denying them by default), then allow CAD to set white or gray list exceptions for desired sites?

It's puzzling that Firefox's own cookie mgr allows blocking all cookies, but webext addons can't use this as an option? Why is that? Addons simply utilizing what Fx 57+ already allows users to do via the UI isn't accessing or changing Fx internal functions.

If the cookie API just won't let cookie extensions utilize the existing "block all cookies" function, or addons are unable to try and make it work, maybe more advanced users will have to write scripts to do some fairly simple things, as a work around.

From Firefox UI (at least v60) users can block all cookies by default, then set session or permanent exceptions.
It appears in later Fx versions (60+), Fx is removing the ability to view / edit / delete set cookies directly from the cookies mgr - now in Settings & Site Data. If you don't use a cookie addon, there are still ways to see & edit cookies, but it's a bit more trouble. https://www.ghacks.net/2018/02/26/mozilla-removes-individual-cookie-management-in-firefox-60/

It's possible that Mozilla doesn't want "average" users deleting cookies (out of sight, out of mind). It's possible that what ever is good for Google is good for Mozilla $$$. Google likes cookies from sites to be in browsers, especially its own cookies.

[bendover22]

How are we coming along on - at least - having an option, to automatically, immediately delete cookies, ...IF... they aren't whitelisted?
I don't want to enter URLs for every site I've never visited on a black list.

Have any changes to the cookie API allowed either denying cookies by default or immediately deleting any that either aren't whitelisted, or you don't gray list for that session?

I really don't want to switch to a browser that can't either block or immediately delete unwanted cookies (if selected in options). Other users should have the option to accept all 1st party session cookies, if they choose.

Using Firefox 52.9.0 esr, I can no longer log into my user account on my ISP's site (AT&T), because they they "_only support the 2 latest Firefox versions_."
So I can't view bills, add / delete credit cards for payment, & other vital functions.

I guess they don't consider Fx ESR versions ARE the latest, in terms of security updates. If they were NOT, corporations wouldn't be using them.

I also can't login (webmail) to my "master" email acct to make changes (e.g., spam filters, alerts I want to get, etc.). THAT email address is how they communicate official business to me. Maybe I can use a NON-AT&T email for official communication. Last time I asked, maybe 1 - 2 yrs ago, they said "no."

I don't use that or any AT&T email acct, other than to communicate w/ AT&T.
But that "master" AT&T acct is used to reset internet connection passwords & other important functions, as mentioned.

Maybe? I can just drop the AT&T email, and / or tell them I don't want to use an AT&T email for my "official" AT&T communication, to send me important notices, because they've locked me out, thinking I'm not using a secure browser.

[ElhemEnohpi]

Fyi, I've switched to Forget Me Not, which has a "default deny" capability. You can set the default action for sites that don't have a rule (are not on a white/grey/etc. list), and one of the options is "block". It doesn't have a way to set an allow rule temporarily, but I've made a feature request for that.

I don't know if it actually blocks cookies from being set in the first place, or immediately deletes them, but whatever, it works...

[bendover22]

Yes, I've tried FMN. Like most web ext. addons at this point, it's got some flaws, but generally works. A problem is (I believe), if you want to block most cookies (blacklist - deletes "immediately" - though people disagree on how long that is), then you really don't want cookies enabled in Fx cookie "mis-manager." If you do that, then FMN & assume other cookie mgrs "won't have any cookies to work with."

Unless - I believe, if you add exceptions to Fx cookie mgr. Then cookies will be blocked except the domains you entered exceptions for. Why cookie mgrs can't do this, if the statement is true, "quantum addons can do the same thing(s) that users can do manually thru Fx preferences."

That's what Cookie Monster used to do for session or permanent cookies - add the exception to Fx. Don't know if it's possible for quantum addons?

If you enable all cookies - at least 1st party in Fx , then FMN & other cookie mgrs have cookies to work with, but cookies from entities that Mozilla's in bed with will be let through. cough, google, cough. If they're in bed with google, then probably by default, they're in bed with 3 - letter agencies, whether they want it or not.

Maybe adding black list rules for most google domains would stop them, but every once in a while, some site you need requires (various) google domain scripts and / or cookies. Giving temporary permission, over riding block or blacklist isn't easy - so far. Mozilla doesn't really want us to block cookies - especially from certain parties. It's a mess.

[bendover22]

I won't beat this almost dead horse, much more. :D
Wanted to ask (anyone) - didn't I see something near the end of 2018, about Mozilla adding cookie API option(s) that allowed new cookie options? I thought it was about blocking cookies by default? I was in a hurry & skimmed the article but forgot to bookmark. Searching hasn't turned up anything.

An option to "Black list cookies by default" (if no other rule exists for a domain) isn't the best solution, but Forget Me Not addon has used it for some time.

[kennethtran93]

Let's see if I can try my hand at this...and as an attempt to try to close old issues/requests when possible.

I think Firefox has a block all now...as well as its own cookie preference to allow/allow for session though you would need to enter in the URL yourself.

Web Extensions, for the most part, cannot see what settings you have put into Firefox Preferences, unless the relevant permission is given.

Web Extensions cannot see Firefox's internal cookie preferences (the window that shows block/allow/allow session).

Greylisting will stay as is (browser restart). I'll need to relabel a few things to make the wording better.

Delete cookies by groupings of sites is not easily doable at this time with the way that CAD is currently.

Blacklisting...has two categories and will need another label

• A) delete cookie upon creation/update via cookie.onChanged (doable). -->perhaps 'BlockList'?
  
  
  
  • Default Block isn't appropriate due to the usage of Grey and Whitelist ... as anything outside those lists are usually deleted in CAD cleanup cycle. However this is probably as close if you have a specific site that you don't want cookies to be set for, or to quickly delete a specific cookie for that site that was just created/updated.
  
  
• B) always delete cookies/sites on regular cookie cleanup cycle --> perhaps the actual 'Blacklist'...
  
  
  
  • Probably more feasible to implement.
  
  

Thoughts?

[ElhemEnohpi]

As I mentioned in my comment above from December 2018, Forget Me Not has a cleanup type of "immediate", and it can be set to be the default type. Since then, the ability to make a temporary exception has also been added. It works reasonably well. The only problem is that some sites have scripts that will keep trying to set a cookie if it's deleted, and get into a loop.

[kennethtran93]

Crunching this up to Blacklist. Duplicate of a (later issue) #134