15 ms·

Apple, Mozilla, Google, Microsoft form group to standardize browser plug-ins

462 points by Black101 5y ago

flowerlad 5y ago
This is ActiveX all over again. 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.
- shash7 5y ago
  I believe the article is referred browser extensions as plug-ins.
- vbezhenar 5y ago
  I'd prefer Discord extension rather than Discord app.
hfktnrjek 5y ago
4 companies, yet only two browsers* between them, with one holding 85%+ of the market. * yes, I know they only share the engine
- zwily 5y ago
  WebKit and Chromium split so long ago, i don’t really think you can call them the same engine anymore.
- edlebert 5y ago
  Also, the engine has little-to-nothing to do with the plugin system.
- SuchAnonMuchWow 5y ago
  to be fair, the way plugins/addons are handled in a browser is a part where browser differs completely despite having the same engine
  - efdee 5y ago
    At least two of them (Edge/Chrome) have extensions that are interchangable.
- lbotos 5y ago
  Wait, Safari == webkit FF == Gecko Google == Chromium Microsoft == Chromium Right? So 3 Engines?
  - IceWreck 5y ago
    Chromium is forked from Webkit so the two share a lot of code
    - stingraycharles 5y ago
      But they have diverged so long ago, they are for all practical purposes different rendering engines. It’s not the same deal as, say, Chrome and Edge.
      - filmgirlcw 5y ago
        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.
    - no_way 5y ago
      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.
- ozim 5y ago
  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.
  - somehnacct3757 5y ago
    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.
    - SquareWheel 5y ago
      > 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.
      - jannes 5y ago
        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
- cm2187 5y ago
  And of which, one which 100%-ish of its revenues are coming from the other.
xnx 5y ago
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.
- swiley 5y ago
  There's no way mobile computing will improve; there's too much money to be made taking advantage of the people that don't understand their devices.
  - kennywinker 5y ago
    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
    - swiley 5y ago
      Mobile computing has regressed but there have been almost no technological improvements (outside of incremental hardware improvements.) Lots of social integration (like payments) but really there hasn't been any real technical innovation for about a decade.
      - rsanek 5y ago
        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).
- nathanasmith 5y ago
  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. https://github.com/kiwibrowser https://github.com/kiwibrowser https://play.google.com/store/apps/details?id=com.kiwibrowser.browser&hl=en_US&gl=US https://play.google.com/store/apps/details?id=com.kiwibrowse...
alanpearce 5y ago
This is about extensions, not plugins. The latter would include Widevine, H264 and previously Flash.
- chrisseaton 5y ago
  > This is about extensions, not plugins. What's the difference between an 'extension' and a 'plugin' in your eyes? These words seem semantically indistinguishable.
  - soapdog 5y ago
    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.
  - wearywanderer 5y ago
    'Plugin' in this context refers to NPAPI or PPAPI.
  - sirn 5y ago
    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.
    - azalemeth 5y ago
      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.
tyingq 5y ago
I'm curious if this makes it more, or less likely that extensions will be crippled in the near future. Google's "manifest v3", for example.
- Ayesh 5y ago
  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.
  - MegaDeKay 5y ago
    Some did come back over time though as additional APIs were added from what was there initially: epubreader and DownThenAll! being a couple examples.
    - iggldiggl 5y ago
      > additional APIs [...] DownThenAll! 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...
  - phendrenad2 5y ago
    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.
wearywanderer 5y ago
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?
- somehnacct3757 5y ago
  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.
  - wearywanderer 5y ago
    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!)
    - somehnacct3757 5y ago
      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.
RedShift1 5y ago
Why did we need to get rid of NPAPI? This looks like we're re-inventing the wheel again?
- qalmakka 5y ago
  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.
  - tschiller 5y ago
    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
  - RedShift1 5y ago
    Could we not have fixed those security issues? What was so structurally wrong with NPAPI that it had to go?
    - tschiller 5y ago
      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)
    - shadowgovt 5y ago
      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.
webmobdev 5y ago
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.".
tschiller 5y 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-extensibility-bcfeb4181c9a 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!
- TedDoesntTalk 5y ago
  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.
  - sneak 5y ago
    Malicious extensions, as well as the ability to block the browser vendor’s ads still pose a problem to these groups to be solved.
    - techdragon 5y ago
      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.
      - contriban 5y ago
        Keep in mind that Safari has enough restrictions that uBlock Origin developers decided to stop supporting it, so ad-blocking is pretty poor there.
