Addon Conflicts and Data Leaks

Apr. 16, 2023 [privacy-security] [libre] [technology]

A half dozen or so extensions sit happily running along in your browser dutifuly, according to the various “privacy” sites that recommended them, foilng trackers. Surely, gathering these tools is just like collecting Poke’mon, right? If the knowledgeable folks pushing them have taken the time to scrutinize their operation, they just might have posted fair warnings to their individual caveats. Often, extentions end up stepping on eachother’s feet.

One such case can be found in running CSS Exfil Protection behind a generalized blocker. This addon preemptively parses stylesheets to check them against known form data exfiltration attacks outlined in the developer’s blog. The problem that arises from this is that cross-origin stylesheets will be fetched regardless of whether or not that third party domain is blocked in something like uBlock Origin or uMatrix. They show up as behind-the-scenes xhr requests in the logger:

01:16:57        behind-the-scene                xhr|Arimo:400,400i,700

So anybody who runs default deny policy from some blocker will have their efforts foiled by CSS Exfil Protection failing to respect the setting and making connections to all kinds of trackers anyway. And it doesn’t help that the priority order for addons to modify requests remains unclear and difficult to influence. The commonly cited workaround being to make sure that the addon you want as “master” be the most recent chronologically installed addon. Which flies in the face of common sense, as addons which users feel are the most important will likely be the first to get installed. Just more unquestionable design wisdom from our friends at Mozilla.

That is just an example of a smaller, relatively unknonwn addon causing problems. But conflicts also arise in much bigger and more widely used combinations. It is still very common that uMatrix users like to also run uBlock origin secondarily in basic user mode, citing its beneficial extensive blocklists and pattern filtering. But let’s look at how nicely they play together when visiting a few sites.

You’ll notice that both uBlock Origin and uMatrix are blocking the,, and domains:

Crucially, note that uBlock Origin is permitting the and domains and permitting some resources from the domain. And viewing the uMatrix logger indicates that these resources are being rejected.

But let’s see what our trusty tcpdump has to say:

23:17:02.250877 IP localhost.34253 > redacted.domain: 2047+ A? (33)
23:17:02.406477 IP localhost.47270 > redacted.domain: 34547+ A? (35)
23:17:02.522724 IP localhost.42132 > redacted.domain: 26001+ A? (37)
23:17:03.447299 IP redacted.domain > localhost.34253: 2047 1/0/0 A (49)
23:17:03.794829 IP redacted.domain > localhost.47270: 34547 1/0/0 A (51)
23:17:04.057974 IP redacted.domain > localhost.42132: 26001 1/0/0 A (53)

Interesting. So DNS queries are made for those “blocked” domains.

To the best of my knowledge, this is probably related to the fact that uBlock Origin unhides domain CNAME aliasing, which necessitates doing a lookup. So I ran the same capture after clearing the container cache and disabled uBlock Origin’s Uncloak canonical names feature. This time the only lookups were for the anticipated domain.

23:17:57.561083 IP localhost.51548 > redacted.domain: 10194+ A? (29)
23:17:57.561109 IP redacted.domain > localhost.51548: 10194 1/0/0 A (45)

(Kinda hard to show what didn’t appear. Work with me, here.) One important factor is that our DNS resolver gets to see these lookups as well as the correlating fact that they all arrive at the same time. But do those leaky domain resolutions ever lead to traffic to any of those domains?

Well, it seems not to but is difficult to evaluate (probably due to which addon gets to intercept the request first, I still need to do some investigation on this ). The expected behavior from this addon combination would be to not even bother with the lookups since those domains are blocked by default anyway. The result is that it generates more network traffic than is necessary.

uMatrix users that want to avoid this could opt to disable Uncloak canonical names. Or if you only use uBlock Origin for the blocklists, consider importing compatible lists into uMatrix’s hosts files and dropping uBlock. It also has to be considered whether the cost of fattening out your DNS lookups even outweighs the benefit derived from discovering and mitigating sites who sneakily delegate subdomains to third parties (which uMatrix has absolutely no defense against). Not to mention uMatrix and uBlock Origin have had a history of clobbering eachother over CSP headers. TL;DR: the whole village is on fire.

All of this has me thinking we might be stepping into a world in which external tools outside the browser are going to be required to hold its hand like a little toddler, scolding it “No, DerpFox, don’t touch that resource!” whenever its grubby hands reach out for yet another connection while you weren’t looking.