How to use uBlock Origin to block Javascript by default

September 15, 2018

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 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 and uBlock considers the domain to be '' (which is correct, that's the top level domain in question). If I noop '' to allow our Javascript, what I get in the 'my rules' tab in uBlock Origin's settings is: * 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, 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 so the support.cs rule doesn't apply.

If I wanted to make a general exemption for all sites to run Javascript (or all 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 '' for various rules for cookies.)

Written on 15 September 2018.
« How you migrate ZFS filesystems matters
CPython has a fairly strongly predictable runtime, which can be handy »

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

Last modified: Sat Sep 15 00:03:56 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.