Google’s Manifest V3 will change how ad blocking Chrome extensions work: Is it to cripple them, or is it for security?

Google Chrome is the most popular cross-platform web browser available on the market right now, claiming 62.7% of the global browser usage share up until May 2019, with Apple’s Safari coming in second at 15.89% and Mozilla’s Firefox claiming 5.07%. Because of its lion’s share, the smallest of changes that Google Chrome undertakes for its platform end up affecting millions of users around the world. So when Google announced the next extensions manifest version in the form of Manifest V3 for Google Chrome Extensions, we knew we were in for some big changes, especially when it came to light that Google was building in a content blocker API within Chrome itself.

What is Manifest V3?

If you are an active Chrome user, you undoubtedly use a few extensions. Extensions are small software programs that customize the browsing experience using the APIs that the browser provides, allowing users to tailor functionality and behavior to suit their individual needs and preferences. These extensions are distributed mainly through the Chrome Web Store, which is home to more than 180,000 extensions.

Since late last year, Google has been working on “Manifest V3,” a set of proposed changes to the Chrome Extensions platform that can be classified as “breaking changes.” As the public discussion document for Manifest V3 states, the extension manifest version is a mechanism for restricting certain capabilities to a certain class of extensions. These restrictions can be in the form of either a minimum version or a maximum version. Restricting to a minimum version allows newer APIs or capabilities to only be available to newer extensions while restricting to a maximum manifest version allows older APIs or capabilities to be gradually deprecated.

In simpler terms, a new manifest version allows Chrome to restrict APIs and features to this new manifest version, in order to force extension developers to migrate away from certain older APIs due to their negative impact on the user experience. Implementing an extension in Manifest V3 should theoretically provide stronger guarantees from the perspectives of security, privacy, and performance.

While there is a wide range of changes outlined in Manifest V3, the most controversial change relates to Google’s decision to limit the blocking abilities present in the existing chrome.webRequest API (and focus the API around observation instead of blocking) and then present these blocking abilities through a new chrome.declarativeNetRequest API. This particular change has inflamed the community as it ends up targeting the ad-blocking mechanism of the famous ad-blocking extension, uBlock Origin, and directly affects its 10 Million+ users.

Before we address this issue, let’s take a look at how the webRequest API compares to declarativeNetRequest API.

Web Request API and Declarative Net Request API

The present

Web Request’s official description describes the API as follows:

Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.

With Web Request, Chrome sends all the data in a network request to the extension listening for it. The extension then has a chance to evaluate the request and instruct Chrome on what to do with the request: allow it, block it, or send it with some modifications.

Follow along the sequence of events to understand what is happening when extensions use the Web Request API. When a user with a Web Request extension installed clicks on a link, Chrome informs the extension that a data request has been made before the request reaches the server. The extension can choose to modify the request at this stage. The server then responds, but the response once again goes through the extension, and the extension can dictate whether the response needs to be modified. Chrome then finally renders the page and the user is able to view the result of his click action.

As Chrome hands over all the data in a network request, extensions which use the Web Request API have access to read and modify everything that a user does on the web. So while content blockers like uBlock Origin wisely utilize the potential of this API, Google claims that other extensions with malicious intentions have abused the same to gain access to users’ personal information. According to Google, 42% of malicious extensions have used the Web Request API since January 2018. Google also claims that there are “significant performance costs” involved with the API as the blocking version of it requires a persistent and often long-running process which is fundamentally incompatible with ‘lazy’ processes.

With Manifest V3, Google is proposing to limit this API in its blocking form. As an alternative, Google is providing the Declarative Net Request API.

The future

Declarative Net Request’s official description describes the API as follows:

The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.

With Declarative Net Request, Chrome does not need to send all information about a request to the listening extension. Instead, the extension registers rules with Chrome that tell the browser beforehand on what to do if certain types of requests are seen.

The extension specifies its rules beforehand. The users’ request is then matched against this rule by the browser (and not the extension), and the action is also undertaken by the browser, and the page is subsequently rendered. Google mentions that this allows them to ensure efficiency since they can exercise control over the algorithm determining the result and can prevent or disable inefficient rules. It also presents better privacy guarantees to the end-user as details of the network request are not exposed to the extension. Since persistent and long-running processes are no longer necessary (since the rules are registered beforehand), Google claims that this approach also brings performance improvements that will make extensions significantly more viable on resource-constrained platforms.

Declarative Net Request will be available to both Manifest V2 (current) and Manifest V3, but it will be the primary way that Google will allow network requests to be modified in Manifest V3.

The controversy

Google’s changes appear to make sense until you hear the other side of the story, mainly that of ad blockers. This particular API migration is being viewed as Google’s way of killing off ad blockers as it fundamentally changes the way one of the most popular ad blockers works. This ties into the “theory” that Google is motivated towards this change more from the business perspective than from the perspective of user security. After all, Google is heavily reliant on advertising for its revenue, and ad blockers are perceived as a direct threat for Google’s clients on this front, as was revealed through Alphabet’s 2018 SEC Form 10-K filing (via The Register):

