Browser Extension MV3 v0.4.0: time to update

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.

5 reasons why the extension is better now

Reason #1: the new rule priority 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.

Reason #2: $badfilter support

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 overrides 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 in the same file. If you had a rule in one file and added $badfilter to it in another file, it simply 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.

Reason #3: 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

Reason #4: support for the $elemhide, $generichide, $specifichide 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 only sends rules that are not excluded to the content script.

Reason #5: everything else

We’ve added 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
• The $all modifier is made of all content-types modifiers and $popup
• The $csp modifier completely changes the rule behavior. When applied to a rule, the rule won’t block the matching request. Instead, response headers will be modified

This is the first ad blocker to run under the harsh conditions of Manifest V3, and you’ll help us a lot by reporting problems with the extension on GitHub.