Cookie management models in Firefox Quantum in practice

September 9, 2018

I was recently reading The WebExtocalypse (via Planet Debian) and ran across the following bit about Firefox Quantum replacements for old non-WebExt extensions:

Some packages are no longer useful upstream but alternatives are available:
[...]

My immediate reflexive reaction was 'these two things are not alike'. I like and use both Cookie AutoDelete and uMatrix, but they have different ways of handling cookies that give you somewhat different results, and neither of them is perfect.

At a hand-waving level, we can break down what happens with cookies into three separate things: whether a website is allowed to set cookies that Firefox will store, whether existing cookies are provided to the website in requests, and whether cookies that are set by the website are later deleted (whether the website likes it or not), and when. The two extensions choose different options here, with different effects and complications.

In Cookie AutoDelete, things are simple; it does nothing to change Firefox away from accepting cookies from websites or returning them to websites. All it does is delete website cookies some time after you close the website's tab (unless you've told it otherwise for specific websites). In effect it makes all cookies into rapidly expiring session cookies, but while they exist the website can track you (during your session on it, for example).

(Based on some testing I just did, it appears that CAD expires third party cookies even if you still have a tab open on the first party website that led to their creation. This is sensible but possibly something to watch out for.)

In uMatrix, cookies are always accepted from websites but not provided back to them unless you permit this. uMatrix normally leaves accepted cookies in the browser, but you can turn on a non-default setting ('delete blocked cookies') that deletes some or all cookies from blocked sites. uMatrix's documentation isn't clear about what cookies are deleted here; it could be only cookies that the site set in this request, or it could be all cookies from the site. Thus, uMatrix hides cookies from websites but allows your browser to accumulate them, and these cookies may potentially be returned to the website later under some circumstances (I believe one way is through Javascript).

(I'm also not sure how uMatrix's optional deletion interacts with Firefox's first-party isolation, if you've found that and turned it on. Cookie AutoDelete is currently explicitly incompatible with FPI.)

It's my belief that deleting blocked cookies in uMatrix interacts badly with fine grained choices of first party versus third party cookie permissions. To use a concrete example, I want to carry a Google cookie to control my Google search settings, but I don't want to allow Google to see cookies when it's a third party site embedded into people's pages and so on (so it has a harder time of tracking me around the web). If I tell uMatrix to delete blocked cookies, I suspect that I would be losing my Google search cookies any time I visited a page where Google was embedded as a third-party site.

(This is a version of how global Javascript permissions aren't a great fit with the modern web.)

Neither of these extensions actually prevents websites from setting cookies in the first place. I'm not sure that's something that a web extension can even do in Firefox; the WebExtensions API may be too limited, either in theory or in practice. I think that an ideal extension would offer uMatrix-like fine grained control over what websites can even set cookies (as well as be given them back), while allowing existing cookies to stay by default; this would mitigate even mild exposures and keep things neater. Even then websites would probably find some way to sneak cookies back in, so you'd want to clean them out periodically.

(I would be happy with a uMatrix option for 'do not accept blocked cookies' (provided that it had no effect on existing cookies); I'd turn it on, but other people might leave it off. I'd probably still keep using Cookie AutoDelete as well, though, just in case.)

Sidebar: Medium demonstrates the problem with uMatrix's approach

Medium has (or had) Javascript that will nag you to sign up with them if you visit more than once or twice and they detect this, and the detection seems to be based on cookies. This is a clear case where uMatrix's 'allow them to be set but stop them from being sent to the website' approach breaks down, because the damage is done when Javascript reads out the cookie and uMatrix isn't blocking that (and probably can't).

If you allow Medium to run Javascript (and sometimes you have to in order to get readable articles), the only solution is either not accepting Medium's cookies or purging them almost immediately.

Written on 09 September 2018.
« My view of the current state of Go's dependency management (as of Go 1.11)
Why I don't think browsers will ever standardize how 'Reader Mode' works »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 9 01:39:26 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.