Wandering Thoughts

My unusual use for Firefox's Private Browsing mode

I've written before about how I use my browsing history to keep track of what I've read, although that only partly works in this era of websites making visited links look the same as unvisited ones. However, there is a little problem with using the 'visited' status to keep track of what I've read, and that is that visiting a web page doesn't necessarily correspond with actually reading it. Specifically, sometimes I run across a potentially interesting link but I'm not sure I have the time to read it right now (or if it's actually going to be interesting). If I follow the link to check it out, it's now a visited link that's saved in my browser history, and if I close the window I've lost track of the fact that I haven't actually read the page.

For years I used various hacky workarounds to take quick peeks at pages to see if I wanted to actually read them. Recently it occurred to me that I could use Firefox's Private Browsing mode to conveniently deal with this issue. If I'm reading a page or an aggregator site in my main Firefox instance and I'm not sure about a link, I can use the context menu's 'Open Link in New Private Window' option and there I go; I can check it out without it being marked as 'visited' and thus 'read' in my history. If I decide that I want to read the page for real, I can re-open the link normally.

(Reading the whole thing in Private Browsing mode is somewhat dangerous, because any links that I follow will themselves be in Private Browsing mode and thus my 'I have read these' history status for them will be lost when I close things down. So I usually switch once I've read enough to know that I want to read this for real.)

In retrospect it's a bit amusing that it took me this long to wake up to this use of Private Browsing. Until now I've spent years ignoring the feature on the grounds that I had other browsers that I used for actual private browsing (ones with far less risk of an information leak in either direction). Even though I was carefully doing things to not record certain web page visits in my main browser's history, using Private Browsing for this never occurred to me, perhaps because I wasn't doing this because I wanted private browsing.

(I think I woke up partly as part of walking away from Chrome, which I sometimes used for such quick peeks.)

One of the gesture actions that Foxy Gestures can do is open links in new private browsing windows, although I don't have a gesture assigned to that action. However I'm not sure I use this enough to make coming up with (and memorizing) a new gesture worth it. And on that note, I wish that you could attach meanings to 'middle-clicking' links with modifier keys held down, so I could make a special variant of middle-clicking do 'open in new private browser window' instead of 'open in new regular browser window'.

(Firefox turns out to have a number of behaviors here, but I'm not sure any of them are clearly documented.)

An irritating limitation or two of addons in Firefox Quantum

It's reasonably well known that Firefox addons in Firefox Quantum (ie, WebExtensions addons) are more limited than pre-Quantum addons were. One of these limitations is the places where addons work at all. Some addons are not deeply affected by these limitations, but ones that deeply modify Firefox's UI, such as a gestures addon or an addon that adds a Vim style interface (via) are strongly affected because the limitations restriction where they can be used and thus where the UI works as you expect. In other words, where gestures work for me.

One limitation is explained directly in Foxy Gesture's Github README, so I'll just quote it:

More importantly, the mouse gestures will not work until the document body of the website you are visiting has parsed. In other words, the DOM must be at least partially parsed but content does not have to be loaded. [...] This is an inherent limitation of web extensions at the moment, because there is no API to get mouse events from browser chrome. In practice this is rarely an issue as mouse events are typically available very quickly.

This is almost always true in practice, because Firefox Quantum loads web pages very fast. Well, it loads them very fast when their web site is responding. When their web site isn't really responding, when you're sitting there with a blank page as Firefox tries to load things and you decide that you're going to give up and close the tab, then you run into this issue. I close most tabs through a mouse gesture, or at least I would like to, but when a new tab hangs during the initial page load (or sometimes during subsequent ones), my mouse gesture doesn't work and I have to turn to Ctrl-W on the keyboard or clicking the appropriate tab control.

The other big limitation of addons is that they can't act on pages that Firefox considers sensitive pages, especially including internal chrome pages. Unfortunately it turns out that a number of pages that you wouldn't expect are considered chrome pages, and these are pages that you may use all the time. Specifically, pages in Firefox's Reader mode are all considered chrome pages and off limits to addons, as are all pages that are showing PDFs using Firefox's internal PDF viewer. The Reader mode limitation is especially irritating and makes Reader mode quite a bit less attractive to me; if you're going to break my UI and not always work, I wonder what I'm really getting out of it.

(With both Reader mode and PDFs, there's no indication in the displayed URL itself that you're in some special internal Firefox chrome page context, since they display the normal URL. This is especially striking and irritating in Reader mode, at least to me.)

Two more important cases of chrome pages are Firefox's network errors page (what you get if you leave one of those slow-loading web pages to actually time out) and about:blank, the completely blank page that shows up under some circumstances. For instance, if you open a URL in a new window or tab except that Firefox decides that the URL should be downloaded instead of shown, you're left with an about:blank page.

(A small but irritating additional case is 'view source', which is of course another internal chrome page these days.)

I'm sure that Firefox has good internal reasons for preventing addons from injecting things into these pages, but the resulting UI glitches (where gestures suddenly stop working on some page and I have to remember that oh yeah, it's a PDF or whatever) are reasonably painful. I really wish there was some way to tell Firefox that no, really, I actually do trust Foxy Gestures that much.

(The gestures that I would like to use on all pages include general window functions like 'close tab' and 'iconify'; on PDFs, I would also like things like 'increase/decrease font size'. None of these are specific to HTML content, and the window manipulation ones are basically global.)

My Firefox addons as of Firefox '64' (the current development version)

As I write this, Firefox 62 is the current released version of Firefox and Firefox 63 is the beta version, but my primary Firefox is still a custom hacked version that I build from the development tree, so it most closely corresponds to what will be released as Firefox 64 in a couple of months. At this point I feel that I'm far enough into my Firefox Quantum era that my set of addons has more or less stabilized, especially what I consider my core set, so it's time to write them down (if only for my future reference).

On the whole I've been pleased by how well Firefox Quantum handles addons, and in particular it doesn't seem to have addon memory leaks. As I mentioned in my earlier entry on some addons I was experimenting with, this has made me much more willing to give potentially interesting addons a go. It's also made me much happier with Firefox overall, since I no longer feel like I need to restart it on a regular basis; I'm back to where I can just leave it running and running for as long as my machine is up.

My core addons, things that I consider more or less essential for my experience of Firefox, are:

• Foxy Gestures (Github) is the best gestures extension I've found for Quantum. It's better than the usually recommended Gesturefy for reasons that I covered in my early entry on Quantum addons. Gestures have become a pretty crucial part of my Firefox experience and I really notice the places in Quantum where they don't work, which is more places than I expected. But that's another entry.

  (I use some custom gestures in my Foxy Gestures configuration that go with some custom hacks to my Firefox to add support for things like 'view page in no style' as part of the WebExtensions API.)

• uBlock Origin (Github) is my standard 'block ads and other bad stuff' extension, and also what I use for selectively removing annoying elements of pages (like floating headers and footers).

• uMatrix (Github) is my primary tool for blocking Javascript and cookies. uBlock Origin could handle the Javascript, but not really the cookies as far as I know, and in any case uMatrix gives me finer control over Javascript which I think is a better fit with how the web does Javascript today.

• Cookie AutoDelete (Github) deals with the small issue that uMatrix doesn't actually block cookies, it just doesn't hand them back to websites. This is probably what you want in uMatrix's model of the world (see my entry on this for more details), but I don't want a clutter of cookies lingering around, so I use Cookie AutoDelete to get rid of them under controlled circumstances.

  (However unaesthetic it is, I think that the combination of uMatrix and Cookie AutoDelete is necessary to deal with cookies on the modern web. You need something to patrol around and delete any cookies that people have somehow managed to sneak in.)

• My Google Search URL Fixup for reasons covered in my writeup of creating it.

Additional fairly important addons that would change my experience if they weren't there:

• Textern (Github) gives me the ability to edit textareas in a real editor. I use it all the time when writing comments here on Wandering Thoughts, but not as much as I expected on other places, partly because increasingly people want you to write things with all of the text of a paragraph run together in one line. Textern only works on Unix (or maybe just Linux) and setting it up takes a bit of work because of how it starts an editor (see this entry), but it works pretty smoothly for me.

  (I've changed its key sequence to Ctrl+Alt+E, because the original Ctrl+Shift+E no longer works great on Linux Firefox; see issue #30. Textern itself shifted to Ctrl+Shift+D in recent versions.)

• Open in Browser (Github) allows me to (sometimes) override Firefox's decision to save files so that I see them in the browser instead. I mostly use this for some PDFs and some text files. Sadly its UI isn't as good and smooth as it was in pre-Quantum Firefox.

• Cookie Quick Manager (Github) allows me to inspect, manipulate, save, and reload cookies and sets of cookies. This is kind of handy every so often, especially saving and reloading cookies.

The remaining addons I use I consider useful or nice, but not all that important on the large scale of things. I could lose them without entirely noticing the difference in my Firefox:

• Certainly Something (Github) is my TLS certificate viewer of choice. I occasionally want to know the information it shows me, especially for our own sites.

• Make Medium Readable Again (also, Github) handles a bunch of annoyances for Medium-hosted stuff. Some of these just automate things that I could zap by hand with uBlock Origin and some of these only apply when I turn on Javascript to get things like Medium images and code snippets, but it's handy.

• Link Cleaner cleans the utm_ fragments and so on out of URLs when I follow links. It's okay; I mostly don't notice it and I appreciate the cleaner URLs.

  (It also prevents some degree of information leakage to the target website about where I found their link, but I don't really care about that. I'm still sending Referer headers, after all.)

• HTTPS Everywhere, basically just because. But in a web world where more and more sites are moving to using things like HSTS, I'm not sure HTTPS Everywhere is all that important any more.

I'm no longer using any sort of addon to stop Youtube and other media from autoplaying. These days, that's mostly covered by Firefox's native media autoplay settings, although I have to add a hack to my personal build so that isolated video documents with no audio don't get to autoplay on their own. I'm happy with this shift for various reasons.

Twelve addons is a significant increase on what I've historically used, but everything seems to go okay so far. At the moment I'm not tempted to add any more additional addons, although some people would throw in major ones like Greasemonkey or Stylus. I've used Stylish in the past, but these days uBlock Origin's element zapping covers basically everything I care about there.

(More commentary on these addons and alternatives is in this early entry on Quantum addons and then this entry on more addons that I was experimenting with. All of those then-experimental addons have been promoted to ones that I'm keeping, especially Certainly Something.)

PS: These days I keep copies of the Github or other repos of all of the important addons that I use for various reasons, including as a guard against what could euphemistically be called 'supply chain attacks' on addons.

Walking away from Google Chrome

Despite periodic qualms over Chrome extensions, I've been using Chrome for what is now a long time. However, that's a bit misleading of a statement, because I don't really use Chrome in a conventional way. Basically all of what I do with Chrome is use incognito mode as my 'just make this site work, I don't care' browser, with Javascript and so on all enabled in a way that I don't normally do. For a long time this also had the advantage that for me Chrome was faster than Firefox on Javascript-heavy sites.

In the recently released Chrome 69, Google made a significant change to Chrome's behavior; logging into a Google site automatically logs you into Chrome itself under that identity, leaving you very close to having Chrome sync your local Chrome data to Google whether or not you really want it to. A number of people are very unhappy about this; see, for example, Chrome is a Google Service that happens to include a Browser Engine (via) and Why I’m done with Chrome (via).

In theory, I'm not affected by this behavior. I almost never log into any Google site in the first place and I'm basically always doing so in incognito mode, where this doesn't (currently) apply. In practice, this has pushed me to deciding that this is a bridge too far and I no longer want to use Chrome if I can avoid it, and fortunately I can these days. Modern Firefox Quantum has sped up Javascript significantly, and anyways I have much faster machines now than I used to, and conveniently the last site where I had to use Flash recently finally moved to using HTML5 video. That leaves having Javascript and cookies turned on. In Firefox, the simple approach to get the disabled addons I had in Chrome's incognito mode is to make a new profile with a different set of addons. These days this is a process I'm already quite familiar with, because I already maintain several special purpose Firefox profiles with different sets of addons.

So now I have a new Firefox 'Javascript' profile all set up to allow Javascript and all that but to throw away all cookies on exit, and some new scripts to make invoking it as convenient as my existing ichrome script. My early experience is positive, and in fact the experience is clearly better than Chrome in two respects. First, I don't have my Chrome cut and paste irritation. Second, Firefox will offer to save website passwords for me in this profile; incognito Chrome quite reasonably never saves passwords on its own, so I always had to set them up by logging in once in regular Chrome.

(If I was really determined about this shift, I would change my ichrome script to run Firefox in my Javascript profile instead of incognito Chrome. I'm not quite there yet.)

I'm under no illusions that Google will even notice my departure from the Chrome fold, especially since I use Chrome on Linux (which is already a tiny OS for Chrome usage). But it makes me happier to walk away from Chrome here, and I even seem to be improving my browsing life in various small ways.

(This elaborates on some tweets of mine.)

Sidebar: How I want to set up Firefox to discard cookies and history

When I first set up this Firefox Javascript profile, I picked the obvious option for history of 'Never remember history'. However, this turns out to magically enable Firefox's private browsing mode, which has the side effect of disabling saving logins and passwords for websites. So instead I have it set to 'use custom settings for history', where my custom setting is not to remember downloads or search and form history and to clear history when Firefox closes, ie Firefox should never remember history. Cookies I have set to 'Keep until Firefox is closed'.

(Perhaps Firefox's private browsing would remember passwords if I set a master password, because that option is not greyed out, but in practice I don't do that for reasons beyond the scope of this entry.)

The Extended Validation TLS certificate endgame is here (to my surprise)

Today, Troy Hunt published Extend Validation Certificates are Dead, which runs over the pretty strong evidence for that proposition. I'm genuinely startled by the pace of these developments; I expected the EV certificate endgame to happen sometime, but nowhere near this fast and this definitively. To me, what stands out in Troy Hunt's article is not just that major mobile browsers have aggressively moved away from doing special things for EV certificates, but that large organizations are considering migrating away from them, and for operational reasons instead of cost ones (modest cost savings may not be convincing to decision makers, but security and operational risk probably is).

In my view this matters a great deal; a perception that EV certificates are worse than plain TLS certificates is a quite bad thing for EV certificates. When the choice between EV and plain certificates was neutral except for cost, EV certificates had a chance in cost-insensitive situations and organizations, as such organizations were basically indifferent and so could be talked into it for various reasons. If EV certificates are worse in practice than plain certificates, organizations are not merely not going to take them, they are going to fight hard against attempts to impose them or sneak in requirements for them.

Back in May I wrote up some speculation on the long term future of EV certificates. A good chunk of that seems very unlikely now, in light of these developments. For example, I speculated that the PCI DSS would be talked into mandating EV certificates. If major banks are now considering moving away from EV certificates for operational reasons, that seems highly unlikely since none of the organizations involved will want to be yoked to EV certificates, and they have a lot of influence on the PCI DSS standards. And given that browsers are killing off EV certificate indicators, they're certainly not going to make future Javascript features conditional on having EV certificates instead of regular ones.

Between Let's Encrypt's relentless march to taking a larger and larger share of plain Domain Validated certificates (you have only to look at Troy Hunt's collection of sites that once may have bothered with EV certificates but have since rolled them over to LE) and the death of Extended Validation certificates, I have no idea what commercial Certificate Authorities can do next. Well, I expect they're going to try more 'marketing', but I'm not sure it's going to do them much good (especially in the long run, say in a year or two, when existing EV certificates come up for renewal and people start taking another look at things).

I'm honestly surprised that the CAs seem to have been so ineffective here at preserving EV certificates. I would have expected CAs to be working away full time to influence browser vendors, among other things. Instead all we seem to have gotten is some clumsy marketing campaigns that are probably not being particularly effective.

(Perhaps most CAs have already effectively written off their EV business as not going to survive and so are simply harvesting whatever money they can from it before they quietly shut it down.)

How to use uBlock Origin to block Javascript by default

I normally use uMatrix for my Javascript blocking (and cookies too), with uBlock Origin only handling ad-blocking and zapping page elements away. However, uBlock Origin can be used to block Javascript as well, and today I became interested in understanding how to do this so that I could understand how uBlock and uMatrix differ here (for reasons beyond the scope of this entry (via)). As a result and since I'm familiar with it, I'm going to frame a certain amount of this in terms of how it compares to uMatrix.

Blocking Javascript with uBlock is done through dynamic filtering, which requires turning on the 'I am an advanced user' setting to enable advanced user features, the important part of which is access to the dynamic filtering pane. The dynamic filtering pane provides you with a number of rows of settings and sites or domains (in bold), and two columns that each provide a three-way option of allow, noop, and block. The first of the two columns (on the left) is for the global scope, the equivalent of uMatrix's '*' scope; its settings apply regardless of what site you're visiting. The second column is for the local scope, the site that you're visiting. Although uBlock Origin will show the domain of the site (based on the Mozilla Public Suffix list), the local scope rules are actually recorded for the specific site.

(You can see and control specific sites, not just their domains, by clicking on the little '+ all' row at the top the dynamic filtering pane.)

To block Javascript by default, we need to set all of inline scripts, 1st-party scripts, and 3rd-party scripts to red (actively blocked) in the global scope. This does what it says on the can; all Javascript is blocked everywhere, both first-party Javascript (JS from the site you're visiting) and third-party Javascript (JS from other sites, which can be anything from Facebook bugs to MathJax or embedded Github code rendering).

If you want to enable Javascript generally while you're visiting a particular site, you make the local scope column settings for all of inline scripts, 1st-party scripts, and 3-party scripts be noop (dark grey). This completely overrides your global scope deny rules. The uMatrix equivalent is turning the 'script' column of the 'all' row to active green, which enables Javascript for all sites down the column. If you want to enable Javascript just from the site when you're visiting it but not load third party Javascript from elsewhere, there are two options; you can noop the site itself in the local scope column, or you can noop just inline scripts and 1st-party scripts while leaving 3rd-party scripts blocked.

If you want to enable Javascript from a particular site no matter what site you're visiting (Youtube, for example), you turn it noop in the global column. You don't want to turn it actively allowed (green), because then that would stop any ad-filtering uBlock is doing for you against the site. However, depending on various factors, just enabling a third party site may not actually activate its Javascript on any particular site you're visiting, because its Javascript may need to be loaded by some other Javascript from another site, which you still have blocked.

(For example, enabling the MathJax Javascript used in this Mark Dominus article requires noop'ing both mathjax.org and Cloudflare to enable their Javascript, because the MathJax code is loaded through Cloudflare.)

To enable Javascript from a domain just while you're on a particular site, you noop their local scope instead of their global scope. For example, if you need to enable Javascript from Cloudflare to get MathJax math to render properly somewhere, you probably don't want to enable Cloudflare Javascript globally; Cloudflare hosts a lot of Javascript that people use for a lot of purposes (as I've noticed before). So you noop Cloudflare only in the local scope of Mark Dominus's blog, because you have a reasonable amount of trust there.

Nooping Cloudflare in the local scope is safe in that you're only unblocking Javascript loaded from it, not anything else (ie, not ad-blocking filters), because Javascript is the only thing we've blocked with dynamic rules. If you had blocked more, for example you'd also blocked 3rd-party (i)frames, there's no way to unblock just Javascript just for Cloudflare. You could unblock Cloudflare for both Javascript and (i)frames, or you could unblock 3rd-party Javascript completely, but that's it.

(In uMatrix terms, you essentially only get the rows and the columns, you don't get the cells at their intersection. With uMatrix you can be completely specific by picking the cell too, and usually that's what I do.)

One little drawback of the uBlock interface on the dynamic filtering pane is that you can't necessarily tell just what is being blocked from a specific domain and thus who you need to noop in order to get Javascript to work. You can see that some things have been blocked (or that a domain has been totally blocked), but that might have come from either your Javascript blocks or from ad-blocking filtering rules (or both). I guess that when in doubt, you just locally noop sites until things work (or go all the way to noop'ing all Javascript in the local scope). However, if you want to go to the effort, you can call up uBlock Origin's logger, refresh the page, and see what gets blocked. This should tell you specifically what Javascript is getting blocked and where from. Conveniently, blocks stand out by being in pale red and you can filter on 'script' to ignore other blocks from things like ad-blocking filter rules.

Generally, completely nooping your global scope rules in the local scope is the big 'just make it work, I don't care any more' hammer. You might allow and run more Javascript than you want, but whatever. You can let your cookie cleaner delete any tracking stuff that you got stuck with (I like Cookie AutoDelete).

Unless you're specifically overriding an ad-blocking filtering rule, the presence of any green in the dynamic filtering pane is a danger sign that you probably clicked the wrong section of a column. For blocking and then selectively unblocking Javascript (or anything), you should see only red (blocks) and dark grey (noops that cancel the blocks).

Overall I'm impressed. Once I looked, it turns out that uBlock Origin does a much better, more usable job of blocking Javascript than I was expecting; it required some decoding and some experimentation, but to be honest so did uMatrix when I started with it. I could actually imagine using uBlock Origin as my Javascript blocker and in some ways it'd be easier and more user friendly than working with uMatrix (although I'm going to stick with uMatrix for various reasons, including that it blocks cookies too).

(I also understand uBlock Origin's dynamic filtering a lot more than I used to, which was one of the points of digging into it for this entry.)

Sidebar: Sorting out what the local scope applies to

Our support site is support.cs.toronto.edu and uBlock considers the domain to be 'toronto.edu' (which is correct, that's the top level domain in question). If I noop 'toronto.edu' to allow our Javascript, what I get in the 'my rules' tab in uBlock Origin's settings is:

support.cs.toronto.edu toronto.edu * noop

In uBlock Origin's rule language, the first word is what this site this applies on (the 'source'), the second is what it applies to (the 'destination'), the third is a type selector ('*' is the wildcard), and the fourth is the operation. So while we're on our support site, toronto.edu as a whole is noop'ed, allowing Javascript. If I go to fill out our account request form, which also has Javascript, that JS is blocked because now I'm on a different site under toronto.edu so the support.cs rule doesn't apply.

If I wanted to make a general exemption for all toronto.edu sites to run Javascript (or all cs.toronto.edu sites), I would have to do it by editing things by hand in the 'my rules' tab of Settings. I don't think there's any way to do this through the dynamic filtering pane.

(In uMatrix you can specifically control the scope that you're working in, so you can set a scope anywhere from this site itself up through the global scope. This does let you set scopes that are likely to be silly, like 'com' or 'edu', but if you're using uMatrix, that's on you. It can be convenient, for example to set a scope of 'google.com' for various rules for cookies.)

Why I don't think browsers will ever standardize how 'Reader Mode' works

I recently read Daniel Aleksandersen's four part series on 'reading mode' in (most) browsers (parts 1, 2, 3, and 4, discovered via my referer logs). In the final summary part, "Web Reading Mode: A bad reading experience", Aleksandersen suggests that there should be standardization of how browsers parse pages to determine what is the 'main page' contents they will show. I'm not a fan of the current state of affairs (I've written about the limitations of Firefox's Reader mode), but I think that browsers will never standardize how this works, and may never fully document it. This isn't because browser people are evil; it's because locking down how reader mode works through a standard would very likely result in reader mode being subverted by web site publishers.

The ultimate purpose of reader mode is to remove things from the website, and it is most needed on exactly those websites that put the most extraneous things in. However, these websites are not putting those extraneous things into the page randomly or because they are idiots; instead, those things serve the interests of the website in various ways (this is most obvious with inserted advertising). Since websites want these elements to be present in the pages that people see, they have a decent motivation to trick and subvert browser reader modes so that this content is still included (in as original a form as possible), especially if it is easy.

In short, if you provide websites with a mechanism to say 'include this in reader mode', they will use it on things that should not be included in reader mode. Standardizing how reader mode determines what is and isn't main content is one way to provide websites with such a mechanism.

Now, this mechanism already sort of exists, in that you can reverse engineer how the various reader modes determine this and what they include, but at least two things slow down websites here; there's more than one implementation to target and implementations are free to change their approach and invalidate your work to date. As a result, right now, it's generally not worth people's while to do all of this work given the low likely payoff. Standardization would likely reduce the amount of work you need to do substantially, so I'd expect to see quite a few websites throw in the necessary tags.

Browsers standardizing reader mode is somewhat like mail systems standardizing what is considered non-spam, and I think it's about as unlikely for this reason alone (never mind any other ones, such as whether browsers consider this either a priority or a competitive advantage). This is a pity, but unfortunately the modern web is a hostile environment (at least in the large).

Cookie management models in Firefox Quantum in practice

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:
[...]

• Cookie Monster: cookie-autodelete or uMatrix are possible alternatives

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.

I've slowly been improving my web experience by trusting uMatrix more

I have a long history of not running Javascript, which comes in large part from me very much not trusting sites that wanted to run Javascript; I started on the web in an era where Javascript was mostly abused, and that has stuck with me ever since. For most of that history the only way I had to deal with Javascript was a total block, first globally and then on a site by site basis (with NoScript). This has left me with a well honed and deep seated reflex of saying 'ha ha no' to sites that wanted to run Javascript, at least in my main Firefox browser. Basically I drifted into a mindset of declaring that it wasn't absolutely essential to enable Javascript, so I wasn't going to.

Then I switched to uMatrix for Javascript blocking, and discovered that uMatrix is a better fit for Javascript on the modern web. The big thing that uMatrix has is that it allows me to be extremely selective by only enabling 'first party' Javascript for a site, or to put it another way I can enable that site's Javascript only when I'm actively visiting it. I knew all about this back in February, but I didn't really do anything with that knowledge; I enabled first party JS for a few sites, and left it at that. After all, things had been working okay before uMatrix and I'm a creature of inertia.

(Keeping Javascript off is more than just privacy and so on; for a long time, allowing Javascript to run has been a great way to bloat up your browser's memory usage and slow it down. I don't want to let sites do that to my browser, because I want to leave my main browser session running for weeks.)

Sometimes being a creature of inertia is kind of the wrong choice. What I've slowly come to realize and convince myself of over the past while is that I don't have to be so reflexively stringent about (still) blocking this first party Javascript. Much like my slowly growing willingness to use uBlock Origin's capabilities to improve my life (1, 2), I've slowly accepted that enabling Javascript on various sites is both harmless and a genuine improvement to my life. I'm still quite selective and limited (far more so than most people would be), but I'm slowly adding more and more sites that have various bits of Javascript enabled.

It remains not entirely easy to persuade myself to enable Javascript for a site; there's still a little voice that asks me 'do you really need this? are you sure it's going to be okay?'. But I'm getting better at it, at moving past my old habits and reflexes to take advantage of uMatrix's power and possibilities to make my life nicer. I admit that part of this is simply remembering that oh yeah, I can actually do that these days; I can selectively turn on Javascript for, say, Go's code review site, and it's not a big deal any more.

(I have an entire separate browser environment for Javascript-heavy websites and it's not too hard to switch to viewing a site in that environment. But it is some extra steps, so having things working in my main browser is nicer.)

There is still a part of me that's grumpy when people's blogs or text websites partly don't work without Javascript for no particularly good reason, or at least no particularly visible one. I still partly resent needing to use Javascript to read content, and part of the reason I don't enable Javascript more broadly is a bit of stubbornness (I tell myself that I don't want to encourage people to use Javascript by having it work in my browser, but I'm aware that that's tilting at windmills at this point).

PS: Medium-based sites are not among the ones that get permanent Javascript permissions. I don't really trust Medium's Javascript much, although I tolerate it some of the time because limited Javascript in my main browser is better overall than unlimited Javascript in the 'just make it work' browser.

(This entry is partly a nudge to myself to remember that this is a perfectly viable possibility now. It works, it's easy, it doesn't seem to blow up my browser, and so on.)

Some Firefox addons I'm experimenting with (as of Firefox 62 or so)

One of the interesting things that's happened as a consequence of my switch to Firefox Quantum (ie 57+) is that I've become much more willing to experiment with addons. My pre-Quantum Firefox setup seemed prone to memory leaks due to addons, which made me fairly nervous about adding more; resigned to leaks or not, I didn't really enjoy the experience. My Firefox Quantum setup seems to be clearly better on all aspects of this (both initial memory usage and growth over time), and this has made me more willing to try addons.

Technically I'm getting most of my exposure to these addons through the latest Firefox master tree ('mozilla-central'), which I compile from source every week or so. But I don't think they do anything different in Firefox 61 or 62, and I have set up some of them there.

Make Medium Readable Again (also, via) is basically what it says on the tin. I'm not affected by as much of the Medium plague as most because I disable most JavaScript and cookies through uMatrix, and I tried dealing with the remaining annoyances by blocking and re-blocking various HTML elements to try to eliminate their top bar and bottom bar, but eventually I got tired of it all. MMRA is a big hammer but it appears to be a reliable one so far, and it works across all of the very many sites and blogs and so on that use Medium, and it has some useful additional effects during the times when I have to turn on JavaScript in order to see important pictures or embedded Github gists of code or the like.

(Medium really is a plague and there is going to be a lot of carnage whenever it winds up shutting down, which I expect it to do within five or ten years at most. A lot of writing is going to disappear from the Internet and that bums me out.)

Certainly Something was pointed out to me on Twitter by @AleXgTorres. It's a quite thorough HTTPS connection information and certificate viewer. I don't use it very often but I care enough about TLS certificate stuff to keep it around in case (I have a history of having some such addon lying around), and it's not particularly obtrusive when I'm not using it. I could pick nits with the interface, but it's not that important in something that I only look at infrequently and CS's presentation of the certificate is traditional.

Finally I've recently added Link Cleaner (via the Mozilla blog entry) because I have to admit that I'm more than a bit tired of all of those utm_ fragments and other things. I sort of wish that it worked like my Google URL fixer addon and fixed the links in place, so that copying a link into some other program also gave me the de-utm'd version, but that's a minor thing. If I cared enough, well, LC's code is GPL3 and I could easily drop it into a version of my addon.

(The LC addon page is clear about how it works and there are probably benefits to cleaning the URL when it's actually used. Ultimately I don't care enough to go out of my way to deal with this; I barely care enough to use the addon when Mozilla basically shoved it under my nose.)

I've considered using 'Stylish' again (these days I'd use Stylus, since the actual 'Stylish' browser extension went bad), but I just don't seem to have much of a desire for re-styling websites these days. Most of what I want to do today is make annoying bits of websites go away entirely, and that's part of what I use uBlock Origin for. Possibly I could use some clever style override to deal with the header and footer plague, but my current answer is often to close the window instead.