Wandering Thoughts archives

How switching to uMatrix for JavaScript blocking has improved my web experience

I'm a long-term advocate of not running JavaScript. Over the years I've used a number of Firefox (and also Chrome) addons to do this, starting with a relatively simple one and then upgrading to NoScript. Recently I switched over to uMatrix for various reasons, which has generally been going well. When I switched, I didn't expect my experience of the modern web to really change, but to my surprise uMatrix is slowly enticing me into making it a clearly nicer experience. What's going on is that uMatrix's more fine-grained permissions model turns out to be a better fit for how JavaScript exists on the modern web.

NoScript and other similar addons have a simple global site permissions model; either you block JavaScript from site X or you allow JavaScript from site X. There are two problems with this model on the modern web. The first problem is that in practice a great deal of JavaScript is loaded from a few highly used websites, for example Cloudflare's CDN network. If you permit JavaScript from cdnjs.cloudflare.com to run on any site you visit, you could be loading almost anything on any specific site (really).

The second problem is that there are a number of big companies that extend their tendrils all over the web, while at the same time being places that you might want to visit directly (where they may either work better with their own JavaScript or outright require it). Globally permitting JavaScript from Twitter, Google, and so on on all sites opens me up to a lot of things that make me nervous, so in NoScript I never gave them that permission.

uMatrix's scoped permissions defang both versions of this pervasiveness. I can restrict Twitter's JavaScript to only working when I'm visiting Twitter itself, and I can allow JavaScript from Cloudflare's CDN only on sites where I want the effects it creates and I trust the site not to do abusive things (eg, where it's used as part of formatting math equations). Because I can contain the danger it would otherwise represent, uMatrix has been getting me to selectively enable JavaScript in a slowly growing number of places where it does improve my web browsing experience.

(I could more or less do this before in NoScript as a one-off temporary thing, but generally it wasn't quite worth it and I always had lingering concerns. uMatrix lets me set it once and leave it, and then I get to enjoy it afterward.)

PS: I'm not actually allowing JavaScript on Twitter, at least not on a permanent basis, but there are some other places that are both JavaScript-heavy and a little bit too pervasive for my tastes where I'm considering it, especially Medium.

PPS: There are some setting differences that also turn out to matter, to my surprise. If you use NoScript in a default-block setup and almost always use temporary permissions, I suggest that you tell NoScript to only reload the current tab on permission changes so that the effects of temporarily allowing something are much more contained. If I had realized how much of a difference it makes, especially with NoScript's global permissions, I would have done it years ago.

Sidebar: Cookie handling also benefits from scoped permissions

I hate Youtube's behavior of auto-playing the next video when I've watched one, because generally I'm only on YouTube to watch exactly one video. You can turn this off, but to make it stick you need to accept cookies from YouTube, which will then quietly follow you around the web anywhere someone embeds some YouTube content. uMatrix's scoped permissions let me restrict when YouTube can see those cookies to only when I'm actually on YouTube looking at a video. I can (and do) do similar things with cookies from Google Search.

(I also have Self-Destructing Cookies set to throw out YouTube's cookies every time I close down Firefox, somewhat limiting the damage of any tracking cookies. This means I have to reset the 'no auto-play' cookie every time I restart Firefox, but I only do that infrequently.)

I've now received my first spam email over IPv6

One of the machines that I run my sinkhole SMTP server on has an IPv6 address, one that's currently present in DNS as the target of an MX record (not literally, of course, it's the AAAA record of the host that's the MX target). Back in October, in a somewhat different DNS setup, it saw its first IPv6 probe, and has seen a number since then. A bit over a week ago it got its first actual spam email over IPv6.

The source IPv6 address is in Asia, which doesn't surprise me; my impression is that APNIC is one of the most active areas for IPv6 usage for various reasons (including IPv4 address exhaustion). The sending host appears to also have an IPv4 address, but apparently it prefers to use IPv6 if it can (which is again not surprising). Its IPv4 address is listed in a couple of DNS blocklists, including b.barracudacentral.org, but is not in Spamhaus or the CBL.

(Spamhaus has an old policy statement about IPv6 that gives an example of querying them for IPv6 addresses. Out of curiosity I tried it for this IPv6 address and not unsurprisingly got nothing. I don't know if Spamhaus, or anyone else, is actually serving IPv6 address DNS blocklist information or if everyone has punted so far.)

The actual spam is your standard variety advance fee fraud spam, claiming to be from a completely unrelated email address in cox.net with replies directed to another address at 'net-c.com'. The spam message claims to be from someone with 'Egmont group, USA', which probably explains the choice of cox.net as the From: and sender address.

(The spammer probably means this Egmont group, which is plausible given the rest of the spam message, which is a typical 'we believe you have been scammed, we have some compensation to give you' thing. Since I didn't know about the Egmont group before this, I can't say that spam isn't educational.)

I have some vague thoughts on IPv6 and spam, but I've decided that they're for another entry. I have seen periodic IPv6 connections, but they appear to mostly be TLS scanners.

(My logs say that Google tried to deliver email over IPv6 back in early December, but I refused it because email from GMail to this sinkhole server is far too likely to be boring spam, usually advance fee fraud attempts. Perhaps I should declare that all spam received over IPv6 is interesting enough to capture.)