This might be the end of filter lists

Now that you mention it, EasyList has become very bloated over the past few years.

Well, it’s not as bad. About 70% of EasyList rules are actually used. The problem is that 90% of these rules are used very rarely, on some unpopular websites.

But if I understand the consequences of removing webRequest from Chromium, then it’d also break hundreds of other extensions, like Tampermonkey, NoScript, Stylish, I Don’t Care About Cookies, and Redirector. So people who think that this will only affect adblockers, would be very disappointed when half of their extensions would become unsupported overnight.

  1. Stylish, I Don’t Care About Cookies and Redirector - should be okay.
  2. NoScript - might be broken.
  3. Tampermonkey/Violentmonkey/Greasemonkey - no technical issues with them, but they might be affected by the “remote scripts” limitation.
1 Like

And here is an update from Chrome developers.

What’s important:

  1. As I’ve said, declarative webRequest is what we’ll have to live with.
  2. However, the old API will still be available to enterprises (!).

By now I don’t know what the Chromium team have been smoking.

It feels like they used ABP (or a knockoff of ABP) for all of 3 minutes, using only the default settings, and then concluding that that was what the entirety of adblocking was about. They seem to not even know that there’s more than 1 filterlist in existence; in fact they don’t seem to even know about EasyList’s regional versions (like EasyList Germany).

Holy freaking cow. Why on earth are they trying to create a new extension API when they aren’t even using nor aware of any of their goddamn extensions?

1 Like

If the Chromium team wants a war, then I’ll give them a war.


Due to a few reasons listed below, the war has mostly been placed on hold for now:

  • I had misunderstood the dev’s comments about rolling out to “Canary” as meaning Chrome Canary instead of Chromium Canary.
  • was updated to show a note from Google about how they (according to themselves) were not intentionally sabotaging adblockers.
  • The EasyList maintainers’ belief (e.g. smed79) that list writers should remain neutral about things like these, thus I wouldn’t be able to rely on their support at all regarding this.
  • I’ll need to tend to other things in my life for the next week-and-a-half-ish, including a water leakage in my kitchen and to challenge myself to properly learn how to read German (beyond just kids media).

In theory, list authors will be able to easily create their own extensions with static lists of their filters instead of relying on ads blocking extensions.


Chrome supports the use and development of ad blockers. We’re actively working with the developer community to get feedback and iterate on the design of a privacy-preserving content filtering system that limits the amount of sensitive browser data shared with third parties.

How this can be private if web requests can still be read?

1 Like

While I am not aware of any of the details around making a static extension for each list maintainer, I can only imagine it’d be daunting for most maintainers to have to deal with Google’s add-on rules/community on a regular basis, in addition to the potential of having users’ extension drawers be cluttered beyond belief. A significant amount of maintainers (Me included) also couldn’t code extensions from scratch if it was a matter of life and death, so there’d have to be some easy extension templates available.

And that is indeed the quote I was thinking of.

How this can be private if web requests can still be read?

I suspect Google of not having any real idea what they’re doing, in addition to how I personally believe that the spokesperson behind the update note may potentially not actually be involved in the Manifest v3 process, even if it is semi-soothing words (s)he is speaking.

Yeah, but with a few issues:

  1. Cosmetic filters aren’t a part of this new API
  2. The lists will be completely independent, so:
    • You won’t be able to disable a rule from the other list. For instance, it sometimes necessary to disable and redefine some rules from EasyList.
    • Whitelisting a website will be the real hell. You’ll need to disable each one of these extensions.
    • Debugging lists will be quite hard for the same reason.
1 Like

Here is an update from Google:

What’s important is that they’re planning to increase the limit to 150k. However, this does not solve the issue because they’re talking about the “static” rules limit (ruleset hardcoded into the extension).

We need the dynamic rules limit to be increased drastically from the current 5k value. Otherwise, having different filter lists is simply impossible.

Here’s a longer version:


Meanwhile, the discussion intensifies:

A member of Chrome’s security team tries to explain why the change is necessary and will improve performance and security.

