By glazou on Wednesday 23 January 2019, 11:47 - Standards - Permalink

The Open Web Platform is a careful and fragile construction billions of people, including millions of implementors rely on. HTML, CSS, JavaScript, the Document Object Model, the Web API and more are all standardized one way or another; that means vendors and stakeholders gather around a table to discuss all changes and that these changes must pass quality and/or availability criteria to be considered "shippable".

One notable absent from the list of Web Standards is WebExtensions. WebExtensions are the generalized name of Google Chrome Extensions that became mainstream when Google achieved dominance over the desktop browser market and when Mozilla abandoned its own, and much more powerful, addons system based on XUL and privileged scripts.

As a reminder, the WebExtension API allows coders to implement extensions to the browser based on:

HTML/CSS/JS for each and every dialog created by the extension, including the ones "integrated" into the browser's UI

a dual model with "background scripts" with more privileges than "content scripts" that get added to visited web pages

a new API (the WebExtension API) that offers - and rather strictly controls - access to information that is not otherwise reachable from JavaScript

a permissions model that declare what part of the aforementioned API the extension uses and which remote URLs the embedded scripts can access

a URL model that puts everything in the extension under a chrome-extension:// URL

URL a review process (on the Google Chrome Extension store) supposed to block harmful codes and more

A while ago, at a time Microsoft still had its own rendering engine, it initiated a Community Group on WebExtensions at the World Wide Web Consortium (W3C). With members from most browser vendors plus a few others, this seemed to be a very positive move not only for implementors but also for users.

But unfortunately, that effort went nowhere. Lack of commitment from other browser vendors and in particular Google, Microsoft abandoning its own rendering engine, lax Community Group instead of a formal W3C Working Group, the WebExtension draft specification has been in limbos for a while now and WebExtensions clearly remain the poor parent of Web Standards even if most people have at least one browser extension installed (usually some sort of ad-blocker).

Today, Google is impulsing a deep change in its WebExtension model:

Background HTML pages will be deprecated in favor of ServiceWorkers. That change alone will imply a complete rearchitecture of existing extensions and will also impact their ability to create and deal with the dialogs their UX model requires.

The webRequest API that billions of users activate on a daily basis to block advertisement, trackers or undesirable content, is at stake and should be replaced by a declarartive new API that will not allow to monitor the requested resources any more. At a time the advertisement model on the Web is harmed by ad blockers, one can only wonder if this change is triggered only by technical considerations or if ad strategy is also behind it... Furthermore, it will be limited to a few dozens of thousands of declarations, which is far below the number of trackers and advertisement scripts available in the wild today.

API that billions of users activate on a daily basis to block advertisement, trackers or undesirable content, is at stake and should be replaced by a declarartive new API that will not allow to monitor the requested resources any more. At a time the advertisement model on the Web is harmed by ad blockers, one can only wonder if this change is triggered only by technical considerations or if ad strategy is also behind it... Furthermore, it will be limited to a few dozens of thousands of declarations, which is far below the number of trackers and advertisement scripts available in the wild today. Some heavily used API will be removed, without consideration for usage metrics or change cost to implementors

Even the description of the top level of an extension (aka the "browser action" and the "page action") will change and impact extension vendors

All of that is for the time being decided on the Google side alone, with little or no visible contact with the other WebExtension host (Mozilla) or the thousands of WebExtension (free or commercial) providers. There is even a "migration plans" document but it's not publicly available, the link being access-restricted

On the webRequest part specifically, all major actors of the ad-blocking and security landscape are screaming (see also the chromium-extensions Google group). Us at Privowny are also deeply concerned by the v3 proposed changes. Even Amnesty International complained in a recent message! To me, the most important message posted in reply to the proposed changes is the following one:

Hi, we are the developer of a child-protection add-on, which strives to make the Internet safer for minors. This change would cripple our efforts on Chrome.

Talk about "don't be evil"...

All of that gives a set of very bad signals to third-party implementors, including us at Privowny:

WebExtensions are not a mature part of the Open Web Platform. It completely lacks stability, and software vendors willing to use it must be ready to life-threatening (for them) changes at any time WebExtensions are fully in the hands of Google, that can and will change it any time based on its own interests only. It is not a Web Standard. Google is ready to make WebExtensions diverge from cross-browser interoperability at any time, killing precisely what brought vendors like us at Privowny to WebExtensions. Google Chrome is not what it seems to be, a browser based on an Open Source project that protects users, promotes openness and can serve as a basis tool for webcitizen's protection.

Reading the above, and given the fact Google is able to impulse changes of such magnitudes with little or no impact study on vendors like us, we consider that WebExtensions are not a safe development platform any more. We will probably study soon an extraction of most of our code into a native desktop application, leaving only the minimum minimorum in the browser extension to communicate with web pages and of course with our native app.

After Mozilla that severely harmed its amazing addons ecosystem (remember it triggered the success of Firefox), after Apple that partly went away from JavaScript-based Safari extensions jeopardizing its addons ecosystem so much it's anemic (I could even say dying), Google is taking a move that is harmful to Chrome extensions vendors. What is striking here is that Google is making the very same mistake Mozilla did: no prior discussion with stakeholders (hear extension implementors), release of a draft spec that was obviously going to trigger strong reactions, unmeasured impact (complexity, time and finances) on implementors, more and more restrictions on what it is possible to do but a too limited set of new features.

On the legal side of things, this unilateral change could probably even qualify as "Abuse of dominant position" under European Union's article 102 TFUE, and could then cost Google a lot, really a lot...

The Open Web Platform is alive and vibrant. The Browser Extension ecosystem is in jail, subject to unpredictable harmful changes decided by one single actor. This must change, it's not viable any more.