Google bringing a new version of Manifest, namely V3, marks a turning point in how browser extensions are developed and operated. For those unaware, every Chrome extension must have a manifest.json file responsible for listing important information about how that extension is structured and how it behaves.
Before this new Manifest V3, Chrome extensions worked under Manifest V2. This old version gave developers more freedom in how they interacted with the browser and user data. For example, extensions could run persistent background pages or manipulate network requests through the ‘webRequest’ API.
This is flexibility at its core, giving devs the power to make unique extensions suited to Chrome. However, this came at the cost of performance and security issues, and Manifest V3 was brought forward to combat this. While this update promises to offer better security and enhanced resource usage, extension developers might be faced with a crossroads.
The Future of Chrome Proxy Extensions in the Manifest V3 Era
Chrome’s Manifest V3 brings about two key changes: the first is that service workers that are active when needed have replaced long-lived background pages and the second is that the ‘webRequest’ API has been replaced by the ‘declarativeNetRequest’ API. These have made changes to how proxy extensions work in the browser, and impose specific limitations for developers and users alike.
Previously, proxy extensions used webRequest to intercept and modify network requests on the fly, which made proxies do what they were developed to do: change networks and make custom configurations. However, the new API under Manifest V3 now requires extensions to declare rules upfront for how they plan on handling network requests.
Instead of the proxy extension deciding this while it works under specific configurations, the browser would now be in control of the situation. This approach revolving around the browser’s decisions is more secure but at the steep cost of flexibility and functionality of Chrome proxy extensions.
As a matter of fact, some Proxy extensions also need to be authenticated before being used, and this was done with a combination of webRequest and webRequestBlocking APIs, which are now deprecated.
More from Tech
- Yonder Launches Premium Rewards Debit Cards To Help More People Earn Meaningful Rewards
- Tech Used for Safety and Crowd Management at Festivals
- Top Test Case Management Tools for QA Teams
- How Can Natural Language Processing Enhance CRM Interactions?
- We’ve Heard Of VR And AR, But What Is Synthetic Reality?
- Green Tech Used To Reduce Waste At Music Festivals
- Experts Comment: Are We Allowing Tech To Over-Optimise Our Lives?
- Solving Blockchain’s Real-World Enterprise Challenges with Institutional Adoption
The End of Web Request API: What It Means for Proxy Extensions
We touched on the webRequest API that was widely in use by proxy extensions, but let’s further explore how it worked and the impact it had. Using this API, extensions gained the ability to intercept network requests in real-time, meaning any proxy extension you downloaded on Chrome would be able to examine the content of incoming traffic and modify it as needed.
This capability powered proxies to route traffic dynamically and enforce security policies. So in the past, Chrome sent all data to the listening extension, and then the extension evaluated the request and gave the browser orders.
But now with the end of webRequest, the new API set to replace it requires that extensions inform Chrome of network rules beforehand. For example, if a certain type of request is seen then a specific action is performed. Chrome now handles requests according to the set rules instead of giving the extension free reign.
How Developers Are Adapting to Manifest V3
As Chrome transitions to Manifest V3, developers of proxy and other extensions face the challenge of making their work compatible with the latest builds. One critical area is that the architecture must be redesigned, especially with tasks related to new service worker implementations.
The manifest.json file would also need to be updated, reflecting the new structure and permissions of the extension. Specifically for proxies, developers would need to find ways to dynamically route by giving a ruling list to Chrome and allowing users to toggle these on or off depending on need.
Google has listened to community feedback with this new update and even put it off for later after developers raised concerns.
The Most Common Question: Is Manifest V3 an Upgrade or a Restriction?
Manifest V3 has sparked a debate, where people find themselves questioning the balance between privacy and functionality. Google has been an advocate for this, pushing the notion of enhanced privacy and security upgrades, but critics argue that this would limit the capability of what’s possible to achieve with extensions.
The new upgrade is set to impose strict rules, and functionality restrictions including limiting filter lists, and lowers the effectiveness of privacy extensions and ad blockers. These are important for many people, who choose to turn them on while browsing in Chrome.
Currently, there is a divide within the community over this matter and we’ll have to wait and see how Google responds. One thing to acknowledge is that the issue is significant for both parties—developers and ordinary internet users but from different angles. Therefore, understanding both concerns and perspectives will be equally crucial for the company to enhance the functionality and the nature of the technology in the future.