IMO, the performance argument seems legit. What for the security argument, I am not convinced to say at least.

They, similar to me above, miss that half of the filter lists are cosmetic filters:

Injects CSS into a page.

To use this API you must have the permission for the page’s URL, either explicitly as a host permission, or using the activeTab permission.


Also they think filter lists are created by little fairies. Filters are crowdsourced! Blocking extension must include logging feature to assist filter creators, and must be as easily available as possible. Even now people complain that uBO Logger is too complicated - developer tools will definitely not work for this.

Fortunately, this API is not going anywhere. But for using it we’ll have to request “any URL” permission, and that kinda defeats the purpose of DNR…

They promised a callback with the info on applied DNR rules.

This is a long shot beyond measure, but considering how Chrome has begun to show Adobe Flash shutdown notifications a year and a half early:

Is it a possibility that the Chromium team is trying to remove the previous manifest in late 2020 in an odd attempt to break support for Flash as hard as they physically can?

The only thing they need to do to achieve this is to not make much effort to support the old API:)

First of all, hello all! I’ve waited too long to join your tight knit community. Collin, I’ve never seen such well thought out backup codes for 2fa.

Anyway, Google does what’s best for Google. After all, it is Google - the top tracking and advertising network on the web and as of late according to Spamhaus - Botnet Report 2020 - the number 2 ranked hosting platform for malware distribution through propagation of Botnets using via the Google Compute Engine. They are also ranked as one of the worst providers in responding to abuse reports. So long as they get paid…

OT: The U.S. has retaken the #1 rank back from Russia for Botnets. Go U.S.A! Russia is now number 2. They continually trade places. Also, Namecheap and GoDaddy are the worst registrars due to bulk registrations. Namecheap has a “Beastmode” where miscreants can order 500 domains at a time at steep discount. Again so long as they get their money…

If you do look here on you’ll see that CloudFlare is ranked 5, despite not technically being a host due to its protection and ease of use their are currently over 9,000 sites hosting malware with CloudFlare’s help.

Now, Amazon did begin a fairly good effort to get its house in order which is a positive.

For others, though, it’s all about the money.


There’s no need to stay with Chrome, is there? You can use a web browser with a different engine. That should help move people away from the browser monopoly.

1 Like

I’ve been rather uncomfortable with Firefox in recent years, chiefly due to the strange gift-button in the upper right that wants to promote strange new functions that no one asked for (such as the time last year where they promoted some concert livestream that only American users had access to, or something similar to that).

It really shouldn’t have to be this goddamn complicated to remove the button in question.

That being said, yes, I suppose I have loose plans of switching to Firefox sometime in the next 6-12 months. I don’t have any haste at the moment… with the exception of the amount of access_status_violation errors in my Chrome setup having become more frequent by an order of magnitudes in the past few months (Probably not helped by how I participate in [email protected] since early April), with even a few hardcrashes that required a system restart before I could use Chrome again.

And also I can see that it’s a very bad sign for CloudFlare that they’re listed with 10,755 malware sites on the AbuseCH page at the time of writing.

Indeed. Yet it’s next to impossible to have them intervene even with such glaring evidence due to the fact that they’re not a webhost, only a DNS provider (among other things) which is the argument they use. Yet protecting malware hosts, and even helping them in their forum which, while not obvious, is apparent. Example: CloudFlare recently stopped allowing CLI for DDNS updates if the TLD behind the DDNS server is one among .tk, .cf, etc. It’s so tiny a step in the direction toward not protecting malware hosts that one would think no one would really notice, since using the GUI dash directly is still allowable for those “use-cases”. Apparently those who host malware are also fairly lazy since the outrage it inspired was far beyond what one would expect. The forum was overrun with new accounts posting threats & ultimatums regarding the commenters leaving CloudFlare. It was hilarious & very telling.

Now only show info about:

  • PiP mode;
  • notify about poor password saved in Firefox Password Manager;
  • added new safe password generator for password fields in form.