Hacker News Reader

Comment by FiloSottile | Hacker News Reader

This is the uBlock Origin edition based on the much-maligned WebExtensions Manifest V3, which implements blocking declaratively instead of allowing/requiring live request interception.

Firefox—my daily driver—still supports the "main" uBlock Origin (and I'm a somewhat heavy user of features unavailable in Lite like custom filters), but I had been waiting for Lite to be available and immediately went ahead and replaced uBlock Origin with uBlock Origin Lite.

The security win can't be understated: with its permission-less design (enabled by MV3) I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions. Sure, attackers could still get into Mozilla, Apple (as I run macOS), or cause a backdoored update to be pushed via Homebrew (how I install unsandboxed applications when no web app is available, which thanks to the likes of WebUSB is getting less common), but unsandboxed browser extensions were clearly the lowest hanging fruit, so this update (and MV3) significantly raised my security posture (and transitively that of projects I have access to, and that of their users).

View on HN

>I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions.

It's my understanding that because uBlock Origin is a "recommended extension", it must undergo a formal code review each time a new update is published. A malicious update would not face zero obstacles.

https://support.mozilla.org/en-US/kb/recommended-extensions-...

The switch from full acces to white-listing for full blocking is just awesome imo.

You can just decide for each case the tradeoff between advanced blocking and security.

I'm unsure of how it exactly differs and whether there are features missing. I will admit that if I were to install uBOL today, I would be worried that it would be less capable and my browsing experience less-safe.

There are many features missing, more prone to anti-adblock/ads-reinsertion (problems with `redirect-rule` and unable to fast updates) and ads/trackers/popups can slip through if cannot be caught by regex filters.

also:

- one thing that is much less powerful is cosmetic filters, which means ads may be replaced with gray squares if uBOL can't remove them entirely

- less filters overall, because the limits on how many filters are possible are pretty strict

- extension updates will be both larger and much more frequent because filter lists can no longer be updated separately from the extension

Why is there a filter limit at all? Why did Firefox add that? Can config change it?

Filters aren't free

They are quite often better than free, blocking unwanted content that would consume more memory and CPU time than the filter itself.

Filters take a minuscule amount of resources. E.g. Even if you had to loop over a list with thousands of entries this would be unlikely to matter, and can in fact even be optimized quite significantly with various algorithms. However, because a database is most likely used, this is not even an issue, and the resource use will in fact be truly minimal.

I can not give you an exact number, but it is massively bigger than the number of trackers / elements that any usable web page can realistically implement. Probably you can do several thousands database calls in less than a second due to indexing; and that can be further optimized by doing it in batches, bringing it up to tens of thousands, if not in the hundreds on modern PCs. It is literally not an issue.

Is the limit still around 30,000 or is it higher? That could be 600,000 filter checks on a page load with 20 requests.

I'm sure it's fast but if people want unlimited number of rules that number could start exploding.

> Why did Firefox add that?

They didn't, Google did. It is part of MV3 specs, afaik.

But Firefox still didn't have to implement the limit.

Then don't use the downgraded version of the ad blocker? What is the point of having two versions of MV3 when you can use a superior adblocker on Firefox anyway?

Google doesn't make Firefox. I flatly don't understand why Mozilla has that limit.

Hmm, it looks like the uBO "Enter element picker mode" feature is not available. I've found that pretty useful occasionally in the past on websites where uBO doesn't catch an ad.

That tradeoff is already possible with the normal uBlock Origin; it just has a different (preferable IMO) default.

The only apparent upside to this version is if you don't trust Raymond Hill to refrain from spying on your browsing sessions via his add-on. By every other metric this seems like a downgrade.

If you use a non-declarative adblocker, you're not just trusting the developer, but also all the third-party filter lists you've subscribed to. These filters have powerful capabilities and can even exfiltrate website data [1], and they are updated in real time, so if a bad actor pushed a malicious update (e.g. by gaining access to any EasyList contributor account), you would most likely be affected.

However, it's true some websites (like YouTube) are especially problematic and a declarative adblocker is not enough. What you can do is combine both approaches: use a declarative adblocker (uBlock Origin Lite) as a baseline, and selectively enable non-declarative adblockers (uBlock Origin) for specific websites (see [2] for a detailed overview).

I like this layered approach because it gets you the best of both worlds: the security and performance of a declarative adblocker, and the functionality of a non-declarative adblocker when you need it, without compromising your entire browsing session.

[1] https://portswigger.net/research/ublock-i-exfiltrate-exploit...

[2] https://seirdy.one/posts/2022/06/04/layered-content-blocking...

Why do you think so?

Say I open HN on my morning coffee and open 5 links in new tabs. They don't have to be to sites I've opened before. I will be tracked until i go to each tab and add it to uBlock Origin.

How is that an improvement?

It truly does seem like a misinformed take on security, believing that being actively tracked is better than the possibility of being tracked if uBlock Origin were ever to be compromised.

Those evil hackers always compromise open source code first, never the ads that no one is reviewing!

Actually every extension on AMO must go through manual inspection to push as auto update. You may push new version to market without manual inspection. But it won't auto update to users' computers until then.

So human review really isn't the real difference on firefox's side. Because it is required since day one

Do you have a source for this? I always thought they long ago stopped manual inspections for most extensions.

I literally wrote one. And it had been taken down due to reviewer unable to reproduce the achieve I uploaded (it turns out to be a \r\n \n line ending issue. Thanks windows and git).

Ok, when adding a new extension to the store. But “recommended extensions” get manually reviewed whenever they update.

I maintain one as well, and had it approved despite the source having a bug, so that doesn’t sound like much of a source.

I don't think they ever care about whether your extension has bug or not. They probably only review whether your extension has weird minified code or dependencies.

It was a bug that prevented building it. If they just look at the source code without building it, they’ll have no idea if it’s the same code at all, and it would be useless.

That's weird. Probably it depends on reviewer? Or probably the reviewer figured out how to compile your source some way? In my experience, the reproducible requirement is always forced.

See my other comment [0], manual reviews have been optional for a long time. There was quite the outcry when they stopped reviewing everything.

[0]: https://news.ycombinator.com/item?id=37218820

> When a developer submits an extension to addons.mozilla.org, it’s scanned for a set of common issues. It may also be subject to human review.

-- https://support.mozilla.org/en-US/kb/tips-assessing-safety-e...

*May* is important here. That is also what I remembered changing years ago.

I'm pretty sure that once you factor in the security reduction from ad blocking being less effective, switching from uBO to uBOL is actually a net worsening of security posture.

If you're getting targeted with major browser zero-days, ads are the least of your concern.

Why do you assume you need to be targetted to be a victim of being pwned by ads?

Because exploits that can break out via ads are not usually worth burning on randos?

Targeted ads let you make sure they don’t get deployed on randos.

Then you should be running more powerful tools like noscript and the full version of this, not a pared down version. Or a significantly more locked down version of Firefox on qubesOS.

Manifestv3 will have negligible improvements on potential security risks and will significantly decrease overall security.

In what way does ad blocking improve your security? It significantly improves your user experience and slightly improves privacy, but it doesn't have anything to do with security, unless you click on random "download" links, which I assume people on HN don't do

Ads can be a malware delivery vehicle.

You assume that modern day browsers are even remotely secure. They still suffer from significant security bugs every now and then. Reducing the amount of third party java script you run is a security improvement.

Fewer requests = fewer potential attack vectors, especially when most of the blocked requests are executable JS code.

Exfiltration of data is a security issue and ads tend to grab any info they can, even if it just loading their ressources. Not a security issue many large tech companies like to focus on for obvious reasons.

You’d be shocked at how many people (smart people included) are fooled by stupid ads and misleading website alerts and notifications. I used to do customer support for a large tech company, and people get sucked into giving up passwords or PII All. The. Time. by convincing ads. Some of these actors even deliberately style the ads to look like system alerts!

Yah, probably not a lot of HN users falling for it, but I was constantly surprised by the demographic. I’d regularly see smart, accomplished people get bamboozled by ads. It’s wild.

You could just disable automatic updates on extensions. uBlock origin is a featured extension, so it's already audited.

MV3 is safer, but so is running no adblocker at all. There is a tradeoff. I get much more ads on Safari+AdGuard (iPhone) which uses MV3 or some similar declarative approach, than on Firefox+uBlock-Origin where I get basically none.

I still prefer to trust one extension like uBlock Origin, just like I trust other software packages on my system, and to really fend off all the web tracking nonsense.

It seems like this issue could also be sidestepped by simply not silently pulling updates, especially in the case of something like browser extensions where the extension is sandboxed (so the potential negative impact of not immediately getting out a "critical security update" is bounded) but the developer is not fully trusted. Have we normalised micromanagement of the user by software vendors so far that this is no longer a default that anyone would consider?

> not silently pulling updates

a regular user would not have the capability to audit an update. A power user, with entirely too much time on their hands, could of course, but one should not be designing systems based on such niche scenarios.

The scenario is: don't enable automatic updates. How long will a compromise exist before someone notices? Often, not very long at all. It's entirely common to avoid an issue because you haven't bothered to update. It's also part of why corpos have their own repository mirrors too since dev supply chain attacks have gotten more common and no one's going to audit their dozens/hundreds of NPM dependencies every update.

A regular user would also not not care about "web sessions", "permissions", "silent updates", and all the other techno-mumbo-jumbo they will file away in their folder of Do Not Care.

Essentially, there's an issue of hypocrisy in the threat model and type of user proposed.

But one should be designing systems, unlike today where there is bad design of forced autoupdates For example, they could be a system of distributed code reviews where an update is offered to the users only after some review

You don't need to audit the update, simply don't update until there's some actual benefit to it.

The counter move is announcing some "security fixes" (of course without any further detail) in each and every update. Now you do not know if you are increasing security by applying the update or if you are decreasing it...

"Security fixes" just means the developer wanted to list what actually changed (which would be "added more telemetry, fixed analytics client ID persistence, made sidebar blue match logo" or something) but the PM insists on using the same generic message each time. Safe to ignore those updates!

I don't get out of bed for anything without a CVE so I can confirm I actually have a threat from the vulnerability, often times they're things where you'd need to use an obscure feature or local privilege escalations on single user systems, etc.

If they never publish any details of security issues (and certainly no CVE score), can you safely assume that you would never receive a genuinely important security fix? How would it feel later on, when your system was compromised and support is pointing to the update with the security fixes?

Yes, maybe that is some weird kind of fear of missing out (on security), but I have a hard time ignoring security fixes, even without details.

For me this security scenario isn't relevant at all. It reminds me of the dysfunctional situation on mobile OS. Sure, theoretically a plugin could get compromised and an update would be malicious. That is true for any software I run on my machine.

But it also comes with costs. The browser is less customizable and further locked down. That reduces possibilities without netting advantages for me. Overall this is security FUD in my opinion. And the negatives can be observed in mobile OS.

Right, I would rather have a slightly less "secure" computer that I control than a super secure walled garden client.

> I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions

Yeah, but is this really a risk for anyone who isn't the sort to have installed Bonzi Buddy back in the day?

That attack surface, compared to that of brew, npm, pip, gem, etc., is miniscule. And browser plugins don't yank in obscure dependencies at install time.

I only run uBlock, and I suspect I'm in the majority here, and my choice of browser is predicated on the availability of a non-crippled ad blocker, because malicious ads are the primary threat.

> I only run uBlock,

(as noted by fsckboy): uBlock was the original name for the add-on that subsequently was ethically compromised/"sold out to" advertisers

uBlock Origin is the 2nd version written by the original author (gorhill) and is not compromised.

The issue with v3 is when it's the only solution. Which is not the case here :

> However, uBOL allows you to explicitly grant extended permissions on specific sites of your choice so that it can better filter on those sites using cosmetic filtering and scriptlet injections.

Which I would expect allow it to work as well as uBO.

> Which I would expect allow it to work as well as uBO.

Note that there are still some adblocker workarounds that will foil MV3, such as CNAMEs. uBO will always be more effective than MV3, unless some substantial improvements are made to MV3.

Note that CNAMEs is literally caused by GDPR, and the pathway every single ad or tracking company seems to go sooner or later.

For people not understanding how it works: you can set a CNAME entry on your tracker.domain.tld to bypass all Browser's third-party tracking preventions, and make it look like it's a normal subdomain of your website.

You need to make a CNAME tracker database manually by resolving the reverse entries for known IPs. Usually there is hundreds or thousands of CNAME entries pointing to the same IP address.

The AdGuard team also made a database for this, in case anyone needs it for UBOL [1]

Most, if not all of those trackers use assets that they serve from there (like a tracking pixel gif socket), so I highly doubt that uBOL will catch those; because the cat and mouse game is now in the ad tracker's favor and it is impossible to keep up now. And that was the intended purpose. We now have to play our hand with marked cards.

[1] https://github.com/AdguardTeam/cname-trackers

> Note that CNAMEs is literally caused by GDPR

How so?

> How so?

Because it shifts the contractual obligations and the "legitimate interest" of data to a seemingly first party, which all companies seem to think they can get away with.

Well, until the tracked subjects do a reverse DNS lookup anyways.

Adding a CNAME does not make tracking first-party. You can simply report them to the relevant DPO.

no it doesn't CNAME is just an alias nothing more and even if it would make it first party it still wouldn't make it legal, like at all

you are allowed to track some information first party for certain purposes without user agreement (e.g. fingerprinting for DDOS protection) but you are ONLY allowed to use it for that purpose and have to use _as little data as possible, store it as short as possible_ etc. You also still have to inform the user about it, give them a way to delete it (through because you also have to keep that data as little and as short as possible you often delete it faster then the time you have to process such deletion requests so that tends to be a non issue)

this section of GDPR pretty much never applies to anything ad related ever, because even if you collected some fingerprints for DDOS protection you MUST NOT use them for ads, not are you allowed to pass them to anyone else especially not if that entity does use them for something else.

pretty much nothing in the law text of GDPR ever implied you might get away with aliasing tracker domains, actually very clearly the opposite

generally GDPR is not technology specific, so pretty much any case of "this technical trick to work around GDPR limitations" is pretty much not legal as long as the trick is not to not collect data

Don't need to mansplain DNS RFCs and GDPR to me, explain it to the companies that use CNAME trackers, and maybe their marketing departments.

I am just stating the trend of ad tracker technologies, and how useless the Datenschutzbehoerde is in practice, from the perspective of someone that builds a browser network that tries to uncover these types of constellations.

then maybe formulate your comment better

because from what you posted above it clearly seemed you don't understand GDPR

people which don't know anything about the topic might come to believe that using CNAME is an actually legally working workaround instead of just a way to hinder ad-blockers

> Note that CNAMEs is literally caused by GDPR

No. The migration to CNAMEs has to do with the phasing out of third party cookies. The GDPR literally does not care about how the technology works.

> Note that CNAMEs is literally caused by GDPR

nonsense

GDPR is not technology specific weather you use aliases or not makes not difference (neither weather you use cookies or other e.g. heuristic methods for fingerprinting btw.)

These "it's the fault of GDPR" posts feel like the comic book caricatures where angry citizens rant that Batman is the cause for all the crimes in Gotham City.

No, it won't work as well as uBO. Many features from uBO are missing in uBOL even in full mode, more prone to anti-adblock/ads-reinsertion (problems with `redirect-rule` and unable to fast updates) and ads/trackers/popups can slip through if cannot be caught by regex filters.

> The security win can't be understated: with its permission-less design (enabled by MV3) I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions.

Can you or someone else elaborate way it would be more secure? I dont quite follow or see the benefit.

Look at the security on mobile OS. It is perfectly secure for Apple and Google. But seriously, the benefit is theoretical and only with the assumption that you believe Apple and Google to treat your data better than a third party. Brave assumption in my opinion.

I don't like the goal of giving less power to extensions. Extensions have traditionally generated independent innovation, when they're allowed to. They're an escape hatch.

And the security problems of malicious ads slipping through at higher rates aren’t an issue?

>I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions.

Why would you even have autoupdates in the first place if that is your threat model?

>as I run macOS

How is the FDE story on macOS? Isn't it closed source - how can you tolerate that as a cryptographer? (Not saying Linux is perfect, cryptsetup doesn't have a secure AEAD mode)

