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–)
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.
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”
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…
Can you explain what you mean by “literal dumpster fire” because this doesn’t align with my own experience. I’ve used it for purchasing a number of apps recently and I saw nothing eyebrow-raising. So long as the app you want has been uploaded to the store, it works perfectly fine.
That’s true of pretty much any App Store that isn’t strictly invitation only. If you have an app follows Apple’s rules, it gets listed. Whereas Steam, by comparison, exercises editorial control over all of its content. The solution for a better Mac App Store would require Apple to be similarly dictatorial about content.
In that sense I agree with you; personally I think it was a mistake of Apple to have the Mac App Store so closely mirror the iOS App Store. They should have made it a more aggressively curated experience.
And before anyone claims u can just buy time on a cloud Mac... The cost for these and requirement from Apple for a min. period of 24 hours rental (something to do with Mac stadium?) mean you're funneled towards making the $2000 "investment" in a iDevice.
If you can't afford to cross-browser test, and you don't have a Mac, I'm not sure why you're building an extension for a Mac-only browser then? Someone has to test it on a Mac, register for a certificate with Apple, etc. In the end, buying a Mac is the easy part?
And there are services like https://www.browserstack.com/docs/automate/selenium/add-plug... where you can basically rent Mac VMs on cheap monthly plans. Or GitHub Actions, as I pointed to earlier, has a free tier with free minutes on an automated Mac terminal.
On one side Apple says they now offer a compatible API, on the other side you’re telling me dropping a minimum of $800 on a computer (+$100 annually) to release a free extension is the easy part.
BrowserStack would be a good solution to test it, but unfortunately you also need a lot of preparation and XCode-specific knowledge to even get to a testable point, which you don’t get unless you own a Mac.
The browsers that Apple claims to be compatible with don’t require anything more than WinZip.
Apple added requirements for their store to publish extensions, yes. They also added more privacy prompts. If you don’t test on MacOS in Safari, how would you know if your extension works correctly?
Why not ask Apple to release macOS for any computer like Windows on x86? Why not ask for Safari to be published for and API compatible with Windows as on macOS? Why not ask Apple to ship Windows since mac-only APIs would be problematic?
Fact is, Apple requiring a Mac to publish for a Mac-only browser is not a problem. It’s not even true. You can code sign for Mac from Linux[1], as I understand it. Worst case, a third-party service will step in to handle packaging and publishing the way we already do for cross-platform native apps and yet Apple will continue to expect devs to test on their Apple devices.
I can run Firefox or Chrome on my Mac so it’s not like I’m missing out if you choose to not develop an extension for Safari and test it in Safari. I feel like you’re arguing that testing isn’t required if you have the right web standards, which is pretty much always false when there are privacy or other implementation details that vary by browser…
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.
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.
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.
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
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.
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
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.
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"
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.
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].
I'm cautiously optimistic that this will work well, but somewhat concerned that this will cause Manifest V3's de facto limits on ad blocking and the like to become endemic. It will be interesting to see how they balance "compatibility with popular existing extensions" against their foundational focus on security and privacy.
The headline is what it is on the site but it should probably be clarified that it is extensions, not plug-ins. The author didn’t correctly distinguish but as other comments point out, it is more than a semantical difference.
This is a good move and something we’ve been moving towards for years, but it is still nice to see. Extensions are often one of the biggest barriers to browser lock-in on the desktop and making it easier for devs to build extensions that can reliably work across browsers, the better it will be for users.
Obviously, the individual browsers will stink have their own specific ways of doing things, but this is a positive development.
I worry that this may lead to an embrace/extend/extinguish by Google given that they have a tremendous influence through Chrome.
After all what's their angle here? Almost every browser extension under the sun has a Chrome version due to its immense market share. It seems like a good way for them to later potentially push for changes that would make, say, ad blocking easier (under the guise of performance or some such).
I consede that it's a bit tinfoil-hatty, but I have very little faith in Google these days.
WebExtensions were already practically required to be a superset of Chrome's APIs, so the incentive is already there to just use what Chrome offers for maximum compatibility. Mozilla can and does offer additional APIs beyond what Chrome does, and in some cases (like adblocking in a manifest v3 world), this will soon be more relevant as Chrome's adblocking capabilities will take a hit upon killing manifest v2, but it's already the case that Firefox is a better platform for adblockers, as detailed by uBlock origin devs: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
I don't see this group constraining vendors to implement _only_ the blessed APIs, much like web standards hasn't stopped Chrome inventing new APIs for Google needs.
You guys do everything in your power to twist a seemingly good thing into something evil. Understandable I guess but at this point I don't even know if Google actually is evil or if that's just a presumed narrative this place likes to put on every initiative from them.
Well Google neutered ad blocking extensions for Chrome. It's very hard not to see this as them trying to do the same elsewhere. Google used to be the good guy darling, not too long ago. They brought it on themselves.
On an anecdotal note this might ironically lead me to being able or moving back to Safari again. I moved to chrome when YouTube started having sooo much advertising and I couldn’t get unlock origins for safari.
The best outcome of this might be to have extensions more widely available on mobile browsers. A bad outcome would be that Firefox limits the capabilities of its extensions.
On my Android tablet I use Kiwi Browser, a fork of Chromium that supports Chrome extensions. Ublock Origin, Tampermonkey, and a few other of my favorites all work reliably.
Kiwi Browser is a great one! I have it installed, but use an older version of Firefox for the peculiar reason that I like to be able to save pages [with SinglefileZ].
In what way has mobile computing remained static over the past decade? The only thing that hasn't changed, is Apple strictly controls what apps are available on iOS. The capabilities of those apps has been changing at a steady clip since "apps" first became a thing
What kind of innovations in desktop computing would you classify as technological improvements? To me, since we created integrated circuits, we've generally been talking about incremental hardware improvements. If anything, mobile computing has actually innovated more than desktop (see ARM coming to laptops via M1 with amazing performance; integrated graphics / system-on-a-chip becoming more common in desktops).
Which feature has Firefox removed or crippled due to such a demand? I cannot think of one, but presumably you have a few documented examples given how confident you are about this.
It's not about Google demanding it, it's that Mozilla has less developer capacity than Google so they're spending more time matching Google's API changes instead of implementing their own.
For instance Manifest V3 would mean the end of uBlock Origin and other content blockers if Mozilla follow Google's implementation exactly, and whilst they've said recently they're not intending to deprecate the content blocking APIs this isn't a long-term certainty especially with this new conformity group arising.
The original claim was: "If Google demands Firefox limit the capabilities then that is what will happen." What you're writing seems completely unrelated to the original conspiracy theory.
But sure, why not. Let's move the goalposts. If Mozilla does not have the resources to implement standards, why bother joining a standardization effort? Why not just stand outside tent and piss into it?
Because everyone is actually better served by standards, and Mozilla is better off having a say in what gets standardized.
Plugin historically referred to NPAPI (Netscape Plugin API), and later PPAPI (Pepper Plugin API) which were used for Flash, Silverlight and such. This historical reason was what distinguished between plugin and extension. The practice still continues today with H264 and Widevine even though they no longer uses NPAPI/PPAPI.
I'm still bitterly sad that Widevine has almost ended up as part of the spec de facto. I always turn off DRM compatibility in FF, and wish the other browsers would give me the choice. For me, that battle has been lost but the war may yet be won. I hope that this move of extension standardisation is actually a net boon for the end user, and not another silent, slippery path like WV and HTML 5 DRM have been.
"Plugin" generally refers to adding custom code to the browser itself, as a dynamic library or something, with the full ability to do anything the browser can do (i.e., it's equivalent to downloading an application). Plugins are usually written in a language like C.
"Extension" generally refers to code given limited access to certain APIs, a bit more generous than the access given to an individual web page but much closer to that model. Extensions are usually written with web languages like JS and HTML.
The multi-decade security trainwreck that was Flash was possible because it was a plugin - both in that bugs that corrupted the code could let an attacker run unrestricted code on your machine as if they'd gotten you to run a malicious application, and in that Flash was on its own for implementing rules like "can this website download files from this other website," so it was often possible to break the web's security model via Flash. Extensions go through the browser core to do all their work, just like JS on a website.
Conversely - Flash allowed doing a whole lot of cool things back when the web platform was nowhere near as capable. An extension can't directly access, say, the clipboard; it has to go through a browser API to do that. But back when there was no browser API, Flash could access the clipboard just like any other program on your computer.
Yes, I think you've captured the difference: An "extension" is written in an extension language like JavaScript, in a browser that's intended to be extended in that language. A "plugin" is a more independent piece of code written in a compiled language, plugged into a host that doesn't necessarily have its own extension language like JavaScript or Visual Basic.
But I think that may be largely an after-the-fact rationalization (like retronyming "YAML" from "Yet Another Markup Language" to "YAML Ain't Markup Language") and it's mainly a historical artifact that two different generations of browser extension technology have different names, because they're not precisely mathematically defined categories of computer science.
At the time that NSAPI came around, JavaScript wasn't really much of a thing, and DHTML didn't exist, so not many people would have seriously thought of actually writing practical browser extensions in it. JavaScript was first thought of more as a way to wire together plugins, not implement them. You were supposed to use Java for that. To that end, Netscape developed LiveConnect.
Microsoft eventually came out with "ActiveX Behavior Components" aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)" that enabled you to implement ActiveX controls with COM interfaces in all their glory and splendor, entirely in Visual Basic Script, JavsScript, or any other language supporting the "IScriptingEngine" plug-in interface, plus some XML. So you could plug in any scripting language engine, then write plug-ins in that language! (Easier said than done, though: it involved tons of OLE/COM plumbing and dynamic data type wrangling. But there were scripting engines for many popular scripting languages, like Python.)
NETSCAPE SHIPS LIVECONNECT BETA. By CBR Staff Writer 30 May 1996.
>Netscape Communications Corp, Mountain View, California, this week released its LiveConnect SDK development kit in beta which enables live objects in Web pages – such as Java applets, JavaScript scripts and plug-ins – to communicate with each other. Netscape will deliver a pre-release version of Java user interface component and application programming interfaces acquired through its acquisition of Netcode Corp earlier this year. Netscape will release a beta version of its Java-enabled Navigator 3.0 client for Windows 3.1 in June.
LiveConnect enables communication between JavaScript and Java applets in a page and between JavaScript and plug-ins loaded on a page. This chapter explains how to use LiveConnect in Netscape Navigator. It assumes you are familiar with Java programming.
Use JavaScript to access Java variables, methods, classes, and packages directly.
Control Java applets or plug-ins with JavaScript.
Use Java code to access JavaScript methods and properties.
For reference material on the Netscape packages, see the JavaScript Reference.
For the HTML syntax required to add applets and plug-ins to your web page, see the Applet and Plugin objects in the JavaScript Reference.
For information on using LiveConnect with server-side JavaScript, see Writing Server-Side JavaScript Applications.
For additional information on using LiveConnect, see the JavaScript technical notes.
You can use WASM in extensions. WASM qualifies for independent pieces of code written in a compiled language. Does that make extensions plugins?
I really don't see how "compiled" versus "script" makes a difference. The are both independent pieces of code written to interact with an API to add functionality.
Extension, add-in, add-on, plug-in are all words describing the same thing.
Yeah, that's why I gave the definition above upthread. It's not compiled vs. script - it's whether it runs alongside the browser's own code, with the same OS access that the browser does, or whether it runs inside the browser, with a bit more access than web pages do.
By convention, "plug-in" means the former and "extension" means the latter. There is a big difference.
Yes, that's what I meant by "after-the-fact rationalization" and "it's mainly a historical artifact" and "they're not precisely mathematically defined categories of computer science." It's just a fuzzy descriptive convention, not a strict prescriptive category.
The terms are just historical accidents. There is no official definition that "plugin means compiled code" and "extension means interpreted code". There is no well defined dichotomy, and the boundaries are fuzzy, and there are many other synonymous terms like "add-in", "add-on", "library", "package", "module", "customization", "mod", "XP/COM Component", "ActiveX Component", "OLE Control", "COM Object", "Windows Scripting Component", "Dynamic HTML Component (HTC)", "Scriptlet", "Binary Behavior", "Browser Helper Object (BHO)" etc.
And technologies like Mozilla XP/COM and Microsoft ActiveX purposefully blur the compiled/interpreted dichotomy by letting you implement components as either compiled code or interpreted scripts.
The whole point of ActiveX/COM/OLE/ActiveScript/Windows Scripting Engine (and Mozilla XP/COM) is to hide the implementation language of components, and transparently enable components implemented in interpreted and compiled languages to interoperate seamlessly.
>OLE Scripting is Microsoft's mechanism for incorporating Visual Basic Script and scripts created in other interpreted programming languages, such as Java or JavaScript, within DocObjects. Get the details from http://www.microsoft.com/intdev/inttech/olescrpt.htm. This sounds quite interesting: a way to plug extension languages in as components, via the COM IScriptingEngine interface.
>First there were VBXs. Then there were OCXs. Then, Microsoft wanted us to call them OLE Custom Controls, but we persisted in calling them OCXs. So they must have figured that we wouldn't accept any control technology that didn't have a name ending in X. -Curt Hagenlocher
For example, here are pie menus implemented in compiled C++ as a binary ActiveX control, which can plug into the browser, but can also be used by any OLE container like Microsoft Word or an arbitrary MFC app, so they don't depend on the browser or JavaScript:
And here are pie menus implemented in text JavaScript+XML source code as a Dynamic HTML Behavior Control, which can only run in the browser, but can leverage browser technology like Dynamic HTML and CSS for rendering:
Both of those are COM Objects/OLE Components/ActiveX Controls, implemented in different languages, and dependent on the host implementing different interfaces. It doesn't make sense to classify one as a plug-in and one as an extension based on whether they're compiled or not, but the JavaScript one does have a lot of dependencies on the browser that hosts it, while the C++ one does not. But the HTC doesn't get its JavaScript interpreter directly from the browser, it gets it from the scripting engine interface, which exists independently from the browser, and it could as well have been written in Python or Visual Basic Script.
Plugins were native code, usually running under NPAPI.
Extensions or Add-ons running with WebExtensions API are HTML/JS/CSS and have way less access to your machine. They run in a sandbox with very specific fine-grained control over permissions and capabilities.
It's mostly a historical term of art: Browser plugins refers to NSAPI plugins (and could also refer to OLE/ActiveX plugins), which is older and now obsolete, and is based on plugging native code in compiled binary dynamic libraries into the existing browser app (or OLE control container), without necessarily requiting an extension language like JavaScript / Visual Basic.
Browser extensions refer to more recent JavaScript centric extension techniques (like the older Firefox XUL extensions, and more modern Chrome/etc extensions), using JavaScript as a browser extension language, throwing in some XML and CSS, and coding most if not all of the plugin in JavaScript, instead of linking compiled binary code.
Python makes a distinction between "embedding" and "extending", that doesn't map directly into the browser plugin/extension dichotomy, but is kind of similar -- it's a question of "who's on top", and embedding usually implies some extending:
Extending Python means building modules that Python code can import to access the features the modules supply. Embedding Python means executing Python code from an application coded in another language. For such execution to be useful, Python code must in turn be able to access some of your application’s functionality. In practice, therefore, embedding implies some extending, as well as a few embedding-specific operations. [...]
>This document describes how to write modules in C or C++ to extend the Python interpreter with new modules. Those modules can not only define new functions but also new object types and their methods. The document also describes how to embed the Python interpreter in another application, for use as an extension language. Finally, it shows how to compile and link extension modules so that they can be loaded dynamically (at run time) into the interpreter, if the underlying operating system supports this feature.
It's best to define these words with feelings, and I feel like plugins are like a little box that is free to do "plugin" things within the box, but is otherwise merely co-existing within the browser, rather than integrating. Things like Flash, Silverlight, Java, etc. always did their own thing. Extensions are often tightly integrated into browser functionality, with interactions potentially happening in both directions. Custom buttons on the toolbar or context menu, with extensive access to your browser profile and perhaps cross-cutting concerns.
Another way to think of it is something you just plug in and use, like a vacuum cleaner. But an extension needs access to the browser API and may entangle itself.
I'm sure there are exceptions to those boundaries, such as Javascript being enabled to interact with Flash applications, but a plugin might operate without any real crossover with the browser functionality beyond existing in a window.
I was always explaining this on our local community forums in the early years of Firefox presence like this: extension extends the program on functionality, while plugins allows you to use other piece of software or its part within the browser
So Flash is an extension because it extends the browser's functionality to also be able to display Flash content, and an advert blocker is a plugin because it allows you to use the advert blocking software within the browser... right?
Firefox abandoning the more powerful XUL to web extensions resulted in a lot of extensions going away because there are not useable APIs. On the other hand, I would feel relatively safer to install a web extensions than a XUL nowadays because they are pretty well contained with permissions.
I miss XUL. Yes, you gave over complete control to the author of the plugin. But with a properly functioning rating and reporting system, bad extensions would be flagged and removed before you were statistically likely to use them. Also, I think that allowing users to open a "banking mode" with extensions disabled would be better than removing user choice entirely. But considering that browsers are quite literally a business, and you need funding to continue to develop one, all browsers had to remove user choice in order to not get hit by a "firefox is insecure" smear campaign.
DownThenAll! (or download managers in general) are still rather severely crippled, though – they can only download into the official OS "Downloads" folder, they can't skip files that already exist in the target directory...
Standardizing browser plug-ins is I think not the best idea; it means that many things will be difficult or impossible to do, due to needing features that are not standardized or cannot be standardized (due to having differences in different operating systems, differences in web engines, and other possible reasons including ones that I don't know yet). It might also perhaps make some things slow or otherwise less efficient than they should be.
I see your point, but I see a huge benefit to standardization here. This will help with the 90% of tasks that all browsers are capable of - instead of two ways to do the same thing, you get one way - developers jobs get easier, cross compatibility actually works. For the remaining 10%, I agree there is some risk - but per the webextension group's charter (https://github.com/w3c/webextensions/blob/main/charter.md) section on "Autonomy"
> Given this, we expect browser vendors to offer APIs and capabilities beyond what's specified.
Of course microsoft and apple would like such standardization: their browsers are very poor on plug-ins/extensions compared to chrome and Firefox. Maybe chrome is still a bit faster than Firefox, but it is fast enough for my uses and, considering it is "more independent" than other browsers, it is now my favorite browser again.
"The incident is a reminder that browser extensions — however useful or fun they may seem when you install them — typically have a great deal of power and can effectively read and/or write all data in your browsing sessions."
I hope they standardize the interface for password managers as well, so that 3rd party password managers can be as secure as the browser's own built-in ones.
I can't fully agree. Maybe from distribution/binary PoV might be more secure, but built-in browsers password store are accessible by your own apple/google/microsoft/firefox account. So if someone compromise your email, it will get instant access to all your passwords too. None of those use a separate encryption key to make sure someone that got access to your account don't get access to passwords.
I am glad that they have come together, finally. After a serious threat from social media companies like Facebook and Twitter. Social media companies have grown too much in power. And they are misusing it all the time.
The decision of Google to build RSS support in Chrome is also part of the same plan. Now you don't need an account on TW, FB to follow someone's blog.
So basically they just want to keep support for the security holes. In here, South Korea, under the name of security, installation of several kind of Active-X and unknown binaries is forced and they ar e suspected to being used in collecting private information of users.
By stopping supporting these kind of security holes internet would be better place.
Aren't Apple and Google phasing out extensions? The v3 manifest is taking some power away from extensions and both Google and Apple banned extensions on mobile devices so it seems like they are trying to get rid of them.
If they are serious about this then is this the first step towards extensions on mobile?
Great - now ad-blockers / anti-data-harvester extensions are going to be further crippled in the name of "security" on all browsers at one go.
This isn't far fetched at all - It is already the most crippled in Google's and Microsoft's browsers and partially crippled in Apple's Safari. And note that all three tech giants browser harvest your personal browsing data as all three of them also run an advertising network.
Mozilla would easily be outvoted by these three on any decision making. (This is ofcourse disregarding the fact that Mozilla already does Google's bidding). The decision that Mozilla makes here will dictate their future - if they cripple their extension api any further, Firefox will be done for as many users will abandon them in huge droves.
As someone on slashdot commented, "There's enough evil here to really do some damage and screw us all over.".
as an extension author I see it as a huge win. 99% of the code remains same if you develop an extension either for chromium and firefox but making that same extension for safari is pita.
Yeah it's possible Apple is getting on board here because they opened up Safari up a bit but found that people were not beating down their door. I'd be curious to know if you did — I didn't port mine, even though I already have a developer account from my iOS app.
A while back I saw somebody castigated here for suggesting that Mozilla would eventually nerf Firefox's adblockers in service of Google. Does this still seem so ridiculous?
It does, because Mozilla recently put out a statement saying they were going to add Manifest V3 support to Firefox without removing MV2 support. Their stated reason is that MV3's architecture is not robust enough to handle all of MV2's use-cases, ad-blockers being the obvious example.
Firefox has little incentive to nerf ad-blockers, unlike Google. And Google can't flex their default search engine payments to Mozilla without walking into the anti-competitive arena.
For years I've been reading comments like yours, about Google funding Firefox to stave off antitrust shit but this in no way corrupting or compromising Firefox. All the while, Mozilla executives have been getting rich with that funding from Google while cratering Firefox's market-share. I no longer trust Mozilla to act in the best interests of firefox users. Not when their supposed incompetence just happens to align with the commercial interests of their sole^ benefactor
(^ donations to the Mozilla Foundation do not fund Firefox development!)
I wouldn't know how to tease apart specifically Mozilla's management from the technological currents that shape the browser wars. So I just assume they're trying their darndest to have the best browser. Every ounce of market share they pry from Chrome is market share they get to charge Google rent on. Google happens to benefit as well (as already mentioned), so it seems win-win. I don't really view one as having the upper hand on the other.
I hope this doesn’t lead to increased, coordinated censorship and bans across all their extension stores. This is already a problem that reclaim the net (https://reclaimthenet.org/) has written about in the past. While the standardization may start with seemingly innocuous goals, I always fear where centralization and coordination between these actors will lead, since global society is entirely dependent on browsers for public communication and exchange of information.
Because NPAPI was basically a backdoor in the browser which has been abused by malware for a decade, at least. It wasn't safe and it couldn't be upgraded easily.
Also this standard refers to add-ons/extensions, and not "plugins". Browser plugins are dead, and have been for a while.
The safety/stability issue comes from the fact that plug-ins (e.g., NPAPI) are native executables
Browsers started dropping support for plug-ins around 2015. However, plug-ins actually held on longer than you might think. Firefox didn't completely drop support for Flash until the beginning of this year
The problem was that NPAPI was an API for designing libraries that could be linked into the browser and run as if they were the browser's own code.
Fixing security issues when they stem from the browser running arbitrary machine code directly in its address space is several grad-student-years worth of computer science theory and may very well grind up against known-unsolvable problems like the halting problem. Purely hypothetically, you could approach it via solutions such as running a virtual machine inside the browser, but now your browser is actually a virtual machine that happens to connect to the internet. As if browsers weren't already heavyweight and complicated enough. ;) In practice, Firefox and the other browsers on the market didn't do that, and sometimes plug-in code would just crash and take your whole browser down with it. No fun, no fun at all.
In contrast, extensions run on top of the JavaScript sandbox and can only interface to the browser via the JavaScript-accessible API. The whole extensions framework piggybacks on the security work already done to allow untrusted JavaScript code from arbitrary websites to run in the browser.
Not an expert on this part, but I'd imagine that problem isn't having an API, it's more that running native executables is the problem if you can't sandbox them or limit their resource consumption. Also, relative to running Javascript, their base resource utilization per tab is significantly worse (especially for Java or .NET-based ones that have a base resource utilization from the VM)
Security issues is what everyone says is the reason to get rid of plugins. But the tinfoil hat wearer in me says this is just a means to remove more control from the user.
First they "removed" HTTP from most of the web so you couldn't trivially intercept text data flowing between the server and your browser window. Then they removed the ability to run code natively in the browser process that allowed the possibility to alter that data securely whilst maintaining HTTPS security. Next up, things like certificate pinning to prevent you as the user from tampering with the data they want your browser to show you. Then DRM will be added to the browser to start preventing you from intercepting the flow of data to your screen.
This is all happening in slow motion over decade long timescales. But some of us are starting to see how the "endgame" is aligning with the various bits they're pushing slowly over time in small increments.
In addition to the other answers, NPAPI only standardizes the interface between a plugin and the browser. It doesn't standardize the interface between the plugin and the outside world. Want the clipboard? Call the native platform API to get at the clipboard. Want local storage? Call the native platform API to read and write files. Want to make HTTP requests? Link libcurl.
This means that, apart from the (serious) security concerns, none of the behavior is standardized or manageable. How do you apply proxy configuration to a plugin that's bringing its own copy of libcurl? How do you report how much storage a plugin has used?
It's also a huge pain for people on less-popular OSes, because each plugin needs to be individually ported, even though the browser already has figured all these things out for its own use.
So, no, this isn't reinventing NPAPI. It's doing a whole lot of things that NPAPI didn't have answers for.
(Note that the headline is incorrect; the article clearly states they're talking about extensions, not plugins.)
FWIW, here's some feedback I wrote up and sent to Netscape about the original version of the Netscape 2.0b3 plug-in SDK (NPAPI), when I worked at Kaleida. This was from around 1995, when JavaScript was called LiveScript, before anything like LiveConnect/XPConnect/NPRuntime existed, when Netscape though Java was the solution to all their problems, and before ActiveX of course (but I warned them about Microsoft's use of OLE in the browser), so plug-ins only had very limited if any interaction with LiveScript and DOM.
ScriptX was a multimedia scripting language, a lot like object oriented Lisp or Python with built-in graphics and multimedia libraries. But unfortunately it was not designed to be an extension language library that could plug into another application like Netscape, the way Python does so well. So I made a "ScriptX Plug-Out" that integrated ScriptX running in another process with a Netscape plug-in via Apple Events.
>The plug-in interface is totally mime viewer oriented, which is very
limiting, and too narrowly focused. There's no way to do background
plug-ins (even though the documentation claims they're supported,
there's no way to express them through the api), protocol handlers
(like you can already do through the Spyglass Browser Remote Control
interface, but only in another process), or embeded plug-ins that
aren't viewing a file (like a QuickCam viewer plug-in that doesn't need
to read a file since it gets its input from hardware, or my cellular
automata plug-in which can be configured from the html embed properties,
and generates animation algorythmically).
>I hope NetScape can come up with a plug-in interface that is good enough that they can implement their own navigator components with it (like the mail reader, outliner, progressive jpeg viewer, etc). The only way it's going to go anywhere is if they work closely with developers, and use the plug-in interface for non-trivial things themselves. Microsoft already has a VRML plug-in for their navigator, so presumably they have a plug-in interface, and from what I've seen on their web site, it may not be "good enough", but it's probably going to do a lot more that you can do with NetScape right now, since they're exposing a lot of their navigator's functionality through OLE. They seem to understand that there's a much bigger picture, and that the problems aren't trivial. Java isn't going to magically solve all those problems, folks.
For more historical background, here's some stuff I wrote about the browser plugin scene in 1996, including a link to a "pluggers" survey about plug-in technology that I wrote at Interval Research called "An Overview of Plug-In Technology circa March 1996", which describes and compares Spyglass's Browser Remove Control API, NSAPI, ActiveX, Java, JavaScript, etc.
Thanks for this. I really don't like it when stuff gets thrown away but I'm starting to come around why NPAPI had to go... Haven't finished yet but interesting reads.
Browser extensions should not be made an official thing. Some extensions are malicious and even legit ones have too much access to your data.
If plug-ins are made official then companies may choose to provide functionality via plug-ins instead of through regular web-based applications and that's a terrible idea.
Look at the bright side, Google at least discusses some stuff with other companies rather than doing ActiveX or other crap like Microsoft when they had 80%+ of the market.
It's pageantry. Google forced Manifest V3 on the world without consulting the other browsers or the existing WebExtension stakeholders. They did it under a false flag of security and performance, objectives that could have been achieved with MV2 if they wanted. But that wouldn't allow them to neuter ad-blockers.
Their member in this group, Simeon Vincent, won't acknowledge this because his paycheck requires him to not understand it. You could read the last year of the chrome extension google group for countless examples of developers raising issues with MV3 architecture only to be corporate-spoken away by the 800-lb browser gorilla. They aren't listening, but they want you to think they are.
Google does whatever it wants, whenever it wants, as poorly documented as it wants. MV3 still does not have buy-in from extension developers but Google has started the clock on MV2 deprecation. This new group is nothing more than an attempt to get Google to document loudly what they're already doing.
> Google forced Manifest V3 on the world without consulting the other browsers or the existing WebExtension stakeholders.
WebExtensions is still Google's browser API. Mozilla implemented it so they could support Chrome extensions, but they didn't inherit partial ownership as a result of that.
I also think it's premature to say it was "forced on the world" when Manifest V3 isn't even released yet.
The WebExtensions API (promise-based) was created by Mozilla. Whereas “Chrome Extensions” (callback-based) was created by Google.
These are not compatible with each other despite being very similar. The former uses the browser.* namespace and the latter uses the chrome.* namespace
There are implementation differences, but it's not as if they were independent inventions. Mozilla's API is based directly on Chromium's. That itself is fine (because Chromium is open-source), but I don't think a difference like callbacks vs promises makes it a unique product. If that's what you were implying, anyway.
Manifest V3 was released three Chrome versions ago. It doesn't fully work, but Google considers it released. They've also started the clock to MV2 deprecation. Have you? You won't be able to deploy MV2 come April 2022. This working group will still be putting its pants on.
If anyone wants proof Google considers it launched, read the warning on MV2 docs.
>>> The page you're viewing describes extensions using Manifest V2. Now that Manifest V3 has launched, we strongly recommend that you use it for any new extensions that you create.
I was going from memory, and I was sadly too optimistic!
The soonest it could happen is _January_ 2022. [1]
Google intentionally won't set a timeline here because they're more interested in finishing and getting promotions than what's best for users and developers on their platform. So they want to make the period as small as they can get away with. The fact that Google has ignored so many requests for a timeline here should tell you that they are happy letting MV2 die on the earliest stated date. Otherwise they'd communicate a later date when asked!
Right, Blink and WebKit are no longer reliably similar, which is why when devs don’t test on WebKit (to say nothing of Gecko), rendering stuff can reliably break.
They share a ton of history but the split happened eight years ago and A LOT of code has changed. In fairness, WebKit (and thus, Safari) has later adopted some of the same changes, but they really aren’t synonymous anymore.
Blink and Webkit have become separate enough that you can't call them the same in good faith: layout engine is completely different, style engine is different and many other parts have been rewritten in both Blink and Webkit independently of each other.
Also, if you care about browser extensibility, join the w3 group (it's free) and watch the GitHub repo!