filmgirlcw 5y ago
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.
marcodiego 5y ago
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.
- patmorgan23 5y ago
  Well Microsofts browser now basically chrome now, most chrome extensions are compatible.
altdataseller 5y ago
I hope this means extensions won’t be able to track the websites you visit.
- mirekrusin 5y ago
  Google will surely lobby for that together with extensions that remove their own ads.
simias 5y ago
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.
- Macha 5y ago
  Does this make a meaningful change? 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-best-on-Firefox 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.
  - whereistimbo 5y ago
    I hope background pages is still available for manifest v3 at least in firefox as service worker still has limitation in comparison: [meta] Deprecate background pages in favor of service workers: https://bugzilla.mozilla.org/show_bug.cgi?id=1578286 https://bugzilla.mozilla.org/show_bug.cgi?id=1578286
    - Guidii 5y ago
      What specific limitations concern you?
- ferdowsi 5y ago
  It gives Google an ingress to weaken adblocking and privacy controls in other browsers.
btown 5y ago
This is their charter: https://github.com/w3c/webextensions/blob/main/charter.md https://github.com/w3c/webextensions/blob/main/charter.md And the twitter announcement from the co-chair: https://twitter.com/xeenon/status/1400862543673921536 https://twitter.com/xeenon/status/1400862543673921536 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.
deleted 5y ago
[deleted]
ksec 5y ago
It is Browser Extensions, not Plug In. There are much better source than Appleinsider. May be 9to5mac [1] or CNet [2]. And you still have to paid $99 /year to publish or get it to work on Safari. Edit: Less Rant-ish. [1] https://9to5mac.com/2021/06/04/apple-teams-up-with-google-mozilla-and-microsoft-to-improve-universal-web-browser-extensions/ https://9to5mac.com/2021/06/04/apple-teams-up-with-google-mo... [2] https://www.cnet.com/news/chrome-safari-firefox-and-edge-join-forces-to-improve-browser-extensions/ https://www.cnet.com/news/chrome-safari-firefox-and-edge-joi...
devfatigue 5y ago
Chrome standard is good enough and the other browsers that aren't chromium based should suck it up and implement their spec. Next if you didn't code it in vanilla js, you probably shouldn't use on your daily driver browser because of the massive security risk.
phendrenad2 5y ago
This is so Google can subtly steer the development in ways that make YouTube downloaders hard to build, right?
hmble 5y ago
Does this mean we can use adblockers on firefox ios in future ?
zzo38computer 5y ago
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.
- kennywinker 5y ago
  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 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.
jerrygoyal 5y ago
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.
- gnicholas 5y ago
  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.
  - jerrygoyal 5y ago
    interestingly, none of my users asked for safari extension.