Apple’s crypto implementation is.

And what's the use if you don't know they're not compiling against a backdoored version under the hood?

That's a different question.

No, you're just moving the goalpost (and you're pretty bad at it too)

Perhaps I’m bad at it because I wasn’t doing it at all?

You asked how someone can trust a crypto implementation that isn’t open source. I replied to the to it directly: it actually is open source. Personally I see the source being available largely irrelevant but I replied to exactly what you asked for.

Your second question is an entirely different topic, which is how you can trust that something isn’t backdoored. Notably, this has nothing to do with whether source is available. How I would typically do that is by inspecting the compiled artifacts themselves, which is the same whether the code is available or not. Of course, this requires that the OS or the AP or the crypto engine isn’t backdoored, for which there exist more involved verification processes. Whether this is possible to do in general is a difficult research area. It is, however, completely divorced from your view on how this works because auditing the properties you’re looking for does not rely on source code at least in a traditional sense.

An AEAD mode on a physical disk doesn't make a lot of sense. You are mapping disk blocks to disk blocks (in the case of cryptsetup, literally via devicemapper) and so you have two choices: a) alter the sector size to something weird so you can fit in tags per sector, likely breaking a lot of code that can't cope with this or b) just use XTS and accept that you can't have AEAD.

It isn't like the average hard disk permits padding oracles and chosen plaintext/ciphertext attacks to be mounted easily, except of course if you are storing disk images in the cloud, but then you're using the wrong tool anyhow - do crypto at the file level where you aren't constrained by sector sizes.

