Chrome Extension Manifest V3 Migration: A New Era of Chrome Extensions Begin!

1. Enhanced Security

With businesses speeding up the Manifest V3 migration for their extensions, the number of fraudulent and malicious extensions actively listed on the Chrome web store is expected to observe a promising drop. Google updated the ‘declarativeNetRequest’ API alongside manifest.json file as a feature that replaced the old ‘webRequest’ API that allowed extensions to interfere and alter network requests made by websites. With Manifest V3 a new rule-based approach was established for websites which limits the authority of extensions to modify a network request. Allowing the extensions and browsers to operate within the pre-established guidelines makes the entire experience feel secure.

2. Better Performance

Manifest V3 migration for Chrome extensions allow browsers to perform more optimally by using ‘declarativeNetRequest’ and ‘chrome.action’ APIs to manage and process multiple network modification requests more effectively. This allows the browser to save time on each request, speeding up various operations for the browser.

Previously background pages were used to handle these operations. But the major issue there was the fact that it had to run a code that was required to execute continuously. And, this code shared the same memory that the extension was using. However, Google announced the service worker model which runs in a different process, allowing the extension to operate freely. This further enhanced the performance of the extension and the browser altogether.

3. Better Compatibility

Manifest V3 extensions are built to establish a more consistent user & developer experience across all browsers. This was made possible by the use of the ‘webExtensions’ API which is compatible with most of the popular browsers and allows the developers to build the extensions for them using a common set of APIs. This solves one of its predecessor’s primary issues, Manifest V2 extensions had slight inconsistencies and variations when it came to being used in different browsers. This forced the developers to make alterations to the code every time they wanted to add a new browser to the extension’s roster.

Additionally, we can’t expect browsers to remain the same forever right? As the web standards & guidelines continue to evolve with time, so will the architectures and security measures of the browser. If these standards are not maintained, your extensions stand at the risk of being removed from the store completely. Fortunately, Manifest V3 was developed keeping these concerns into account, this makes extensions that follow its guidelines relevant even after any basic changes in the near future.

4. Increased Controllability

Migrating to Manifest V3 provides your extension the ability to follow a model which is similar to an event-driven architecture. Now the advantage of having this architecture is that it provides in-depth control over how the extension interacts with the browsers. Service worker models play a major part in implementing the event-driven programming model for Manifest V3.

In addition, the ‘declarativeNetRequest’ API provides the users with extra controllability over the modifications an extension makes to a browser. The extension developers are asked to justify their requirements for every sensitive permission which is analyzed by the browser platform. This puts the browser back on the driver’s seat allowing them to take control of the changes, instead of the overruling extensions.

(a) Updating the Manifest

The initial step while migrating your extension to Manifest V3 would be to make a few important changes to the manifest file of your extension. Here are the key changes you need to make - 

1. Update the Manifest version field from V2 to V3
2. Mention ‘host_permissions” as a separate field
3. Modify the “web_accessible_resources” field

(b) Migrating to a Service Worker

One of the major performance enhancements during Manifest V3 migration is the switching of background pages into service worker models. These models execute the background code in a different location, providing the entire memory to the browsers. It also enables offline usability for the extension up to some extent. Here’s how we implement these service models, we - 

1. Replace “background.scripts” with “background.service_worker”
2. Implement offscreen API supports for DOM and window objects
3. Change the web platform’s storage mechanism to something relevant
4. Move the event listener script to the top level of your script
5. Switch “XMLHttpRequest()” with “global fetch()”
6. Use Storage APIs, Alarm APIs, etc according to the needs of the extension

(c) Updating the API Calls

During Chrome extension Manifest V3 migration there are a significant number of APIs that need to be replaced. Either because there is a better alternative available for them, or they are simply not supported in the newer version of Manifest anymore. Let’s go over these API changes briefly - 

1. “chrome.tabs.executeScript()” replaced with “chrome.scripting.executeScript()”
2. “tabs.insertCSS()” & “tabs.removeCSS()” replaced with “scripting.insertCSS()” & “scripting.removeCSS()”
3. Browser Actions & Page Actions are replaced with Actions
4. We implement calls like “postMessage()” & message event handler to ensure your extension scripts use message passing for establishing a connection between service workers and other parts of the extension.
5. Finally, we remove the APIs that are not compatible with Manifest V3

For more details, check out what Chrome Developers have to say about - Updating API calls

(c) Replacing the Old Content Blockers

With the “declarativeNetRequest” API the extensions are able to make reasonable changes to the browser or block unwanted content without accessing any sensitive user data. This significantly improves the security standards & performance, reflecting a positive user experience. Here’s a quick look at how we upgrade the old content blockers, we -

1. Make necessary changes to the “permissions” field in your manifest.json
2. Add a “declarative_net_request” object and establish a set of rules using “rule_resource”

Here are a few common use cases where “declarative_net_request” is used to block unwanted resources from accessing your browser/ personal data -

1. Blocking a single URL
2. Redirect multiple URLs at once
3. Block cookies for websites that are not visited very often

(d) Implement the Modern Security Protocols

When it comes to improving security protocols, Manifest V3 has really elevated the standards by a promising amount. It introduces a few operational and policy changes that make using extensions of this newer generation much safer. Here’s how we update the security guidelines for Manifest V3 - 

1. Execution of external logic & arbitrary strings is prohibited
2. Remotely-hosted files are restricted, all the logic being used must be a part of the extension package
3. The “content_security_policy” is updated
4. Outdated content security policies are removed