Experimental version of unmatched adblock extension built on Manifest V3.
chromewebstore.google.com
It’s been almost a year and a half since we released the MV3-based extension, and it’s time for a major update. After all, we are living in the MV3 reality. The extension now relies on our updated filter engines,
TSWebExtension and
TSUrlFilter. For a look back at how we managed to create the first extension that works with Manifest V3, see
our blog.
Introducing our new rule prioritization scheme
In the past, we had 4 different priorities for rules, but the selection and prioritization of rules within a group was not clear. With our new scheme, we calculate the weight of a rule based on the modifiers it contains. These modifiers are ranked by priority, from lowest to highest, and their impact on a rule’s scope determines its overall priority weight. This new approach allows you to set a declarative priority for a rule at the conversion stage, which is particularly useful for the new MV3. More details about the new priority scheme can be found in our
Knowledge Base.
Support for rules with the $badfilter modifier
The $badfilter modifier has the power to disable any other rule. Here’s how it works: filter developers add a rule with this modifier, and when the extension receives a dynamic update, the rule with the $badfilter modifier takes precedence over the rule it was applied to.
In the past, it wasn’t possible to disable a previously added rule in MV3. As a result, we initially added $badfilter support only for rules that were already present in the same file. If you had a rule in one file and added $badfilter to it in another file, it just wouldn’t work.
However, thanks to feedback from extension developers, the
W3C Working Group has listened and introduced a new API that allows you to disable other declarative rules. This opened the door for us to add $badfilter support for all rules in all files. To achieve this, we revamped the rule conversion scheme to generate additional metadata for filters and dynamically find the rules that need to be disabled.
Support for the $cookie modifier
The $cookie modifier allows you to specify the time to live (TTL) of cookies. The current MV3 functionality is not sufficient for this modifier to work properly, so we've made some improvements:
- If the MV3 API is sufficient for the filtering rule to work, we convert the rule to a declarative one and add it to the static ruleset
- Otherwise, we additionally process cookies in our TSUrlFilter engine and use the browser.cookies API to remove cookies that should not be set or to reduce the lifetime of the cookies
Support for the $elemhide, $generichide, $specifichide exception modifiers
These modifiers help us to turn off cosmetic filtering for certain websites. MV3 doesn’t have such tools yet, so we added support for the modifiers through our TSUrlFilter filtering engine. This engine matches blocking rules to exception rules and sends only not excluded rules to the content script.
And some other modifiers as well
We’ve included support for the following modifiers:
- $method limits the rule scope to requests that use the specified set of HTTP methods
- $to limits the rule scope to requests made to the specified domains and their subdomains
- $removeheader: rules with this modifier are intended to remove headers from HTTP requests and responses
- Sall modifier is made of all content-types modifiers and $popup
- $csp completely changes the rule behavior. When applied to a rule, the rule won’t block the matching request. Instead, response headers will be modified
chrome.google.com
www.wilderssecurity.com
github.com
adguard.com
