Hacker News new | ask | show | jobs
by tschiller 1835 days ago
The timeline of browser extensibility is quite fascinating. There's really not a single place that covers all of it, so I decided to research my own timeline/history:

  - Consumer web browsers (1993-)
  - Plug-ins (1995-2015ish)
  - User Style Sheets (1998-2019)
  - Bookmarklets (1998–)
  - Browser Extensions (1999–)
  - Mozilla XUL (1997–2017)
  - Alternative Browser Distributions (2004–)
  - Userscripts (2005–)
  - Converging on the WebExtensions API (2017–)
  - Manifest V3 (2021–)
  - No/Low-Code Browser Extension Builders (2021–)
Here's a link to the blog post with my research: https://medium.com/brick-by-brick/a-brief-history-of-browser...

Also, if you care about browser extensibility, join the w3 group (it's free) and watch the GitHub repo!

9 comments

Now find some sources to cite with that timeline, and create a wikipedia article from it!
What is the goal of this group since the current WebExtensions standard is already supported by almost every major web browser? If seems their goal is already complete.
There's still a lot to do, mainly around distribution and publishing areas:

- webextensions specific storage apis to return promises but chrome still needs callbacks

- A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser.

- csp policies differs between chrome and firefox(and cors too I think)

- UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials.

- Difference between how permissions are interpreted on different browsers

- Huge huge difference between publishing on chrome vs on firefox

- Safari requires xcode, and therefore macos to publish

Ok… but the following topics in your list have nothing to do with an API specification, which is what they say their goals is on the Goals section:

>

“A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser. - UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials. - Huge huge difference between publishing on chrome vs on firefox - Safari requires xcode, and therefore macos to publish”

Bottom line is I don’t think there is going to be an api standard around “distribution and publishing areas”

That last restriction (Safari requiring Xcode) isn’t always a limitation, though. Most CI platforms support Mac for publishing apps to that platform. For instance, GitHub: https://link.medium.com/63hjdbRBQgb and the Safari Web Extension command line parts are documented at https://developer.apple.com/documentation/safariservices/saf...

Plus, you probably still need a Mac or a virtualized Mac (for automated tests, for example) because you’ll want to test your extension with Safari to ensure it works correctly.

I don’t get your comment. You just confirmed that, indeed, you need a specific computer to publish Safari extension, which isn’t the case for Firefox and Chrome extensions.

It is a limitation and it’s completely unnecessary for the end user.

If they’re so lazy to have a extensions-specific store they could at least offer an automatic wrapper that they run before publishing. I should not need XCode anywhere in my build to publish web extensions.

But you need Safari to test the extension and Safari only has these extensions on a Mac? This is Apple’s way of avoiding their store getting cluttered with extensions that haven’t been tested to work on Safari. And yes, it also encourages developers to buy Macs. It can do both…
Have you ever looked at the Mac App Store? It is a literal dumpster fire.
I think the confusion here is need to own vs need to use.
You need to own it in order to use it, and you need to use it in order to publish an extension for Safari. No confusion.
Afaik Chrome does not support the standard, yet Firefox supports Chome’s API. As a result, most extensions seem to use the Chrome API.

Firefox also provides a polyfill to adapt the Chrome API to the WebExtensions standard.

More info here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

> Afaik Chrome does not support the standard

Chrome published the WebExtensions API, not Mozilla. Whether or not it’s a standard is another question, you could call it a defacto standard, but Chrome definitely implemented the api that they published.

"WebExtensions" is a nebulous term and I can find no where that Chrome calls their API WebExtensions, it is simply the "ChromeAPI"

Mozilla as even stopped using the term WebExtensions, instead just going with Extensions [2]

The "spec" that most people refer to as WebExtensions, is BrowserExtensions orginally published by Microsoft via W3C [1]

[1] https://browserext.github.io/browserext/ [2] https://wiki.mozilla.org/Add-ons/Terminology#Background

At the end of the day, though, you can't remap keys in a fully general way in Firefox[1], so the experience has regressed.

[1] Extensions can change it, but they don't take effect until the tab for current page has loaded, which often defeats the purpose.

How is that relevant to OP topic?
Malicious extensions, as well as the ability to block the browser vendor’s ads still pose a problem to these groups to be solved.
Except Apple who don’t have the incentive of browser advertising and are currently selling privacy as one benefit of choosing their hardware (and by extension their software and browser [safari])

Mozilla make money from Google deals and so have outside incentives to not rock the boat too hard on this detail.

Keep in mind that Safari has enough restrictions that uBlock Origin developers decided to stop supporting it, so ad-blocking is pretty poor there.
As always its about control. Its a fight against general computing.

The goal is deprecation of "remote code" execution, where "remote" means remote to Vendor, but local to user, aka anything not shipped and signed by the extension store.

I hadn’t realized that user stylesheet support had ended. I feel like I should bemoan the loss of user control, but in reality, few people used them.
I think Safari on Mac OS has them. If not, what’s https://support.apple.com/guide/safari/advanced-ibrw1075/mac meaning where it says

“Style sheet

To use your own CSS instead of webpage style sheets, click the pop-up menu, then choose Other.”?

Correct. And the cool part is that it loads the file straight from disk. However it offers no Stylish-like UI
Thanks for the link! Adding this to the list of corrections I need to make to the Medium post
Still there in 14.1.1...
$20 says Google removed the feature from Chrome, so a chunk of developers consider the feature 'dead', because to them "Browsers = Chrome".
They definitely still work in Firefox, but you have to toggle a pref in about:config.
I bet there are browser extensions that fill this gap.
Yep, the first style manager extension was released in 2005 (Stylish). Style manager extensions are a much more frictionless way to manage and share styles

The WebExtensions API has APIs for injecting styles: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Stylish was also found to be malware. This is the problem with extensions over browser features. You just can’t trust them with such critical data.
I currently use a user style sheet on the latest version of safari
I suppose you could link to the adoption and decline of methods of running code local (instead of remote) such as JavaScript, Adobe Flash, etc.

But I also think its interesting to note how browsers became suits including a chat and mail client (protocols such as POP3, SMTP, IMAP, NNTP, IRC, FTP, etc) to focusing on WWW only (HTTP). Heck at some point browsers even had LDAP support for things like bookmarks and settings.

> User Style Sheets (1998-2019)

I’m still using them.

Agreed. I just made a new one last week.
Shouldn't Java be somewhere in that list?
Java falls under plug-ins. The Java plug-in was released in 1998. Flash was released in 1996
Are you referring to applets? Or the webstart(?) thing?
Both of them were implemented as plugins.
Internet Explorer add-ons (if only because they were kinda a scourge)

https://en.wikipedia.org/wiki/List_of_Internet_Explorer_add-...

Bookmarklets will die once Content Security Policies will get wider adoption, which I really hope will happen soon.
According to the spec, Bookmarklets should actually be exempt from a site's CSP. The reason is that the user's preferences should take precedence over a site's preferences

There's an open bug in Firefox about this (because it doesn't follow the spec): https://bugzilla.mozilla.org/show_bug.cgi?id=866522

