What happened to Custom filters and Quick Fixes filter, or the impact of MV3 policies
“Where are Custom filters? And what happened to the Quick Fixes filter?”
To comply with Chrome’s strict remote execution policy under Manifest V3, we’ve had to make some tough decisions. Custom filters are temporarily unavailable, and the Quick Fixes filter has been removed for good.
Why? Because Chrome’s policy prohibits injecting scripts or remotely hosted code. While the intention behind this policy is good, the wording is so broad that even ad-blocking rules can fall under these restrictions — and unfortunately, both Custom filters and the Quick Fixes filter did.
Why this is a problem
First of all, the Quick Fixes filter was implemented only because of the limitations of MV3.
In the MV3 extension, all AdGuard filters are pre-built within the extension itself, which means that filter updates can only be delivered through full extension updates, with a review in the store. And those updates can take days to reach users. If a popular website breaks, users are stuck waiting for a solution — frustrating for them and for us.
In MV2, we solved this problem with differential updates, so we could quickly release new filters without updating the entire extension. But MV3 doesn’t allow that, and the Quick Fixes filter was our workaround to deliver real-time updates.
Despite our best efforts to make this filter compliant (the agonizing history of our back-and-forth battle over this filter can be found below), Chrome’s policy ultimately forced us to remove it entirely. And that’s just one big loss.
Another loss is Custom filters, which also had to be sacrificed due to the same remote execution policy.
Custom filters allow users to add third-party filters via a URL. Thousands of volunteers maintain these filters, which are essential to the growth of the ad-blocking ecosystem. We can’t include everything in our “pre-built” filters, and Custom filters was the place to tailor filtering and easily test and distribute those filters.
The loss of Custom filters is not just a setback for users; we are committed to doing our best to keep our extension effective for them. However, as we’ve said before in one of our many MV3-related posts, “the real victims in this transition are filter developers”. And here it comes: Losing Custom filters is a blow to the community that keeps the ad-blocking world running.
How we are solving this
We’re overhauling how AdGuard handles filtering rules to comply with Chrome’s policies while keeping the extension functional and useful.
Here’s what we’re doing:
To bring back Custom filters, we’ll use the
userScriptsAPI. This API lets us register scripts in a way that complies with MV3 policies.However, there’s a catch: users will need to enable Developer mode to use them, which adds an extra step. We know this might be a barrier for less tech-savvy users, so once we roll out the version with custom filters, we’ll make sure to provide clear instructions on how to enable it and add filters.
Since the Quick Fixes filter can no longer exist in its original form, we’re switching to Chrome’s fast-track review process. This will allow us to update filters more frequently without waiting for a full extension review. However, this method has some limitations: it only applies to changes in DNR rulesets and safe rules.
We’ll soon have two types of extension updates: fast-track updates — set to happen automatically every few hours, and full updates — with a review in the Chrome Web Store.
It’s been a long road to even get to this not-so-ideal solution. Below is a timeline of everything we tried to make our extension comply with Chrome’s policies while still blocking ads effectively and letting users customize filtering the way they want.
The timeline of our struggle
- 1st rejection: Remote script execution
Our submission was rejected for using <script> tags to apply rules. We indeed used a mechanism where the extension would extract scripts from rules and apply them to the page via the <script> tag. For MV3 extensions, the Content Security Policy requirements are stricter than for MV2 and we can’t just inject script rules, which severely limits the tools available to developers for modifying page content. That’s why in some cases, we had to enhance the <script> tag injection, and that became a problem.
What we did:
We adopted a solution that we’d used in Firefox: converting script rules into local JavaScript functions stored within the extension. This allowed us to apply rules natively without <script> tags. We also added checks to ensure scripts were part of built-in rules before applying them.
However, exceptions were left for User rules, Custom filters, and the Quick Fixes filter, which still used <script> to inject rules.
The version with those changes was approved. Until it was not.
- 2nd rejection: Quick Fixes filter download
This time, Chrome flagged the mechanism for downloading the Quick Fixes filter from a remote source, interpreting it as a violation of the remote execution policy.
What we did:
We added detailed comments explaining the purpose of the Quick Fixes filter and clarified how it was designed to address MV3’s limitations without violating policies.
This wasn’t enough to satisfy Chrome reviewers, so here goes…
- 3rd and 4th rejections: Quick Fixes filter
To meet Chrome’s requirements, we removed the Quick Fixes filter entirely and resubmitted the extension. After receiving the rejection again, we contacted support and submitted a version that completely disabled downloading the Quick Fixes filter code and metadata. This version was initially approved, but...
- 5th rejection: Scriptlets and parameters
Chrome flagged the use of scriptlets — built-in JavaScript functions — as violating the remote execution policy because they could be executed with parameters.
What we did:
We hardcoded all scriptlets directly into the extension. The extension engine now validates whether a rule matches a pre-built filter category (e.g. Ad blocking or Security). If there’s a match, the rule is applied; otherwise, it is discarded.
We also reintroduced the Quick Fixes filter in a limited form, but without <script>-based execution.
Despite these changes, the extension was still rejected.
The bigger picture
Of course, we’ll find a way through this — it’s what we do. But this isn’t just about AdGuard. Chrome’s policies affect all ad blockers and extensions.
Developers need clearer guidelines and more transparency from Chrome Web Store. We hope this situation sparks a broader conversation about balancing security and functionality — for the benefit of everyone, developers and users alike.
