The manifest is used by browser extensions to declare what permissions an extension requires, and is associated with a set of APIs through which the code can interact with web pages. Extensions are able to read and modify the content of the page, giving them high capability but also introducing privacy and security risks, in the case where a user installs a malicious or compromised extension.
In early 2019, Google came up with a proposal to make extensions safer but at the expense of some reduction in capability. In particular, the webRequest API, which lets the extension view, modify or block browser requests, is being deprecated in favour of a new and less powerful Declarative Net Request API. A common use for webRequest is ad blocking, but there are many other use cases. It is a difficult matter as while Google is correct in stating that extensions can abuse webRequest, there are also suspicions that the company is keen to keep ads flowing because its business depends on it. We reported last year on a Google financial filing which highlighted ad-blocking technology as a threat that "could adversely affect our operating results."
Google relents slightly in ad-blocker crackdown – for paid-up enterprise Chrome users, everyone else not so much
Despite this, Google said in June 2019 that weakening ad blockers "is absolutely not the goal." The company also clarified that webRequest would remain as an observational API and that blocking, curiously, "will still be available to enterprise deployments."The current state of play is that Manifest V3 remains "in active development" and Google has said: "We have not decided on a final end of life date for Manifest V2." Microsoft could potentially have made support for the more powerful webRequest API a distinctive feature of Edge; and some users begged for it to do so, saying: "Please, please don't remove/change/limit this API." Those appeals appear not to have been heeded. In a new post, the Microsoft Edge team said: "We plan to support the Declarative Net Request API and other changes proposed as part of Manifest V3." Further, the documentation states: "We're replacing Web Request API with Declarative Net Request API, but will continue to keep Web Request API’s observational capabilities."
Manifest v3 is already supported in the Edge stable release, but no timeline has been given for neutering webRequest, with the company saying, "Once the changes are finalized in Chromium, we will share an update on our timelines." According to Microsoft: "After an extensive review of the concerns raised by content blockers and the community, we believe that a majority of those concerns have been resolved or will be resolved before Web Request API is deprecated."
Chromium developer advocate Simeon Vincent confirmed that the first preview would be available for the Google developer Canary channel in late July or start of August. Microsoft is currently asking users whether they want built in ad blockers, while Brave has already said it won’t be taking on the Manifest V3 changes.
There is of course wriggle room in "will be resolved" but there is no evidence that the community is equally confident.
Author of the uBlock Origin extension, Raymond Hill, told The Register that Microsoft (and Google's) claim that the changes improve privacy is false. "They are not deprecating the Web Request API, they are deprecating the *blocking ability* of the Web Request API – specifically, the 'webRequestBlocking' permission. The Web Request API will still be available and still be able to provide information about all network requests fired by the browser … as opposed to what those announcements state, the deprecation of the blocking ability of the webRequest API accomplishes nothing privacy-wise for content blockers since they will *still* require broad hosts permissions." Hill said that other features such as run-time host permissions (RTHP) and forbidding remote code execution (RCE) are more effective for protecting privacy, but that these are not done with Manifest v3, since RTHP is a browser feature and forbidding RCE "is a store policy issue, not an API one … those Manifest v3 announcements improperly attribute virtues (RTHP and no-RCE) to Manifest v3 which are technically unrelated to Manifest v3."
Google has begun testing their upcoming extension manifest V3 in the the latest Chrome Canary build, and with this initial 'alpha' release, developers can begin testing their extensions under the upcoming specification.Error when using unsupported APIs If you switch the extension to use a service_worker instead then the extension loads properly into Google Chrome.
Hill also quoted the EFF report, which said that "the next time Google [or Microsoft] claims that Manifest V3 will be better for user privacy and security, don’t believe their hype … Manifest V3 will curtail innovation and hurt the privacy and security of Chrome users." Microsoft's Edge has a tiny market share relative to Chrome, and its web advertising business is also tiny relative to that of Google, but it does have an advertising service and is therefore vulnerable to the same suspicion that it may want to protect this. That said, enterprise security is also top of mind for the company, so this may be as much to do with privacy, security and performance, the stated reasons.
Even with Microsoft and Google on the same page with regard to Manifest v3, users will have plenty of other options. Mozilla has a FAQ on the subject and states that "Firefox is not obligated to implement every part of v3" and that it has "no immediate plans to remove blocking webRequest." That said, the Firefox company adds that it is "waiting for more clarity and has begun investigating the effort needed to adapt." It is also possible for browsers to implement content-blocking technology that works outside of the extension API.®