Bookmarklets are exempt from CSP by spec.

And as far as I can tell, they should be. They're a natural intermediate step between nothing and extensions, and there's not really security problems they have that extensions don't.

If there's a problem here, it's that browsers (some, at least) aren't following the spec.

I sure hope not. I rely on bookmarklets on a regular basis. I use them every day.
Yeah, what? I actually have a client that relies on these for some stuff I wrote for them, guess this means I'll have to rework it, but if they represent a security concern then I guess that's all there is to it
They don't represent any more of a security concern than an extension, or even a browser.

The real reason they'll stop working (if they do stop working) is that it would be extra work for browser vendors to maintain and "pfft, power users? what are those"

How does CSP affect bookmarklets?
As others have noted, according to spec, it's not supposed to but in practice at least some browsers apply the CSP to them.

Something I'm not clear on is whether the CSP spec says it shouldn't apply to any bookmarklet or if it only shouldn't apply to bookmarklets that don't request resources from other domains. That is, CSP shouldn't prevent a bookmarklet's own code from doing things like adding/removing attributes to elements but if the bookmarklet tries to load other files (more JavaScript, CSS files, images, etc.) then the page's CSP should apply.

To me, if a browser extension can run, a bookmarklet should also be able to run; a difference is the bookmarklet will only run once when it's clicked and will always clear from memory when a new page is requested.

Both extensions and bookmarklets pose some risk to the user but it's a worthwhile trade-off. If bookmarklets started to become a problem (remote resources being replaced will malware), maybe restrictions would be necessary, like all links to remote resources requiring valid subresource integrity hashes.

Do you know of a replacement for the last resort for transforming a web page into something readable for an individual with accessibility needs?
A browser's built-in Reader Mode (Safari, Mac and mobile, Firefox, Edge's Immserive Reader, Chrome has one behind a feature flag) can be very helpful when they work. A better solution is probably one of the browser extensions, like Stylus [0], that enable not just a single user stylesheet but the ability to have custom stylesheet's on a per-domain basis. On top that personal customization, they can load stylesheets others have already created and shared on userstyles.org [1].

[0] https://en.wikipedia.org/wiki/Stylus_(browser_extension) [1] https://userstyles.org

Firefox's Reader Mode maybe?
Anyone else remember stuff that fizzled out like DHTML?
DHTML didn't fizz out, people just stopped using the buzzword - because everybody uses it pretty much all the time.
Just like AJAX - it's still a thing: you can't have SPAs without it.
The only thing that fizzled out about that is the name.