My Firefox addons as of Firefox 86 (and the current development version)
I was recently reminded that my most recent entry on what Firefox addons I use is now a bit over a year old. Firefox has had 14 releases since then and it feels the start of January 2020 was an entirely different age, but my Firefox addons have barely changed in the year and a bit since that entry. Since they have updated a very small amount, I'll repeat the whole list just so I have it in one spot for the next time around.
My core addons, things that I consider more or less essential for my experience of Firefox, are:
- Foxy Gestures
probably still the best gestures extension for me for modern
versions of Firefox (but I can't say for sure, because I no
longer investigate alternatives).
(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
(Github) is my primary tool
cookies as far as I know, and in any case uMatrix gives me finer
- Cookie AutoDelete
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.)
Additional fairly important addons that would change my experience if they weren't there:
(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.)
- 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:
- 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.
(I think my use of Open in Browser is fading away. Most PDFs and other things naturally open in the browser these days, perhaps because web sites have gotten grumpy feedback over forcing you to download them.)
- 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. The
current Firefox certificate information display is almost as good as
Certainly Something, but it's much less convenient to get to.
- HTTP/2 Indicator
(Github) does what
it says; it provides a little indicator as to whether HTTP/2 was
active for the top-level page.
(GitLab) is my
current replacement for Link Cleaner
after the latter stopped being updated. It cleans various
tracking elements from URLs, like those 'utm_*' query
parameters that you see in various places. These things are
a plague on the web so I'm glad to do
my little bit to get rid of them.
- 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.
As I've done for a long time now, I actually use the latest beta versions of uBlock Origin and uMatrix. I didn't have any specific reason for switching to them way back when; I think I wanted to give back a bit by theoretically testing beta versions. In practice I've never noticed any problems or issues.
(There are somewhat scary directions in the Decentraleyes wiki on making it work with uMatrix. I opted to skip them entirely.)
My pragmatic sysadmin view on subdomains and DNS zones
Over on Twitter, Julia Evans had an interesting poll and comment:
computer language poll: is mail.google.com a subdomain of google.com? (not a trick question, no wrong answers, please don't argue about it in the replies, I'm just curious what different people think the word "subdomain" means :) )
the ambiguity here is that mail.google.com doesn't have its own NS/SOA record. An example of a subdomain that does have those things is alpha.canada.ca -- it has a different authoritative DNS server than canada.ca does.
This question is interesting to me because I had a completely different view of it than Julia Evans did. For me, NS and SOA DNS records are secondary things when thinking about subdomains, down at the level of the mechanical plumbing that you sometimes need. This may surprise people, so let me provide a quite vivid local example of why I say that.
Our network layout has a bunch of
internal subnets using RFC 1918 private IP address space, probably like a lot of
other places. We call these 'sandbox' networks, and generally each
research group has one, plus there are various other ones for our
internal use. All of these sandboxes have host names under an
.sandbox (yes, I know, this is not safe
given the explosion in new TLDs). Each different sandbox has a
.sandbox and then its machines go in that subdomain,
so we have machines with names like
However, none of these subdomains are DNS zones, with their own SOA and
NS records. Instead we bundle all of the sandboxes together into one
sandbox. zone that has everything. One of the reasons for
this is that we do all of the DNS for all of these sandbox subdomains,
so all of those hypothetical NS and SOA records would just point to
ourselves (and possibly add pointless extra DNS queries to uncached
I think most system administrators would consider these sandbox subdomains to be real subdomains. They are different namespaces (including for DNS search domains), they're operated by different groups with different naming policies, we update them separately (each sandbox has its own DNS file), and so on. But at the mechanical level of DNS zones, they're not separate zones.
But this still leaves a question about mail.google.com: is it a subdomain or a host? For people outside of Google, this is where things get subjective. A (DNS) name like 'www.google.com' definitely feels like a host, partly because in practice it's unlikely that people would ever have a <something>.www.google.com. But mail.google.com could quite plausibly someday have names under it as <what>.mail.google.com, even if it doesn't today. So to me it feels more like a subdomain even if it's only being used as a host today.
(People inside Google probably have a much clearer view of what mail.google.com is, conceptually. Although even those views can drift over time. And something can be both a host and a subdomain at once.)
Because what I consider a subdomain depends on how I think about it, we have some even odder cases where we have (DNS) name components that I don't think of as subdomains, just as part of the names of a group of hosts. One example is our IPMIs for machines, which we typically call names like '<host>.ipmi.core.sandbox' (for the IPMI of <host>). In the DNS files, this is listed as '<host>.ipmi' in the core.sandbox file, and I don't think of 'ipmi.core.sandbox' as a subdomain. The DNS name could as well be '<host>-ipmi' or 'ipmi-<host>', but I happen to think that '<host>.ipmi' looks nicer.
(What is now our IPMI network is an interesting case of historical evolution, but that's a story for another entry.)