Manifest V3: The Ghostery Perspective

Manifest V3: The Ghostery Perspective

Internet privacy is a constantly evolving domain. New trackers and new tracking techniques are uncovered every day. By following our motto of "Tracking the trackers", Ghostery publishes the world’s largest trackers database, whotracks.me. By utilizing this powerful knowledge source, we augment the browsing experience by making the web transparent, fast and private.

Ghostery offers industry leading tracking protection

To maximize privacy protection, Ghostery incorporates various resources, techniques and algorithms to ensure industry leading tracking protection. We do rely on community maintained block lists, dynamic data-driven tracking protection algorithms, hand crafted compatibility lists and breakage-preventing heuristics. Ghostery adapts as needed and innovates to stay ahead of the tracking industry.

Manifest V3

There is a new risk for online privacy which prevents innovation in the privacy area and it comes from the most popular web browser around - Google Chrome. Starting January 2022, Google’s Manifest V3 will impose massive limitations on all new browser extensions. When Manifest V3 is coming out in January 2023, these restrictions will be enforced on all extensions, Ghostery included.

This blog post covers in detail a long list of changes that Manifest V3 imposes on the extensions platform, outlining how Ghostery plans to deal with these limitations and what drawbacks extension users will have to cope-with.

Does Manifest V3 help protect privacy?

Prepare for a gloomy read as nothing Manifest V3 introduces in its current state, can help protect privacy.
Extension developers and users should act firmly against it. At Ghostery we believe that in collaboration with browser developers, we'll find ways to improve the extensions platform, overcome the weaknesses of Manifest V3, and build a more private web in which WebExtensions continue to be the playing field for innovation and the express lane for browser enhancement.

TL;DR

With enforcement of Manifest V3, Google dramatically limits capabilities of browser extensions. It removes access to powerful APIs that allowed us to provide innovation in privacy protection. Being subjected to those constraints, we have to re-invent the way our extensions operate. Intended or not, Manifest V3 takes choice away from users, exposing them to new threats. Manifest V3 is ultimately user hostile.

Overview of Manifest V3 changes

‍To give a quick overview, Google's Manifest V3 affects Ghostery in the following ways:

• No access to the network layer
• declarativeNetRequest (DNR) instead of webRequest API
• Service workers instead of background page

The access to the network layer is for Ghostery the most critical feature of the current WebExtension platform. This functionality allows us to do the so called content blocking, utilised to block ads, trackers and other annoyances. Additionally, at Ghostery traffic inspection is used to track the trackers; we analyse them and neutralize leakage of unique identifiers. This is what we call Anti-Tracking, AI Tracking Protection or Dynamic Data-Driven Tracking protection.

In their Manifest V3 documentation, Google explains why they decided to remove blocking webRequest API:

The blocking version of the webRequest API is restricted to force-installed extensions in Manifest V3. This is because of issues with the blocking webRequest approach:

Blocking webRequest approach

What are the issues?

• Privacy: This requires excessive access to user data, because extensions need to read each network request made for the user.
• Performance: Serializing & deserializing data across multiple process hops & the C++/JS boundary adds up.
• Compatibility: Does not work well with event-based background execution as it requires the service worker to be running to handle every request.

The above means that developers can implement many common use cases, such as content blocking functionality, without requiring any host permissions.

The last point in the list, compatibility is a result of replacing background scripts by service workers - a problem introduced with Manifest V3. Let's focus on the first two points, which are the most interesting.

Implications on privacy

Some of the changes in Manifest V3, like forbidding arbitrary code execution (loaded from the server), are reasonable - both from a security and privacy standpoint. Yet the argument that privacy can be further improved by removing blocking webRequest is questionable.

The concern is that malicious extensions can use it to steal user data. This is correct, but it is a fallacy that removing blocking webRequest will solve the underlying problem; WebExtensions retain access to sensitive information, for example, by using the content script API.

There is no silver bullet to protect against malicious extensions. To build trust, the source code of WebExtensions needs to be manually reviewed; unfortunately, there is no existing tool to automate that. What we can do as extension developers is to open-source all client code.

Implications on performance

