Adguard Manifest V3 Brings New Features and Changes

Adguard Manifest V3 has introduced a new feature called "async scripts" which allows scripts to run in the background without blocking the main thread of the browser.

This feature is a significant improvement over the previous version, which often caused browser crashes and slow performance.

One of the key benefits of async scripts is that they can run without blocking the main thread, making the browser more responsive and efficient.

Adguard Manifest V3 has also introduced a new feature called "content security policy" which provides an additional layer of security for web applications.

See what others are reading: Dns Adguard Com Android

In the upcoming release version of AdGuard Manifest V3, you can expect some exciting new features. Filter management will be updated to automatically sync with the extension, eliminating the need for manual or automatic update options.

The filtering log will make a comeback in a modified form, providing an "approximate rule that was triggered" based on AdGuard's engine. This is due to DNR restrictions, but users can still install the "unpacked" form of the extension for more precise information.

Statistics will be displayed on a new stats screen, showing a categorized list of URLs by company, sorted by type, and requests sent. All data is handled on the client side, and no request information is stored.

We're in the process of making some significant changes to our extension, and I'm excited to share the details with you. We've switched to a new UI that's similar to our old MV2 extension.

One of the main reasons for this change is Manifest V3, which divides rules into static and dynamic with strict limits. Static rules are capped at 30,000 per extension, with a cumulative limit of 330,000 for all extensions installed by a single user.

We're currently operating with 5,000 rules instead of 30,000 as we work on categorizing them to fit within these limits. This is a temporary measure until we can provide further updates in future releases.

Some of the changes we're working on include adjusting the maximum number of static rule-sets and enabled rule-sets, as well as increasing the maximum number of dynamic rules to 30,000.

Here are some of the specific changes we're making:

We're also discussing some other changes, including providing a way to register a "page script" and adding support for wildcards in initiatorDomains and excludedInitiatorDomains fields.

In the upcoming release, you can expect some exciting changes to the extension's filter management system. The manual and automatic update options will be removed, but you'll still be able to check for extension updates and receive notifications.

The filtering log is also making a comeback, but it will be in a modified form due to DNR restrictions. We'll provide an approximate rule that was triggered based on our engine, but for precise information, you'll need to install the "unpacked" form of the extension.

The new stats screen will resemble the query log in AdGuard DNS, displaying a categorized list of URLs by company, sorted by type, and showing the requests sent. All data is handled on the client side, and we don't store any request information.

Here's a breakdown of the new features:

Declarative rules are a new way of creating filters in Chrome, introduced with Manifest V3. They're a departure from the old dynamic filtering engine.

The syntax for declarative rules is quite different from what we're used to, and it's causing some issues for developers. Each rule should consist of fields like id, priority, action, condition, and more.

Here's a breakdown of the fields:

The problem is that many of our existing rules can't be converted to declarative rules, due to limitations like the lack of support for regular expressions, exclusions, and cookie rules. This means we'll have to rewrite many of our filters to make them work with the new API.

Declarative rules syntax is quite different from what you're probably used to. Each rule should consist of three main fields: id, priority, and action.

The id field is used to identify the rule, which can be useful for associating a declarative rule with a text rule. The priority field determines how the rule will be applied to the query. The action field is where you specify what action the rule will take.

The action field can have one of three kinds of actions: condition, which is the condition under which the rule is applied. Here's an example of how this works:

This rule will block all requests to scripts that have an abc substring in their address and originate from the site with the domain example.org.

To make this work, you'll need to specify the id, priority, and action fields correctly. The id field can be a unique identifier for the rule, the priority field determines the order in which the rules are applied, and the action field specifies the action to take when the condition is met.

Here's a breakdown of the fields:

Keep in mind that while this syntax may seem straightforward, there are some limitations and restrictions that you should be aware of. For example, the $removeparam operator does not support exclusions (~) or regular expressions (regexp).

Rulesets are a crucial aspect of declarative rules in Manifest V3. They must be combined into rulesets.

In Manifest V3, declarative rules are specified in the manifest.json file and are loaded only when the extension is installed or updated. This can be a problem because sometimes a filtering rule can break the layout or performance of one or several websites.

Websites are constantly changing, and rules that used to be fine earlier might cause issues now. This is why having a simple way to disable individual rules was a huge advantage in Manifest V2 extensions.

Unfortunately, the "$badfilter" modifier used in Manifest V2 to disable rules won't work in Manifest V3. This means filter developers can't update filters quickly to fix issues.

Filters may not be updated for several days on end, which can be frustrating for users. However, there is a small chance that extensions will be given the functionality to update filters quickly in the future.

Here's an interesting read: Manifest V2 vs V3

The new AdGuard Browser extension, based on Manifest V2, has a filtering log that shows detailed information about requests sent by your browser. This log allows you to see which filtering rule was used to block a particular request.

However, due to Chrome's new blocking policy, we can't implement the filtering log as we used to. Instead, we'll have to rely on a peculiar alternative that will launch an old engine to show which rules may have been applied.

For now, filter developers will have to install the extension in an "unpacked" form, clone the repository, build the extension, and switch the browser to Developer Mode to access debugging tools. This will allow them to get information about which rule triggered, but it's a bit of a hassle.

Curious to learn more? Check out: Chrome Extension Manifest V3

Manifest V3 imposes strict limits on the number of rules and filters an extension can have. These limits are in place to prevent overloading and ensure a smooth user experience.

The maximum number of static rules per extension is 30,000, with a cumulative limit of 330,000 for all extensions installed by a single user.

For regex rules, the limit is set at 1,000 per extension. This means that extensions can't overload the system with too many complex rules.