flowerlad 5y ago
The Case for Limiting Your Browser Extensions "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." https://krebsonsecurity.com/2020/03/the-case-for-limiting-your-browser-extensions/ https://krebsonsecurity.com/2020/03/the-case-for-limiting-yo...
Sargos 5y ago
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?
throwawaysea 5y ago
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/ 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.
dartharva 5y ago
Uh oh. Does this mean ad blockers are in danger?
justinhj 5y ago
Great. I’ll look forward to the most useful ones getting banned on all the browsers at the same time
tambourine_man 5y ago
Extensions, not plugins. Think Adblocker, not Flash/Java
Juntu 5y ago
Plug ins and updates are standards needs of one program to for it to function giving or pasting that then coding it after will work. Its just the same as Macintosh and apple but two different ai when cortana is one another is made a human being self robot voice activated coding infusion gives plug ins of browsers the highest pleasure. Maxed out ::/(
avipars 5y ago
Finally!! just missing those brave devs
syshum 5y ago
XUL was still the best, and Web Extensions will never be a good as XUL was
amelius 5y ago
Can't they standardize web-apps, and allow them in their stores etc.?
dajonker 5y ago
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.
- irae 5y ago
  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.
chunsj 5y ago
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.
JoeyBananas 5y ago
Hold up. I thought webExtensions already was an effort to standardize browser addons
jangid 5y ago
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.
rambojazz 5y ago
Is this a 2021 news? The "webextensions" API has been talked about for years already.

462 points by Black101 5y ago

This is ActiveX all over again. 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.

shash7 5y ago
I believe the article is referred browser extensions as plug-ins.
vbezhenar 5y ago
I'd prefer Discord extension rather than Discord app.

hfktnrjek 5y ago

4 companies, yet only two browsers* between them, with one holding 85%+ of the market. * yes, I know they only share the engine

zwily 5y ago
WebKit and Chromium split so long ago, i don’t really think you can call them the same engine anymore.
edlebert 5y ago
Also, the engine has little-to-nothing to do with the plugin system.
SuchAnonMuchWow 5y ago
to be fair, the way plugins/addons are handled in a browser is a part where browser differs completely despite having the same engine
- efdee 5y ago
  At least two of them (Edge/Chrome) have extensions that are interchangable.
lbotos 5y ago
Wait, Safari == webkit FF == Gecko Google == Chromium Microsoft == Chromium Right? So 3 Engines?
- IceWreck 5y ago
  Chromium is forked from Webkit so the two share a lot of code
  - stingraycharles 5y ago
    But they have diverged so long ago, they are for all practical purposes different rendering engines. It’s not the same deal as, say, Chrome and Edge.
    - filmgirlcw 5y ago
      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.
  - no_way 5y ago
    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.
ozim 5y ago
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.
- somehnacct3757 5y ago
  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.
  - SquareWheel 5y ago
    > 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.
    - jannes 5y ago
      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
cm2187 5y ago
And of which, one which 100%-ish of its revenues are coming from the other.

xnx 5y ago

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.

swiley 5y ago
There's no way mobile computing will improve; there's too much money to be made taking advantage of the people that don't understand their devices.
- kennywinker 5y ago
  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
  - swiley 5y ago
    Mobile computing has regressed but there have been almost no technological improvements (outside of incremental hardware improvements.) Lots of social integration (like payments) but really there hasn't been any real technical innovation for about a decade.
    - rsanek 5y ago
      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).
nathanasmith 5y ago
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. https://github.com/kiwibrowser https://github.com/kiwibrowser https://play.google.com/store/apps/details?id=com.kiwibrowser.browser&hl=en_US&gl=US https://play.google.com/store/apps/details?id=com.kiwibrowse...

alanpearce 5y ago

This is about extensions, not plugins. The latter would include Widevine, H264 and previously Flash.

chrisseaton 5y ago
> This is about extensions, not plugins. What's the difference between an 'extension' and a 'plugin' in your eyes? These words seem semantically indistinguishable.
- soapdog 5y ago
  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.
- wearywanderer 5y ago
  'Plugin' in this context refers to NPAPI or PPAPI.
- sirn 5y ago
  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.
  - azalemeth 5y ago
    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.

tyingq 5y ago

I'm curious if this makes it more, or less likely that extensions will be crippled in the near future. Google's "manifest v3", for example.

Ayesh 5y ago
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.
- MegaDeKay 5y ago
  Some did come back over time though as additional APIs were added from what was there initially: epubreader and DownThenAll! being a couple examples.
  - iggldiggl 5y ago
    > additional APIs [...] DownThenAll! 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...
- phendrenad2 5y ago
  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.

wearywanderer 5y ago

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?

somehnacct3757 5y ago
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.
- wearywanderer 5y ago
  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!)
  - somehnacct3757 5y ago
    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.

RedShift1 5y ago

Why did we need to get rid of NPAPI? This looks like we're re-inventing the wheel again?

qalmakka 5y ago
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.
- tschiller 5y ago
  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
- RedShift1 5y ago
  Could we not have fixed those security issues? What was so structurally wrong with NPAPI that it had to go?
  - tschiller 5y ago
    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)
  - shadowgovt 5y ago
    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.

webmobdev 5y ago

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.".

tschiller 5y 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-extensibility-bcfeb4181c9a 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!

TedDoesntTalk 5y ago
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.
- sneak 5y ago
  Malicious extensions, as well as the ability to block the browser vendor’s ads still pose a problem to these groups to be solved.
  - techdragon 5y ago
    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.
    - contriban 5y ago
      Keep in mind that Safari has enough restrictions that uBlock Origin developers decided to stop supporting it, so ad-blocking is pretty poor there.