‍At a first glance, it is convincing that replacing the webRequest API by a native implementation will improve performance by avoiding context switches between the JavaScript threads and the network thread. Yet the underlying assumption that code run by extensions must lead to significant overhead is flawed: it overlooks that modern ad blocking engines are highly optimized.
In 2019, Ghostery published the Adblockers Perfomance Study, where we show that the overhead is in the sub-millisecond range. In other words, Google's Manifest V3 is trying to solve a performance issue that does not exist. Of course, there are WebExtensions that will slow down the browser, but that alone does not justify removing APIs for all other WebExtensions.

What is wrong with Manifest V3?

Beware, following are dragons of technical nuances and dirty tricks to counteract imposed limitations - skip to the conclusion if you are not into it:

No access to the network layer

Manifest V3 completely removes the so called blocking webRequest API which enables us to do all mentioned above.  Content blocking is meant to be achievable by the new declarativeNetRequest (aka DNR) API, which we will cover in detail in the next point. But there is no replacement for other use cases that blocking webRequest supported.
Without webRequest, our abilities to track trackers and block leakage of unique identifiers are being restricted.

The question is how to compensate for the loss of the blocking webRequest API in Ghostery?

• Through using declarativeNetRequest

Recently released Ghostery for Safari implements content blocking via DNR. Thanks to the experience gained on the Apple platform, Ghostery developers are better prepared for the limitations coming to Chromium based browsers under Manifest V3.

Our workaround and its drawbacks: declarativeNetRequest is not as powerful as our content blockers. We will report bugs and feature requests for all browsers until they will reach feature parity with the solution we already have (browser developers have a lot of work to catch up)

• Reimplement Anti-Tracking feature by monkey patching browser APIs from the content scripts

Read the explanation on how Ghostery Anti-Tracking works and how Manifest V3 renders its current implementation unusable on the public issue tracker of W3C WebExtentions Community Group here.

Our workaround and its drawbacks: monkey patching means that we are going to replace browser's build-in APIs like fetch to send the contents of their calls to the service worker via content script. This additional communication results in delays (it turns out that delaying requests that are likely from trackers bring benefits; but that is a topic for a separate blog post).

Monkey patching comes with a risk of site breakage as other WebExtensions and/or the site itself may choose to modify same APIs, possibly leading to bugs if the changes are incompatible. This technique, being very powerful has to be used with special care.

• Keep the current content blocking engine (not for blocking but for cosmetic filters)

declarativeNetRequest only allows request blocking, but cannot handle cosmetic filters (injecting CSS to improve page layouts if ads are blocked). Thus, the content blocking engine is still needed to fill that gap. More about it in the next section.

Our workaround and its drawbacks loading the content blocking engine in the service worker has costs, most notably CPU costs. On mobile devices, that can negatively impact battery performance.

declarativeNetRequest

declarativeNetRequest API is designed as a drop-in replacement for blocking webRequest in the respect of content blocking. It was inspired by Safari's Content Blocking API, but the new design is less powerful then Apple's API. Compared to the webRequest API, it lacks the capabilities to inspect and modify requests.

It is uncertain whether the DNR API in its current form will outperform state-of-the-art adblockers. Expressing the rules in declarative format might introduce hidden abstraction costs: some of the optimizations that went into specialized adblocker engines might be hard to replicate in the browser, as the browser can make fewer assumptions. Perhaps native implementations will be able to outperform today's adblocking engines, but not be a high margin. In return, native implementation will sacrifice flexibility, which means some features of today's ad blockers will no longer be supported.

So, how do the limitations of the new API affect the Ghostery extension? We identified the following areas:

• no incremental updates - at Ghostery, we publish updates to our ad blocking list daily. Yet Manifest V3, which was designed to reduce extension review times, would force us to release a new extension version each time we update the block list. Some updates are allowed in a form of dynamicRules, but the number of entries is limited to 5,000 and it has to be shared with user controls, which makes it unusable.

Our workaround and its drawbacks: Manifest V3's idea was to simplify WebExtensions to speed up the review process. We will put that to test - we plan to release updates to our extension as often as needed, every single day if required. We hope that reviewers will be able to keep up with it.

• no granular control - Ghostery users can overwrite the defaults by blocking or unblocking individual trackers, whole categories, or any subset associated to the trackers list. These choices can be made globally, but also for specific pages. With 5,000 dynamicRules we will be able to offer some customization, but not as much as we can offer now. Features like trusting or restricting individual websites may be limited or impossible.