> you're using the wrong tool anyhow - do crypto at the file level where you aren't constrained by sector sizes.

Really, I'd say that 99% of the uses of block device encryption would be better served by using a filesystem that supports encryption natively. The remaining 1% is for block devices that handle the encryption in the hardware.

Hqng on, MV3 still lets extensions read web traffic, right? It just can't block it.

declarativeNetRequest (https://developer.chrome.com/docs/extensions/reference/decla...) involves loading a ruleset into the browser, which then does the blocking itself inside the network process.

Firefox's implementation of MV3 allows both async permission-less blocking (declarativeNetRequest API) and permissioned synchronous blocking (webRequest API). uBO Lite uses the former to provide an ad-blocker without read/write permissions.

You can still write a unsandboxed extension with MV3 (and in Firefox it will still be able to intercept requests, while in Chrome it will not be on the network hot path) but the point is that you can also write a permission-less ad-blocker now, which is what I want.

You need the webRequest API (that uBO Full is using) from manifest v2 to be able to read the traffic. Without it, you can just block/allow based on rules.

Chrome is deprecating it with v3, Firefox supposedly no.

Unless I'm misunderstanding the docs, the webRequest permission isn't going anywhere, just the webRequestBlocking one. So it doesn't sound like there has been any security win here.

Yeah, I think you're correct. The security win is that you can block without needing the permissions for webRequest which are "can read and modify everything you do"

If you sideload an extension, you can achieve your 0 third-party silent autoupdate goal without compromising on any functionality (though this misfeature should be a per extension toggle at the browser level)

In Firefox, you can disable automatic updates per-extension. So you don't need to sideload to achieve this.

Even better, thanks for the correction

You could also just turn off extension autoupdate.

That only makes a difference if you’re auditing each extension update. Switching to extensions with per-site permissions reduces the attack surface drastically and you don’t have to worry about auditing or disabling updates.

I considered that a few times, but eventually complex things like modern ad-blockers rot, so I would be forced to update every once in a while, and let's be honest: I am neither qualified nor prepared to audit the diff.

I guess deferring updates would give me lead time to let others get targeted / detect an issue before it's likely I would get the update. Still, installing the permission-less version is so much simpler and reassuring.

I rely on the latter. I am much more concerned about supply chain attacks of mass exploitation than I am about 0day in my Signal client or my browser extensions.

If there is something big enough to warrant quick update, my HN addiction will make sure I find out about it before it is a 1day.

There really isn't a great configuration for browser security rn, is there? The gold standard I think is Qubes, which afaict is not practical.

Turn off extension autoupdate sounds like a bad choice, not all updates are mallware injected, many of them may contains security updates anyway

So can you tell Firefox to only allow MV3 (or MV3+sandboxed, I guess) extensions then? Or have you manually audited your list of extensions?

I was sort of aware but your post clearly reminds me that Firefox extensions are probably my single biggest point of general vulnerability on my phone and computer, given how much is done in browser.

Appreciate your original thoughts either way.

If you don’t trust the OG ublock what makes you think you can trust the Lite ublock?

the fact that it cannot do a lot of untrustworthy things under the new v3 policy, like remote execute code, that is literally the point.

The point is to neuter extensions to the point where they can't effectively block ads.

Can uBOL be autoupdated to a v2 extension? That would negate this point.

It would only partially negate the point. Any new permissions would trigger a prompt for the user to accept the additional permissions before installing the update. Also there is some aspect of human review for updates to extensions on the Mozilla Addons site.

At that point it would request the global "read and modify all sites" permission, which makes it kinda obvious.

Lack of custom filters is an immediate no-go.

Is there any benefit to ublock origin full fat Vs lite? I've been using it for years on Firefox and android but it sounds like I should switch?

What do you think about using Brave on Apple with its built-in ad-blocking?

Brave just shows a different set of ads.

That's only if you opt-in to the Brave ads.

You use Mac. You are already being attacked by Apple. Both on the permissions to run the computing you want, and your data being harvested by them.

Good on you nonetheless to check one less, but the one still open is much larger, so the fight goes on.

> attackers could still get into Mozilla, Apple (as I run macOS), or cause a backdoored update to be pushed via Homebrew [..] but unsandboxed browser extensions were clearly the lowest hanging fruit

This is a total non-sequitur. The source of all malicious browser extensions is Google, Apple and Mozilla, and none of them have demonstrated any willingness whatsoever to fix the problem, even when a mere grep across their distributed extension base can trivially identify all the various openly advertised trojan SDKs that cause millions of users to be tracked or have their internet connection reused for various shady proxy websites.

You have a different definition of "malicious" than the general public. In fact most of us on HN do. That shouldn't be dictating what browser vendors think of as malicious extensions. Consider an extension that tracks your browsing in exchange for giving you promo codes to get 5% off on some purchase. Plenty of users have considered this kind of trade off and decided that the 5% discount is worth the privacy impact. Most HNers would consider it malicious. But if browser vendors start to block these extensions we would sooner hear news reports of tech companies being overly paternalistic.

You are not speaking for all users and you know it.

No informed user would consent to a Trojan however.

Just like nobody informed is using a smartphone or cloud anything

I'm not clear to what you mean.

The person I replied to said no informed user would go with a Trojan. I disagreed, citing the popularity of modern phones and cloud storage.

Reply on news.ycombinator.com