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.
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.
But 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. 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.
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.
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.
To give a quick overview, Google's Manifest V3 affects Ghostery in the following ways:
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:
* 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.
This means that developers can implement many common use cases, such as content blocking functionality, without requiring any host permissions.
The last point (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.
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.
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.
Let's talk about what is wrong (beware, following are dragons of technical nuances and dirty tricks to counteract imposed limitations - skip to the conclusion if you are not into it):
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?
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)
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.
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` 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:
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.
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)
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.
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.
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.
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.
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.
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 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:
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.
Our workaround and its drawbacks: Not much can be done about it except choosing the best DOM library.
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.
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:
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.
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.
Manifest V3 is a detrimental step back for internet privacy.
Instead of reinventing the wheel, we would prefer to focus on finding new ways to prevent tracking. This is after all what browser extensions are and should be, a playing field for innovation and the express lane for browser enhancement.