Our workaround and its drawbacks: Ghostery will not be able to provide much control. The recently published Ghostery for Safari based on declarativeNetRequest offers only turning off entire block lists. (More details on this in the following paragraph)

• active block list limit - enabling gradual control will be impossible, so toggling individual categories of trackers, for instance blocking social widgets, site analytics or consent forms could be options. And yes, you can achieve it with DNR, but there is a limit of 10 block lists enabled at the same time. Yet Ghostery has 14 categories for now, and planning to introduce more as the tracking industry is constantly changing.

Our workaround and its drawbacks: we will have to merge related block lists until getting down to 10 (e.g., merging Advertising with Porn Advertising or Hosting with CDN). Note that this tactic will not benefit the user, but only complies with the new constraint of 10 lists.

• competition on the global limit - Today, users can install Ghostery together with other content blockers like uBlock Origin and both extensions will work fine. In Manifest V3, there is global limit of rules that is shared between all extensions. So, if multiple content blockers are installed in the same browser, some of them (and there is no way to tell which ones), will not work as expected. Extension developers will have to handle that situation and explain to their user base the necessity of disabling one content blocker in favour of the other to work correctly. There is a guaranteed minimum set of 30k rules, but it is not enough. In Ghostery, we need a minimum of 60k rules; a number which does not even cover many region specific trackers.

Our workaround and its drawbacks: We will be polite, informative and transparent. Many hours will be spent  implementing new interfaces and crafting in-extension messages so our users can understand what is happening. We really do hope other extension developers will have enough resources and patience to do the same.

• introspection limit - Ghostery's mission is not only to block tracking but also to visualize tracker's activity. We are able to identify thousands of trackers, and let the user decide upon their treatment. DNR provides feedback on which of the rules have triggered, to learn which trackers were blocked. But there is a limit to how often WebExtentions can request such information from the browser; this limit is set to 20 times per minute. That means if you try to open the Ghostery Panel, more than 20 times in 10 minutes, we cannot show any data! To get the data, users will have to make an additional click. Our feature Tracker-Tally, which shows trackers while they load on the page, will not be possible as it would require users to click on it constantly.

Our workaround and its drawback Tracker-Tally has a due date. Also, the Ghostery popup UI needs to be adjusted, as additional interactions will be required. The user experience will decrement, and extension developers will have to explain that it comes from browser limitation. Our fear is that some users will have no open ear for our excuses.

• no protection against zero-day privacy attacks - declarativeNetRequest is declarative, based on block lists, but these are typically built by communities in a process requiring consensus, which makes it quite slow. Additionally, with Manifest V3 an extension update is required for updating the block lists. There is no way to react on time.

Our workaround and its drawbacks: Ghostery will use dynamicRules limit to its maximum. If monkey-patching of browser APIs (see next point) will work well, we will try to use it to block those requests that we know are a threat but are not in block lists yet. How will extension reviewers react to over-the-air updates to block lists? Hard to tell.

• no dynamic tracking protection - this is perhaps the most impactful assault on users' privacy. At Ghostery we are proud of our dynamic, data-driven tracking protection. This anti-tracking technology does not block the requests but modifies parts of them to remove unique identifiers. DNR by nature cannot offer such protection as its block lists are fixed, they cannot adapt to the trackers' conduct, and it is very common that well functioning trackers behave erratically on a regular basis.

Our workaround and its drawbacks: We're currently running experiments by intercepting requests before they are being initiated; we do this by monkey-patching browser APIs like fetch. As already mentioned, that technique comes with the risk of breaking sites. It brings back the required capabilities of the webRequest API - inspecting and modifying requests, - but in a inferior way. Still, this experiment is worth the effort to protect our user's privacy. Be sure to read more about this in upcoming blog posts.

• no cosmetic filters - a detail for some, a deal breaker for others. Once an ad is blocked, some websites show empty space that was reserved for ads. This makes those websites look defect. Cosmetic filters are little pieces of CSS that we inject into websites to remove such blank spaces; it improves the layout of the website to function without ads. DNR does not provide cosmetic filter injection. Interestingly, the Safari Content Blocker - the inspiration for the DNR API - has this feature.

