
Browser Extensions Standard - tbassetto
https://browserext.github.io/browserext/
======
avaer
Hm, if web extensions become a standard, are they really even extensions?
Isn't that just new web APIs with tweaked security parameters?

This is great for security and all, but browser extensions were borne out of
the idea that you wanted your browser to do things that the browser vendor
didn't want, or didn't even conceive of.

Having it be a standard adds security but strictly limits extensions to things
the browser vendors explicitly did conceive of, and stamped their approval on
-- sometimes literally, if you're going through a curated store. Is that a net
win? I'm not sure.

~~~
greenhouse_gas
In general, if your software supports plugins, you can:

1\. Have plugins with ultimate power (meaning that plugins can change
everything, no encapsulation) 2\. Stable API/ABI (meaning that plugins written
for version 1 will work with version 2) 3\. A refactorable code base.

You can pick only two out of three.

Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess
support for years (causing it to have worse performance and security), and now
wants to move to 2 and 3.

Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a
stable Kernel ABI - they chose 1 and 3.

~~~
btrask
There is one plausible solution to this inequality: the Unix philosophy. Small
parts, loosely coupled. Individual parts can't be significantly changed or
removed, but they can be deprecated and better alternatives added. Because the
parts themselves are small, they're less likely to have errors and replacing
them is cheap.

Rich Hickey also has a talk on this. And there's also an overlap with CRDTs
(basically you have a distributed system unless you can refactor everything
atomically).

