Google קבוצות Re: [crx] Re: Manifest V3: Web Request Changes Daniel Glazman 23:52 22/01/2019 Extensions Chromium :פורסם בקבוצה > Le 23 janv. 2019 à 08:29, Giorgio Maone <[email protected]> a écrit : > > The author of NoScript here. > I'm in the final stages of a project in the making for more than one year and lots of research / resources now: porting the NoScript Security Suite add-on to Chromium. > Removing the webRequest API (which on Chromium is already severely limiting because it lacks the asynchronous mode offered by Firefox) would jeopardize the entire effort, because it would make very difficult if not impossible reliable script blocking and other features, implemented by adding CSP headers and other fine-grained manipulation of the requests. > What I do propose is keeping both the APIs (possibly making webRequest asynchronous like in Firefox, which could also mitigate some of the perceived performance concerns and allow for more flexibility) but advertise the performance and potential privacy trade-off, if any, on installation through the permissions system. Let me follow up on one point that was almost not discussed before: WebExtensions are in 2018 a cross-browser API. We, extension authors, heavily rely on the fact it's more or less implemented in the same way in both Chrome and Firefox. The v3 proposed changes are clearly going to make WebExtension support in Chrome and Firefox diverge quite deeply, and that's a VERY bad signal sent to extension authors and to the Open Web: 1. background pages replaced by ServiceWorkers (holy cow, that alone would imply months of work for us) 2. restrictions on <all_urls> 3. webRequest changes 4. browserAction and pageAction merge (while Firefox preserves both and allows both in the same extension) 5. deprecated but heavily used API that will be removed 6. i18n.getMessage would be changed or removed Seriously guys, have you really evaluated/studied the impact on us implementors?!? Furthermore, the WebExtension API is not managed like a Web Standard. The standardization effort initiated by Microsoft in a W3C Community Group ended up miserably and almost everything that makes the Open Web Platform stable and reliable is absent from WebExtensions: - a Web Standard - API stability - frozen API - open upgrade process discussed between browser vendors and implementors - API reaching a Standard level when there are TWO interoperable shipped implementations - prospective approach of the impact of ANY change on implementors based on usage metrics - lack of API giving controlled access to the device ("à la" FirefoxOS) In the recent years, Mozilla severely harmed its addons ecosystem that triggered its massive adoption back in 2003-2007 and the result is immediately visible: less powerful addons, tightened ecosystem, less innovation. In the recent years, Safari moved away from extensions based on Web standards too; the result was immediate too: an anemic (I could say dying) addons ecosystem, implementors moving away from Safari. Is Google seriously going to follow that path too, harming hundreds of third-party implementors that are an important part of the richness of its browser environment? I urge Google to resurrect a real and active Standardization effort around WebExtensions. This is the *only* part of the Browser space that is not handled that way, and we clearly see today with the v3 proposal that it is not workable for third-party implementors any more. We just cannot cope with deep changes of high magnitude in a timely manner. The financial impact of the proposed changed on extension vendors is vastly underestimated (if estimated at all), and that alone should be a showstopper signal from a strategic point of view. </Daniel> -- Privowny, Co-CTO & Vice-President Engineering .