Our workaround and its drawbacks: We will run them in the service worker. They will have to load from scratch approximately every five minutes; and sometimes they will fail (depending on how eager browser developers will be in respecting message passing API to resume the service worker).

Service workers

Service workers are the new execution environment for background processes of web extensions in Manifest V3. They existed before Manifest V3 and were originally designed to help websites deal with caching and push notifications. Why they are used for extensions? Frankly, we have no clue. Yet, we have identified a number of issues with them:

• no workers, no web assembly - At Ghostery, we have optimized our extension to its limits. We are very careful to have as little blocking computation on the background run-loop as possible. This explains our speed even if we use blocking webRequest. Yet some operations that are already optimized are still expensive, for instance, the cryptographic operations for securing the communication with our server. To prevent blocking the background run-loop, these operations are offloaded to a web worker. Also, the implementation uses Web Assembly (WASM) to boost performance. But service workers do not allow to start another worker or use WASM.

Our workaround and its drawbacks: There are some interesting new APIs like chrome.storage.session which were specifically designed to overcome some of Manifest V3's limitations. The new Alerts API can be used to defer heavy tasks in the service worker. Regarding the lack of WASM, there is no obvious solution. Falling back to asm.js - which has been largely replaced by WASM - is possible, but it is slow. It is also important to stress that performance is not the only reason why WebExtensions use WASM: it is also used for non-JavaScript code, e.g. libraries.

• ephemeral model - another aspect of service workers is that they are ephemeral: the browser kills them every now and then. That is how Manifest V3 planned to improve browser performance: by stopping long running background threads to save memory. Sounds great on paper, but there is a catch: everything that was killed has to be started anew whenever the service worker is resumed. Those bootstrapping efforts can be significant, specifically on devices with less powerful hardware. Dealing with JSON data is particularly unpleasant as data has to be fetched and parsed every few minutes. Parsing is a blocking operation, and bigger files - very common in privacy extensions - can block the run-loop for a significant amount of time. End-users will notice this when the browser starts lagging. In Manifest V2, many extensions are optimized to use in-memory caches to boost performance. In the context of Manifest V3, these caches will be constantly purged, as service workers are short-lived. Losing the potential to trade memory for CPU in order might also increase battery usage on mobile devices. Here we see again how Manifest V3 fails to deliver on its guiding principle of improve performance.

Our workaround and its drawbacks: Fortunately, Ghostery is in a better situation than others: we moved away from storing data in JSON years ago. Instead, we switched to binary data structures where it makes sense. Apart from speeding up parsing, it only requires a single allocation. We use this technique for our ad blocker engines and for the anti-tracking bloom filters. Some other extensions would need to invest to get a similar level of optimization.
   
Reconsidering the ephemeral model would also be a step towards the needs of extension developers. Since the execution can be killed at any point, it forces the use of extra persistence layers. Migrating from background scripts to service workers leads to accidental complexity.

• no access to DOM API - another technical limitation of service workers is lack of access to the DOM API. That means, whenever the extension has to parse HTML, it has to fall back to an external library that emulates the browser's native implementation. These libraries are great, but not always 100% compatible with browser engines; that can result in unexpected errors. Since they are also written in JavaScript, they are slower then the browser's tuned native implementation. Shipping an extra library will also increase the size of the extension. Since losing the ability for incremental updates will force us to move to shorter release intervals - over time, these downloads will add up and can become a problem on metered connections.

Our workaround and its drawbacks:  Not much can be done about it except choosing the best DOM library.

• no JavaScript modules - it is 2021 and Service Workers still don't support JavaScript modules. On top, only a single script can be specified in the manifest. Loading additional files requires extensions to use importScript API, which does not support JavaScript modules. That makes development of sophisticated WebExtensions harder than it should be. JavaScript bundlers are almost required, so the platform is getting even harder for newcomers to approach.

Our workaround and its drawbacks: We write JavaScript like in 1999. And to share code between platforms we need to resort to dirty tricks. Check our DNR based extension code to learn more.

What does this all mean for users?

Manifest V3 is an opinionated specification; it enforces technical limitations with the goal of improving user experience. That looks good on paper, but the reality is quite different.