Dynamic rules are also subject to a strict cap of 5,000 rules, which includes a maximum of 1,000 regex rules. This means that extensions can't have too many dynamic rules, including regex ones.

If the limit of 5,000 rules is exceeded, only 5,000 converted rules will be applied, in the order of Allowlist, User rules, and Custom filters. The rest of the rules will be displayed in the editor but not applied.

The maximum number of simultaneously enabled filters is 50. This is a hard limit that extensions must adhere to.

The stats and filtering log is a powerful tool in AdGuard Browser extension. It shows all the requests sent by your browser and detailed information about them, including which filtering rule was used to block a particular request.

This log is based on Manifest V2, but Chrome itself now blocks requests and shares statistics only with extensions installed in Developer Mode. This makes it difficult to implement the filtering log as it used to be.

Fortunately, AdGuard has come up with an alternative solution. When you open the filtering log, an engine that works by the rules of Manifest V2 will be launched. It won't do anything with the requests, only show which rules may have been applied.

By comparing the Chrome statistics with the results of the old engine, you'll get a rough picture of how requests are processed. This is a good workaround, but it's not the same as the original filtering log.

Currently, the prototype does not implement a filtering log. Instead, filter developers will have to use the mechanism recommended by Chrome developers. This involves installing the extension in an "unpacked" form, which requires some technical expertise.

To use the tools for debugging filters, you'll need to clone the AdGuard repository, "build" the extension, switch the browser to Developer Mode, and only then will you be able to access the debugging tools.

Intriguing read: Manifest V3 Release Date

AdGuard Manifest V3 offers several experimental features that allow users to customize their browsing experience. One such feature is the ability to block tracking scripts.

The `scripting` property in the manifest file allows users to specify which scripts are allowed to run on a webpage. This can be useful for blocking tracking scripts that are often embedded in third-party widgets.

Blocking tracking scripts can improve user privacy and reduce the risk of malware infections.

We started working on a new browser extension in mid-2021, a prototype that would block ads even within the strict limits of Manifest V3. This was a daunting task, as the new API was still raw and some aspects were being finalized.

The new API presented a lot of problems, including features that didn't work as intended. We faced many serious issues while developing the prototype.

We managed to overcome some of the problems, but others we had to reconcile with. This was a challenging experience, but we proved that ad blockers can survive even after the apocalypse that is Manifest V3.

The new API was still being developed, which made it difficult to work with. We had to adapt to its limitations and find ways to make it work for our purposes.

We developed an experimental AdGuard MV3 Browser extension, which showed that it's possible to block ads even in a restrictive environment. This was a significant achievement, considering the difficulties we faced.

In Manifest V3, messages received by an extension over a websocket connection won't wake up the sleeping service worker.

This can lead to missed updates and error messages about traffic limits, device limits, and non-routable domains.

The initial plan was to make an unsleeping service worker, but the team decided to play by the rules and connect to the websocket only when the service worker is awake.

A solution was found, but the team hopes Google will address the issue and add the possibility to extend the service worker life with messages received over the websocket connection.

Adguard Manifest V3 is built on top of the Web Extensions API, which allows it to interact with the browser in a more secure and efficient way. This is a significant improvement over the older manifest v2 system.

The new manifest v3 system has a more limited set of permissions, which helps to prevent malicious extensions from accessing sensitive user data. This is a major security benefit.

Adguard Manifest V3 also uses a new concept called "declarative content scripts", which allows scripts to be declared in the manifest file rather than being injected dynamically. This makes it easier to manage and debug scripts.

The service worker is a crucial part of Manifest V3, replacing the background page that used to exist in Manifest V2. It's a separate background process that works with browser APIs, but it can be interrupted by the browser.

In Manifest V3, if the browser stops the service worker, the extension goes into a kind of sleep mode, where declarative rules still work, but cosmetic rules don't. To make the extension functional again, something needs to wake up the service worker, like loading a page or sending a message to it.

The service worker needs to wake up before it can read filtering rules from the repository and process them. During this time, the extension doesn't apply cosmetic filtering, but ad requests are blocked by the browser itself for about 1.5-2 seconds. This is a temporary delay before the engine launches and ads disappear.

Chrome has implemented a workaround to prevent the service worker from going to sleep, which helps reduce the delay and glitches that occur when the service worker is inactive. However, this workaround is not foolproof and can be removed by Chrome at any time, causing the delay and glitches to return.

Here are some key facts about service worker functionality in Manifest V3:

The Network Connection Observer is a class that monitors the network status, helping to identify whether the issue is with the user's Internet connection or the server.

It listens for the online event and calls the callback passed to it, making the implementation simple in MV2.

However, in MV3, the service worker doesn't have access to window, making the implementation more complicated.

A solution is to use an offscreen document, which would create an invisible page with access to window and document.

But Google promises that in the future, the offscreen document will fall asleep after a period of inactivity, similar to the service worker.

This would lead to problems with the Network Connection Observer not being able to listen to the online/offline event all the time.

So, a not-so-subtle solution is to check the state of navigator.online every half second and call the callback if it has changed from offline to online.

The service worker in Manifest V3 can't enter hibernation mode due to events and API calls.

One key limitation is that the service worker is restarted when an event occurs in Manifest V3, requiring event listeners to be registered at the top level of the code synchronously.

In Manifest V3, the Alarm API has a limitation: it's impossible to set a timer that works in a short time frame, such as 3-5-10 seconds, but only in a minute or more.

This limitation can cause errors if not taken into account when implementing timers in your extension.

To avoid errors, consider using the Alarm API for longer time frames, such as minutes or hours.

Here are some examples of events that can prevent the service worker from entering hibernation mode: