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

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.