Manifest V3 introduces more harm than good and this blog post outlines only Ghostery’s perspective.
A brief visit to Chromium Extension User Group reveals that all browser extension developers are in a similar situation.

Privacy protection is getting tougher as a result of changes introduced by Manifest V3. We are forced to rewrite our extensions, due to losing access to APIs that helped us protect users' privacy. Intended or not, Manifest V3 is working against privacy protection. We are committed to finding new ways to continue our mission but the cost is huge.

The future is not pretty, but we have to prevail.

The bigger picture

Google as the owner of a dominant web browser has almost uncontrollable power to shape the web platform. When Manifest V3 was first introduced as a proposal in 2018, some of us hoped there will be a way to influence its design. In 2022, Manifest V3 will land in a form that is almost identical to its original draft. Was it the community failing to provide feedback, or was it something else? We will never know. The truth is that Chrome forces all new WebExtensions to follow Manifest V3 starting January 2022.

But how do other browser vendors look at this, and will they follow?

June 2021 offered a bit of bright light in our story when a new W3C Community Group for Web Extensions (WECG) was formed by Google (chair), Apple (chair), Mozilla and Microsoft. The group aims to identify differences in the extension platforms across browser vendors, document them, and prepare for further standarization by the W3C bodies. It is a first site that was able to gather all major browser vendors to talk about the extension platform. It became even more significant as in September 2021, Safari has implemented WebExtensions on all it platforms (macOS, iOS, iPadOS).

Ghostery takes an active role in WECG by joining bi-weekly meetings and filling in issues on a public GitHub repository.

We deeply hope that together with a wider extension community we can document how Manifest V3 is restricting us in protecting privacy, so that we can influence all browser vendors to make choices with respect to our goal.

Let's discuss stances of different browser vendors:

• Mozilla - representatives are very active at WECG and this is very much appreciated by the community. Their focus is more on compatibility. For instance, by keeping the blocking ability of the webRequest API but also adding the DNR API, it is easier for Firefox extensions to migrate to Manifest V3 without the downsides. Thus, Mozilla will not have to support multiple manifest versions. They recognize that Manifest V3 is unsuitable for many use cases of extensions. Regarding Manifest V2, Mozilla stated they have currently no plans to deprecate it any time soon. They are working on their own implementation of Manifest V3; to understand its limitation, but also to play an active role in its development.

By continuing to support Manifest V2 even when Google stopped it, Mozilla may expect to see quite an exodus of users quitting Chrome in favor of Firefox; the effect will depend on how popular WebExtensions will work on Manifest V3. We hope that Mozilla, with its tradition to value users' privacy, will continue play a main role in the development of WebExtension platform in scope of Manifest V3 and beyond.

• Apple - something exciting has been happening in the past years. Apple - with a history of being a closed ecosystem - decided to implement WebExtensions in Safari. First introduced on macOS in 2020, and later on iOS and iPadOS in 2021, it made Apple the first Big Tech to offer extensions on all platforms (neither Google, Microsoft nor Samsung support extensions on mobile). The way Apple has approached it is also quite unique. In some sense, Apple implemented Manifest 2.5 - they have kept background pages but made them ephemeral; they have implemented DNR (which only makes sense as behind the scene it runs the regular Safari Content Blocker). At this stage, Apple's extension platform is still full of bugs. Yet anyone who understands how complex this is, can appreciate the enormous effort that was put into it. At Ghostery, we definitely are big fans of this new development. We wish to contribute in making the Safari browser a better host for all WebExtensions.

If there is anything more we would like Apple to look into is to recognize the importance of persisted background pages (or other execution contexts) on mobile platforms where battery life is of essence.

• Chromium forks - according to our knowledge Microsoft, Brave, Opera - have not expressed much concern on Manifest V3 yet. Being Chromium forks with own agendas, they may not be very interested in the future of the WebExtension platform. Also because they tend to offer many features provided by extensions, natively in their browsers. At Ghostery, we believe this is fine and we do the same (with a muuuuch smaller budget) by running our own Firefox fork - Ghostery Private Browser. Browser forks, all alike fight for recognition. Ghostery Private Browser implements many of its features as built-in WebExtension. Other browser forks implement their features in native code. Both approaches work well as we all try to innovate and distinguish ourselves from the other.

‍