3 ms·
> But Google has decided that block and allow are not that easily abused so it will allow up to 30,000 rules to be added dynamically. Can someone give an examp
by insanitybit 3y ago
> But Google has decided that block and allow are not that easily abused so it will allow up to 30,000 rules to be added dynamically.
Can someone give an example of what a good number would be? How many dynamic rules are currently used?
> Also, extension developers are limited in what regular expressions they can use, along with other technical limitations.
Does this meaningfully impact rules? Just curious.
> According to Firefox’s Add-on Operations Manager, most malicious extension that manage to get through the security review process, are usually interested in simply observing the conversation between your browser and whatever websites you visit. The malicious activity happens elsewhere, after the data has already been read. So in their mind, what would really help security is a more thorough review process, but that’s not something Google says it has plans for.
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.
- Macha 3y ago> 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.
- insanitybit 3y agoThanks. 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.
- jimbob45 3y agoHas 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.
- insanitybit 3y agoWell, 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.
- THENATHE 3y agoYea, 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
- insanitybit 3y agoIf 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.
- SquareWheel 3y agoEasyList 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.
- a_wild_dandan 3y agoComing 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!
- deleted 3y ago[deleted]
- Vinnl 3y ago> 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.)
- insanitybit 3y agoAh, 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.
- Vinnl 3y agoI think this is the relevant API: https://developer.chrome.com/docs/extensions/reference/webRequest/ 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.
- erichurkman 3y agoIs that 30,000 limit per extension, or global?