Hacker News Reader

> I don't see how one follows from the other. Attackers are using malicious extensions to eavesdrop on networks... therefore we need better reviews and not restricted APIs? I get why you might want to advocate for the latter over the former, but certainly it seems like restricting APIs also has positive impact.

As I understand it, the APIs that are removed only remove the ability to modify network requests; the remaining APIs will still allow you to inspect requests.

(Disclosure: I work at Mozilla but not on extension APIs or even Firefox. I have written extensions myself though.)

Ah, thank you. So the idea here is that extensions will still have the read access to requests, which is all attackers care about (typically). Confirmation would be interesting - at minimum I thought that inspecting requests (read only) Was being limited, but I'm just a casual observer.

I think this is the relevant API: https://developer.chrome.com/docs/extensions/reference/webRe...

> As of Manifest V3, the "webRequestBlocking" permission is no longer available for most extensions. Consider "declarativeNetRequest", which enables use of the declarativeNetRequest API. Aside from "webRequestBlocking", the webRequest API will be unchanged and available for normal use.

So the other functionality, to inspect web requests, will still be available.

> Can someone give an example of what a good number would be? How many dynamic rules are currently used?

uBlock's built in list has 47,000

EasyList has 75,000

EasyPrivacy has 31,000

Fanboy's List is 78,000

Basically none of the major lists fit inside this quantity.

Thanks. Has Google explained why the limit is so low? This doesn't seem like it would be super useful to an attacker, or meaningful for performance to change to, say, 150k. They've already raised it.

Has Google explained why the limit is so low?

I don’t think we need the adtech company to make a statement for us to know what’s going on here.

Well, I don't see how this would impact Google at all. Obviously as one of the biggest advertisers all of Google's advertising will fit within the limit and will be highly prioritized over others.

Yea, I would be okay with spending all 30k of those on just YouTube ads, and pihole for the rest. Google is the biggest advertiser, so logically their ads would go first or close to the top

If anything Google would be incentivized to increase the size, since that would impact competitors. So I'm just curious to learn more about the justifications - like I said, they've made a number of changes to the APIs already in the last two years or so.

EasyList has become bloated with many rules being outdated or invalid. It's a system where rules are added at a much faster rate than they're removed. It's not like there's test suites or anything to shake loose old rules, so it only ever grows.

Checking 150K rules once wouldn't be a problem, but if you have to do that for 50 network requests on every single page load, that adds up. So the hope, as I understand it, is to set a ceiling to encourage developers to keep more up-to-date lists by pruning old and outdated rules. This prevents a situation where browser performance slowly degrades.

I'd like to see a system where users opt-in to allow ad blockers to collect metrics on which rules are actually applying, and have them occasionally trim anything under 0.01% usage. Which sounds like a small number, but should capture the majority of dead or unused rules. Of course, that would require a new browser API in a declarative system.

Coming to an extension store near you: AdBlockr (Part One) and AdBlockr (Part Two)! We've heard your feedback and have split our extension into two, more narrowly focused blockers. Only block what you need, without the bloat of a monolithic blocker! Or use both extensions for complete security with up to 60,000 rules!

Is that 30,000 limit per extension, or global?