filmgirlcw 5y ago

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.

marcodiego 5y ago

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.

patmorgan23 5y ago
Well Microsofts browser now basically chrome now, most chrome extensions are compatible.

altdataseller 5y ago

I hope this means extensions won’t be able to track the websites you visit.

mirekrusin 5y ago
Google will surely lobby for that together with extensions that remove their own ads.

simias 5y ago

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.

Macha 5y ago
Does this make a meaningful change? 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-best-on-Firefox 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.
- whereistimbo 5y ago
  I hope background pages is still available for manifest v3 at least in firefox as service worker still has limitation in comparison: [meta] Deprecate background pages in favor of service workers: https://bugzilla.mozilla.org/show_bug.cgi?id=1578286 https://bugzilla.mozilla.org/show_bug.cgi?id=1578286
  - Guidii 5y ago
    What specific limitations concern you?
ferdowsi 5y ago
It gives Google an ingress to weaken adblocking and privacy controls in other browsers.

btown 5y ago

This is their charter: https://github.com/w3c/webextensions/blob/main/charter.md https://github.com/w3c/webextensions/blob/main/charter.md And the twitter announcement from the co-chair: https://twitter.com/xeenon/status/1400862543673921536 https://twitter.com/xeenon/status/1400862543673921536 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.

deleted 5y ago

[deleted]

ksec 5y ago

It is Browser Extensions, not Plug In. There are much better source than Appleinsider. May be 9to5mac [1] or CNet [2]. And you still have to paid $99 /year to publish or get it to work on Safari. Edit: Less Rant-ish. [1] https://9to5mac.com/2021/06/04/apple-teams-up-with-google-mozilla-and-microsoft-to-improve-universal-web-browser-extensions/ https://9to5mac.com/2021/06/04/apple-teams-up-with-google-mo... [2] https://www.cnet.com/news/chrome-safari-firefox-and-edge-join-forces-to-improve-browser-extensions/ https://www.cnet.com/news/chrome-safari-firefox-and-edge-joi...

devfatigue 5y ago

Chrome standard is good enough and the other browsers that aren't chromium based should suck it up and implement their spec. Next if you didn't code it in vanilla js, you probably shouldn't use on your daily driver browser because of the massive security risk.

phendrenad2 5y ago

This is so Google can subtly steer the development in ways that make YouTube downloaders hard to build, right?

hmble 5y ago

Does this mean we can use adblockers on firefox ios in future ?

zzo38computer 5y ago

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.

kennywinker 5y ago
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 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.

jerrygoyal 5y ago

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.

gnicholas 5y ago
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.
- jerrygoyal 5y ago
  interestingly, none of my users asked for safari extension.

flowerlad 5y ago

The Case for Limiting Your Browser Extensions "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." https://krebsonsecurity.com/2020/03/the-case-for-limiting-your-browser-extensions/ https://krebsonsecurity.com/2020/03/the-case-for-limiting-yo...

Sargos 5y ago

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?

throwawaysea 5y ago

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/ 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.

dartharva 5y ago

Uh oh. Does this mean ad blockers are in danger?

justinhj 5y ago

Great. I’ll look forward to the most useful ones getting banned on all the browsers at the same time

tambourine_man 5y ago

Extensions, not plugins. Think Adblocker, not Flash/Java

Juntu 5y ago

Plug ins and updates are standards needs of one program to for it to function giving or pasting that then coding it after will work. Its just the same as Macintosh and apple but two different ai when cortana is one another is made a human being self robot voice activated coding infusion gives plug ins of browsers the highest pleasure. Maxed out ::/(

avipars 5y ago

Finally!! just missing those brave devs

syshum 5y ago

XUL was still the best, and Web Extensions will never be a good as XUL was

amelius 5y ago

Can't they standardize web-apps, and allow them in their stores etc.?

dajonker 5y ago

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.

irae 5y ago
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.

chunsj 5y ago

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.

JoeyBananas 5y ago

Hold up. I thought webExtensions already was an effort to standardize browser addons

jangid 5y ago

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.

rambojazz 5y ago

Is this a 2021 news? The "webextensions" API has been talked about for years already.