New and existing technologies could affect our ability to customize ads and/or could block ads online, which would harm our business.

Technologies have been developed to make customizable ads more difficult or to block the display of ads altogether and some providers of online services have integrated technologies that could potentially impair the core functionality of third-party digital advertising. Most of our Google revenues are derived from fees paid to us in connection with the display of ads online. As a result, such technologies and tools could adversely affect our operating results.

Google had to release a statement to address this, reiterating its stance that the change is in the interest of user privacy and not a direct attack against ad blockers:

We are not preventing the development of ad blockers or stopping users from blocking ads. Instead, we want to help developers, including content blockers, write extensions in a way that protects users’ privacy.

Reference needs to be made to two of the most popular ad-blockers available on Google Chrome: uBlock Origin and Adblock Plus, both of which take different approaches to achieve the same result of content blocking. uBlock Origin heavily relies on Web Request API, and the community has taken a preference to this extension over the years, while Adblock Plus’s approach (coupled with an EasyList filter) mimics that of the Declarative Net Request API.

Google’s push to deprecate Web Request will essentially kill uBlock Origin in its current format, something that will indeed affect a lot of users. While users with no loyalty (and no intention of bothering themselves with how the ad block is achieved) will find alternative solutions that come with their own drawbacks, it will become impossible for loyalists and enthusiasts to come up with new filtering engine designs to circumvent the various techniques that web sites will eventually come up with to combat ad blockers on this specific API.

Declarative Net Request was also proposed to be a rather limited filtering engine, as it was initially planned to have a 30,000 rule limit on per-extension static filter rules (rules that are declared during installation); and 5,000 rule limit on per-extension dynamic filter rules (rules that can be added after installation). Any excess rules will be ignored, which is a bit of a problem as EasyList itself has 70,000 rules, while uBlock Origin can be configured to run with over 100,000 rules. After the initial backlash from the community, Google responded by promising to alter the static rule limit from 30,000 rules per-extension to a global maximum of 150,000 rules. This then has the side effect of precluding users from using other rule-heavy scripts in conjunction with an ad blocker, so users will have to juggle around with their preferences.

Other than the limited filtering limit, Declarative Net Request can only redirect to static URLs, so there is no support included for pattern matching. uBlock Origin heavily relies on pattern matching, and the extension developer stated that it is not possible to retrofit his extension’s matching algorithm to meet the APIs requirement. The API would also require a complete extension update to simply update the filter list, which would be a far too frequent activity considering the frequency with which these filter lists are updated. Of course, these updates would also hinge on Google’s extension review criteria and processes.

On the other hand, Google has always maintained its stance that its intent to move away from Web Request is from a security perspective, as the Web Request API is too powerful in its current form and leaves open a very wide room for abuse. This abuse isn’t just theoretical, as Google has mentioned that 42% of malicious extensions have abused this API. Apple Safari’s Content Blocker API was designed like Declarative Net Request for similar reasons, as there is lesser room for a rogue developer to exploit. On the nerfed Web Request, network requests would still be observable, but they would need permissions on the relevant hosts. With Manifest V3, host permissions are also changing significantly and they can no longer be granted in a blanket manner at install time.

Google has also used performance overheads as a motivator for the switch. Evaluation of network requests occurs in the JavaScript thread of the extension, which can be costly on performance. As a rebuttal, uBlock Origin’s developer mentions that his extension does not incur any significant performance penalty even when having as many as 140,000 static filters to enforce. The costs incurred are claimed to be easily recovered by the resources that are prevented from being downloaded from remote servers and thus not processed by the browser.

Even though Google does not use this reasoning, one argument against Web Request can also be made for efficiency with ad blocking. With Web Request, if an extension does not respond in time (because of a lag or a crash), the network handling request is plainly allowed, which lets ads slip through the ad blocker. Declarative Net Request, on the other hand, would not suffer from this drawback. Instead, ads will pass through if they do not get caught within the static rules, and this will happen more often than not.

Conclusion

From the explanations above, it is clear that Declarative Net Request is not a 1:1 functionality clone for the blocking capabilities of the Web Request API, and extension developers are bound to be miffed when their hard work will get handicapped by such changes. But Google’s reasoning also carries weight — Web Request is too powerful, and its powers need to be curtailed in the larger interest of the user community (which comprises of average users along with enthusiasts).

The move towards Declarative Net Request could have been a positive PR move too — after all, Google is adding in a built-in content blocker API to Chrome! But since the new API comes with its own heavy restrictions, the community rightfully sees this as a clipping of their wings. In an ideal world, Google should have explored the working of ad blockers like uBlock Origin before pushing forth the new API. As it stands now, the new API could use further relaxations on its rule limits to accommodate scenarios where users would want to use two filter-heavy extensions.

According to The Register, the first builds with Manifest V3 changes will be available from July 2019 onwards. We hope Google accommodates the feedback received from the extension developer community with these builds.

The post Google’s Manifest V3 will change how ad blocking Chrome extensions work: Is it to cripple them, or is it for security? appeared first on xda-developers.