------
pimterry
Finally! WebExtensions ([https://developer.mozilla.org/en-US/Add-
ons/WebExtensions](https://developer.mozilla.org/en-US/Add-ons/WebExtensions))
have slowly been becoming an adhoc standard for a little while now, but with a
few tricky small differences here and there between browsers (e.g.
[https://developer.mozilla.org/en-US/Add-
ons/WebExtensions/Ch...](https://developer.mozilla.org/en-US/Add-
ons/WebExtensions/Chrome_incompatibilities)). So far it's just been Firefox
and Edge slowly building a close approximation of Chrome's existing API, but a
proper standard for this would be great, and make it much clearer what
extension developers can _depend_ on, and what's optional.

Right now you basically write your extension once (probably for Chrome), and
then port it to the others, often with various small manual changes or
workarounds for incompatibilities. It's much better than it used to be, but
still pretty inconvenient and error prone.

I can see at least a couple of differences with current implementations
though, like using the `browserext://` protocol instead of `moz-extension://`
and `chrome-extension://`. Does anybody more involved with this have a summary
of the differences between this spec and Firefox, Edge and Chrome's
implementations?

~~~
Manishearth
I'm not very involved, but on top of the Chrome base API both Firefox and Edge
have a bunch of additional APIs IIRC (I _think_ Firefox supports all of the
Chrome APIs but I'm not sure). The intent is to have the same manifest format
so basic extensions work everywhere, but extensions can use browser-specific
APIs that fit within the same general framework too.

~~~
weaksauce
> I think Firefox supports all of the Chrome APIs but I'm not sure

They support quite a few but not all. in addition there is a promise based
version of each of the APIs that you can use in firefox under the browser
namespace instead of the chrome namespace. (with a polyfill on npm too if you
want that in chrome)

------
piyush_soni
The only problem which Mozilla didn't think about or hasn't given much value
to is the huge number of add-ons that are going to die or just stop working
when they completely switch to WebExtensions (as there's just no replacement
to the previous API in them). One of the Firefox's USPs was its addons which
could modify the browser behavior and UI in any manner. It's all going to go,
and Mozilla is moving closer to becoming a Chrome clone (albeit open).

For example, a hugely useful feature for me was TabGroups (Panorama) which
they removed from the main browser to make it an external add-on, and even
that will stop working soon [0]. Similarly, there are add-ons which modify the
browser's inbuilt 'Find in page' behavior in Firefox. Looks like even they are
not WebExtension compatible.

[0] : [https://addons.mozilla.org/en-US/firefox/addon/tab-groups-
pa...](https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/)

~~~
gcp
Mozilla has given this _a lot_ of thought, and realized it is _extremely
valuable_. But the value does not dwarf the downsides.

XUL extensions would block most of the Servo work, as an obvious example. You
can't rely on the browser internals if those are changing underneath you.

~~~
piyush_soni
Had they given it enough thought, they'd have pushed for replacement of XUL
APIs in WebExtensions in a non-blocking way, for example. But they found
killing all of the valuable add-ons of years worth of work of so many
developers justified.

~~~
bzbarsky
> they'd have pushed for replacement of XUL APIs in WebExtensions in a non-
> blocking way

Which "they" did, and are. Some APIs are more amenable to such replacement
than others. For example, APIs that allow you to modify any part of the
browser UI in an arbitrary way are not so amenable _and_ have the problem of
breaking any time the internal structure of the UI changes. Which has, in the
past, prevented improvements to the internal structure of the UI...

It's really easy to see only one side of this (the downside of extensions
breaking, or the upside of not having your implementation severely constrained
by extensions that keep depending on internal details they shouldn't depend
on). But there are in fact people who've thought long and hard about both
sides of this.

~~~
xg15
Except the downsides are mostly for the users (extensions stop working) while
the upsides are mostly for the browser developers. (Better ability to refactor
and update)

~~~
bzbarsky
The upsides are for users as well: better performance, less memory usage,
better ability to implement web standards. Browser developers aren't just
breaking extensions for the fun of it, but because they're in the way of
actually producing a better product; the goal is to produce said better
product.

The upsides are just somewhat more diffuse than the downsides: the former
apply to all users, while the latter only to those who have extensions that
stop working.

------
xg15
As a developer, I'd really like if I could publish an extension as a single
archive file and have users load it into whatever (compliant) browser they
like - however, the standard doesn't seem to actually support this. When it
comes to packaging, there is nothing more than a vague acknowledgment:

 _Browser extensions MAY be distributed and subsequently loaded as individual
files or via a container, such as a .zip archive. Regardless of the packaging
format, these containers MUST contain the following: [manifest.json, Necessary
JavaScript files ( <filename>.js)] [...]

Browser vendors MAY require that extension packages include a digital
signature. The signature MAY indicate the source of the extension, such as a
distribution store or the extension's publisher. This aspect of packaging
varies by browser, and browser implementers MAY enforce different
requirements._

I guess that's a concesson to all the politics surrounding app stores, but
it's disappointing nevertheless.

~~~
nsgi
Unfortunately that would be practically difficult with Chrome only allowing
extensions downloaded from the Chrome Web Store.

~~~
fny
The package format could apply to how extensions are deployed to the store at
least.

Also, I know it's possible to run third-party extensions in developer mode.

------
martinsbalodis
As a chrome extension developer I really like this. Previously I didn't
develop extensions for other browsers because I would have to learn another
ecosystem. Now it could be pretty simple to do.

I also like that all of the asynchronous API calls are returning Promises.
Chrome API is still using callbacks. This also means that some time will pass
while this is even added to chrome. I expect that there will be a polyfill
library that translates the new API calls to legacy browser API calls.

------
erikrothoff
Sorry for not bringing anything of value to the discussion but: Heck. Yes! I
love Firefox for going in this direction. The politics of embracing Chrome's
extension APIs and standardising upon them must have been astounding.

I can't wait to port my extension to Firefox. Firefox is seeming like a more
and more viable option to Chrome.

------
mekkkkkk
It would be interesting to have a browser where every part except the engine
is an extension. I.e. hotkeys, address field, bookmarks and so on being
standardized, replaceble extensions, run in a chromeless window. An infinitely
hackable experience. Prepackaged bundles could ship as discreet browsers, for
the less techy user.

~~~
Yoric
Well, that sounds like the historical Firefox. If you look at the source code
of Firefox, just about everything except Gecko is a XUL add-on. Worked like a
charm for the first 10 years, not so much afterwards because it became a
maintenance nightmare.

That's actually the main reason for which Firefox is moving away from XUL add-
ons and towards more restricted WebExtensions.

~~~
carussell
> If you look at the source code of Firefox, just about everything except
> Gecko is a XUL add-on

That's not really true at all. Most of the Firefox UI was written in JS (and
XUL and XBL), but not as add-ons.

It would have been great if it _were_ true, because not only do you get the
reconfigurability the parent commenter writes about, but there are even better
advantages: it would also have meant the Firefox team themselves would have
had to confront the poor APIs exposed to extension authors and the poor
practices about breaking things. The reality is everyone just touched
browser.js (or what have you) to make it do what they wanted.† Had that not
been the case, the deprecation of old-style toolkit add-ons might have
happened long ago and a good replacement created. What happened instead is the
worst from both ends: a sickly add-ons ecosystem built on top of fragile XUL-
based extensions hobbled along for years, and now that they are obsoleted,
they are given a replacement that is decidedly not good.

When Robcee announced he'd gotten the imprimatur to ship devtools with
Firefox, I made an impassioned plea for it to be developed and shipped it as a
built-in add-on, for exactly these reasons, and because it would have allowed
faster development iteration and provided an easier contribution path (no need
to ever waste hours rebuilding nightly, or asking for the same from a casual
contributor who wants to submit a patch but doesn't work for a manager with an
@mozilla.com address). No dice.

† Not to mention tons of XPCOM junk _not_ related to rendering or parsing or
the JS runtime that was nevertheless implemented in C++ and would need updates
to the core if ever wanting to anything non-trivial.

------
OliverJones
Does anybody know whether the Google Chrome / Chromium team and the Mozilla
team are squarely behind this standardization effort? What about the Apple
Safari team?

There's only one rep from Google in the community group. There don't seem to
be any from Apple.

[1990s paranoia mode] this could be another Microsoft effort to embrace and
suffocate [/1990s paranoia mode]

~~~
OliverJones
I've been working on web extensions for multiple browsers lately.

Chrome and Firefox have workable ecosystems and accept more or less the same
code, but package it differently.

Edge accepts almost the same code, but they had to change the "chrome"
namespace to "browser". I suppose it was a question of pride. Also, Edge
doesn't have a workable way to publish and to inline-install web extensions.

Safari accepts similar code to the rest, but organized differently. They have
a slow and ponderous process for approving extensions for their store. They
don't offer anything remotely resembling inline installation.

~~~
Manishearth
> but they had to change the "chrome" namespace to "browser"

It's weird, because Firefox internally has had the "chrome" namespace long
before Google Chrome _existed_.

In browser terminology the browser "chrome" is the stuff that's outside the
browser engine -- the stuff that doesn't handle loading/laying
out/rendering/javascripting a page. I.e. the tab strip, URL bar, bookmarks,
context menus, settings, etc.

IIRC (very unsure of this, but have heard it from different non-google
sources) the name "Google Chrome" is actually a joke on this because it had
the _least_ chrome amongst browsers of the time (remember the toolbar and
status bar?)

~~~
Slackwise
> IIRC (very unsure of this, but have heard it from different non-google
> sources) the name "Google Chrome" is actually a joke on this because it had
> the least chrome amongst browsers of the time (remember the toolbar and
> status bar?)

Well, that and it was Google.com's "chrome".

------
gwbas1c
Part of the reason why we have different browsers is the variety of features
they support. A browser extension inherently is closer to the unique part of
browsers that make them different.

What value does this really provide? The times that I've gotten into browser
extensions were really working with features that are unique to the given
browser.

~~~
vec
There's an argument that while rendering engines are huge, monolithic
undertakings, the actual browsers wrapped around them are fairly trivial.
Assuming they use the same rendering engine under the hood, a relatively
lightweight, tightly integrated platform-native browser (i.e. Safari or Gnome
Web) might be a better user experience than a cross-platform behemoth like
Chrome.

Extension support and depth of extension library have traditionally been the
big pain point with switching to a minority browser. Moving extension support
into a browser independent standard removes a lot of the selective pressure
toward a monoculture.

------
Osmium
It would be really nice if you could blacklist websites from using extensions
in Safari, e.g. banking websites.

There are lots of useful extensions out there that would be nice to use, but
I'm concerned if they became compromised (which happens regularly[1]) they
might hijack my data.

Safari has a great feature that stops extensions from being able to read or
transmit anything from websites you visit, which is great, but limits the
effectiveness of a lot of ad blockers.

[1]
[https://news.ycombinator.com/item?id=14888010](https://news.ycombinator.com/item?id=14888010)
(just 2 days ago!)

------
fibo
Looks a really good idea

------
ahmedfromtunis
But will Google allow this to happen, as it would strip them a huge selling
point for Chrome?

~~~
josteink
Please elaborate. What selling point for Chrome are you talking about?

~~~
gcp
The add-on ecosystem of Chrome currently dwarfs Firefoxes. Firefox extensions
used to be more capable, but there's just more and certainly more NEW ones for
Chrome.

(I'm sure this was an important consideration for Mozilla as well - it reduced
the supposed value of their "more powerful" XUL extension system, as in
practice you can often find a Chrome extension to do what you want, but not a
Firefox one)

~~~
josteink
But Firefox can already run WebExtensions (aka Chrome extensions).

So how does this change anything?

~~~
gcp
It can.

But it can't keep XUL compatibility and do major overhauls of the browser.

If XUL compatibility doesn't even get you a clear advantage in the add-ons
area, should it block modernizing the browser?

Firefox can't be the browser that people use only because they're stuck on it
because they have extensions that changes how the browser works. Think about
that for a bit.

~~~
josteink
I know all about the issues with Firefox, the new WebExtensions and how the
"old" XUL extensions which let you do "anything" are being phased out.

I just don't see how any of that is relevant to the original comment I replied
to:

> But will Google allow this to happen, as it would strip them a huge selling
> point for Chrome?

In what way would standardizing WebExtensions, which are already supported by
all modern browsers (sans Safari), strip Chrome of selling points?

Why should Google have to "allow" this?

~~~
gcp
Chrome currently has the largest amount of extensions, which is an advantage
for that browser.

Standardized WebExtensions dilute that, because they allow easy ports to the
other browsers.

~~~
connorcpu
I think the point is more, in what way does google have any power to stop
other browsers from implementing this API?

~~~
gcp
They don't. Unless you want to claim API's are copyrightable, but there are
some downsides to that :-)

------
Nyrox
Cute idea, but I will eat a broom before this actually becomes reality.

~~~
gcp
Not sure what you mean by this, but this (like most modern web standards, and
I'm not even sure of the modern part) is just documenting what the
implementations are _already doing_.

Mozilla and Microsoft are specifically re-implementing the Chrome Extensions
API, and documenting it.

~~~
_nalply
Eating a broom is a German saying: «Eher fress ich einen Besen...!».

~~~
WaltPurvis
Thank you! I was just about to ask about the origins of that phrase (which
I've never heard before).

