Browser Add-on Terminology is Broken. Can it be Fixed?

28 June 2011 by Matthew Gertner - Category: Rants and Ruminations

Ever since I started developing browser add-ons for clients, I’ve battled with the confusing terminology used to describe them. A typical conversation goes something like this:

Client: How’s the plugin development going?
Me: Extension development.

When we started running some Google ads, I noticed the same phenomenon at work. I picked a bunch of keywords including “plugin”, “extension” and “add-on”. Some people found our ad with a query containing “extension” (especially if they were interested in Firefox), but the large majority queried “plugin”. The funny thing is, exactly none of them wanted an actual plugin. They all wanted extensions.

The fact is that for the segment of the population who are not browser geeks, everything you install in your browser to extend its functionality is a plugin. Partly this is doubtless because the term “plugin” has an older pedigree. Partly it probably reflects the fact that a lot of other software also uses plugins but none has extensions. For all I know, “extension” simply has too many syllables.

Since a considerable majority of the population is made up of non browser geeks, this makes me wonder how legitimate the distinction between “plugin” and “extension” really is. Despite valiant attempts to explain the difference, it’s a safe bet that most people will never know or care. Meanwhile the ambiguity inherent in the term “plugin”, which means something totally different to an expert and a layman, is frequently annoying and occasionally downright dangerous.

How could this be fixed? I see two appealing solutions (neither of which will ever be adopted, but I can dream, right?). The most obvious is to make “plugin” mean what “add-on” does today (i.e. anything that adds new capabilities to the browser, whether an extension or a plugin). That way popular usage would no longer be wrong, and we could presumably tell from context when a plugin (in the traditional sense) is meant. Browser geeks and other pedants could say “NPAPI plugin” or “ActiveX plugin” if they want to be specific.

The other solution is to eliminate the difference entirely. The primary use of plugins is to handle a type of content that the browser itself can’t by registering then to handle data embedded in a webpage. There could just be an API that an extension (potentially written entirely in JavaScript) could use to register itself to handle a specific content type. This is arguably the case in IE already, and Firefox has content listeners so making plugin-like behavior possible in an extension would be more a case of some convenience APIs than adding any real new capabilities.

The other use of plugins is to allow binary code in Chrome extensions, but that doesn’t strike me as a great idea anyway. I was pretty surprised when I installed a Chrome extension that included an NPAPI plugin and was warned that it can access “all data on your computer and the websites you access”. Maybe I’m missing something, but shouldn’t that have continued “…and format your hard disk, send your online banking details to the Russian mob and sleep with your spouse next time you’re on a business trip”? I’m a big fan of having a clear distinction between safe JavaScript extensions that have sandboxed capabilities and those with binary components, which should have a much scarier nag screen and stricter review requirements for inclusion in official add-on galleries. If Chrome were to go this route, another reason for the plugin vs. extension dichotomy would be eliminated. Good riddance.

« Off Trac - Should Apple Discontinue Safari or Double Down? »

COMMENTS

http://Website wi

i do see everyone calling addons “plugins” too, even among people that have IT jobs such as some net admins.
kinda annoying as i personally expect a plugin to be a npapi plugin
http://www.owlfolio.org/ Zack

Nobody likes the NPAPI as far as I know, and it has unfortunate knock-on effects (for instance, it adds to the difficulty of fixing the notorious bug 90268, and for Unixy builds it means we have to lug around an Xt-to-Gtk shim) so a proposal that moved the platform toward being able to kill it off would I think be most welcome. And now we have pdf.js as a demonstration that things traditionally handled by NPAPI plugins can be dealt with in JS libraries. So I encourage you to push your second proposal.

Your first proposal also has merit, I’ve heard plenty of people complain that they don’t understand the difference, and not surfacing it in the UI doesn’t seem like it would be a hard sell.

http://colonelpanic.net taxilian

pdf.js may solve a single problem that is commonly handled with NPAPI plugins, but there are about a million other things that people do with NPAPI plugins or ActiveX that simply cannot be done with HTML5; generally it involves doing things that won’t perform well enough to use HTML5, requires direct hardware access, or requires filesystem access.

Like it or not, “browser plugins” (as opposed to extensions or other types of add-ons) aren’t going anywhere; as the author of FireBreath (http://www.firebreath.org) I am continually surprised by how many new people we get using the porject; frankly, if your problem can be solved without using a NPAPI plugin/ActiveX control then it should be. Unfortunately, a great many problems *can’t* be solved in any other way.

The idea of unifying them all into the same type of interface would be really neat, but currently every single browser supporting an “extension” uses a totally different API; good luck getting them all to agree on a single extension method :-/

http://Website cuz84d

Lets just call all the addons/extensions plugins then.
http://users.skynet.be/antoine.mechelynck/ Tony Mechelynck

I’m seeing the terminology getting fuzzier all the time, and I’m not sure I like it. There used to be:
- plugins (stuff like Acrobat, Flash and Java, which could be shared with Konqueror, Opera, and in fact any browser except IE);
- search engines (stuff like Google or Yahoo, but also to search various Wikimedia or even Bugzilla sites; the main place to look for them is the Mycroft project on Mozdev)
- extensions (packaged as .xpi, which could do wonderful things and required a restart)
- themes (also called skins, packaged originally as .jar and nowadays as .xpi, and it was possible but not recommended to change them without restart by means of a hidden pref)
The latter two converged quite fast, and with the second-latest avatar of the extension manager they were handled identically. Nowadays there are more kinds:
- restartless extensions (including, but not limited to, Jetpacks). Some restartless extensions can be run on SeaMonkey, most Jetpacks can’t
- restartless themes (or lightweight themes, or Personas) which can only set two background images for the chrome and can only be worn on top of the Default theme
- two more kinds already existed but are now handled separately: language packs and spelling dictionaries

All the above are now called add-ons, and IIUC the plan is to handle them all through about:addons, though search engines aren’t yet, and [NPAPI] plugins are listed under both about:addons and their former abode, viz. about:plugins.

I’m not sure this is all for the better: after all, “Netscape plugins” (as they are still sometimes called, especially by their makers) can be used anywhere except on IE; search engines are of two kinds, one of which can also be used on IE, and the rest are all packaged as .xpi archives nowadays, and handled very similarly, though some are restartless (and more limited), others not.

I feel as if someone tried to push the idea that every piece of clothing should be called a diaper because that’s what people who don’t know any better are clad in.