[HN Gopher] Apple, Mozilla, Google, Microsoft form group to stan...
___________________________________________________________________
Apple, Mozilla, Google, Microsoft form group to standardize browser
plug-ins
Author : Black101
Score : 399 points
Date : 2021-06-05 11:24 UTC (11 hours ago)
(HTM) web link (appleinsider.com)
(TXT) w3m dump (appleinsider.com)
| simias wrote:
| 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.
| Kiro wrote:
| 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.
| clusterfish wrote:
| And whose fault is that? They reap what they sow.
| thatguy0900 wrote:
| 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.
| ferdowsi wrote:
| It gives Google an ingress to weaken adblocking and privacy
| controls in other browsers.
| stephenr wrote:
| Content Blocking is unrelated to Web Extensions in Safari.
| A4ET8a8uTh0 wrote:
| Is it though? I personally would argue that most of the
| population is not tinfoil enough.
|
| To me, it is fascinating, and terrifying, how quickly
| narratives change and people seem to take that vhange in
| stride.
|
| Admittedly, it does not help that I am now watching mr robot.
| oogabooga123 wrote:
| It was always a lab leak
|
| Everyone knew it was a bad election
|
| We were always at war with Eurasia
| Macha wrote:
| 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-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 wrote:
| 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
| moksly wrote:
| 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.
| phendrenad2 wrote:
| This is so Google can subtly steer the development in ways that
| make YouTube downloaders hard to build, right?
| webmobdev wrote:
| 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."_.
| amelius wrote:
| Can't they standardize web-apps, and allow them in their stores
| etc.?
| tschiller wrote:
| The timeline of browser extensibility is quite fascinating.
| There's really not a single place that covers all of it, so I
| decided to research my own timeline/history: -
| Consumer web browsers (1993-) - Plug-ins (1995-2015ish)
| - User Style Sheets (1998-2019) - Bookmarklets (1998-)
| - Browser Extensions (1999-) - Mozilla XUL (1997-2017)
| - Alternative Browser Distributions (2004-) - Userscripts
| (2005-) - Converging on the WebExtensions API (2017-)
| - Manifest V3 (2021-) - No/Low-Code Browser Extension
| Builders (2021-)
|
| Here's a link to the blog post with my research:
| https://medium.com/brick-by-brick/a-brief-history-of-browser...
|
| Also, if you care about browser extensibility, join the w3 group
| (it's free) and watch the GitHub repo!
| Siira wrote:
| > User Style Sheets (1998-2019)
|
| I'm still using them.
| 63 wrote:
| Agreed. I just made a new one last week.
| branneman wrote:
| Now find some sources to cite with that timeline, and create a
| wikipedia article from it!
| flomo wrote:
| Internet Explorer add-ons (if only because they were kinda a
| scourge)
|
| https://en.wikipedia.org/wiki/List_of_Internet_Explorer_add-...
| amelius wrote:
| Shouldn't Java be somewhere in that list?
| tschiller wrote:
| Java falls under plug-ins. The Java plug-in was released in
| 1998. Flash was released in 1996
| dlhavema wrote:
| Are you referring to applets? Or the webstart(?) thing?
| takeda wrote:
| Both of them were implemented as plugins.
| jamal-kumar wrote:
| Anyone else remember stuff that fizzled out like DHTML?
| toyg wrote:
| DHTML didn't fizz out, people just stopped using the buzzword
| - because everybody uses it pretty much all the time.
| DaiPlusPlus wrote:
| Just like AJAX - it's still a thing: you can't have SPAs
| without it.
| detaro wrote:
| The only thing that fizzled out about that is the name.
| dimal wrote:
| I hadn't realized that user stylesheet support had ended. I
| feel like I should bemoan the loss of user control, but in
| reality, few people used them.
| stephenr wrote:
| $20 says Google removed the feature from Chrome, so a chunk
| of developers consider the feature 'dead', because to them
| "Browsers = Chrome".
| Someone wrote:
| I think Safari on Mac OS has them. If not, what's
| https://support.apple.com/guide/safari/advanced-ibrw1075/mac
| meaning where it says
|
| _"Style sheet
|
| To use your own CSS instead of webpage style sheets, click
| the pop-up menu, then choose Other."_?
| sbuk wrote:
| Still there in 14.1.1...
| tschiller wrote:
| Thanks for the link! Adding this to the list of corrections
| I need to make to the Medium post
| contriban wrote:
| Correct. And the cool part is that it loads the file
| straight from disk. However it offers no Stylish-like UI
| NegativeLatency wrote:
| I currently use a user style sheet on the latest version of
| safari
| amelius wrote:
| I bet there are browser extensions that fill this gap.
| tschiller wrote:
| Yep, the first style manager extension was released in 2005
| (Stylish). Style manager extensions are a much more
| frictionless way to manage and share styles
|
| The WebExtensions API has APIs for injecting styles:
| https://developer.mozilla.org/en-US/docs/Mozilla/Add-
| ons/Web...
| foxpurple wrote:
| Stylish was also found to be malware. This is the problem
| with extensions over browser features. You just can't
| trust them with such critical data.
| Fnoord wrote:
| 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.
| jfrunyon wrote:
| Rip FTP https://chromestatus.com/feature/6246151319715840
| TedDoesntTalk wrote:
| 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.
| shash7 wrote:
| There's still a lot to do, mainly around distribution and
| publishing areas:
|
| - webextensions specific storage apis to return promises but
| chrome still needs callbacks
|
| - A few UI differences between chrome's extension popup and
| firefox's one means you'll need to potentially leave out
| features for one browser.
|
| - csp policies differs between chrome and firefox(and cors
| too I think)
|
| - UX differences between browsers means you'll need to write
| extra code, and maybe a few extra tutorials.
|
| - Difference between how permissions are interpreted on
| different browsers
|
| - Huge huge difference between publishing on chrome vs on
| firefox
|
| - Safari requires xcode, and therefore macos to publish
| TedDoesntTalk wrote:
| 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"
| lstamour wrote:
| That last restriction (Safari requiring Xcode) isn't always
| a limitation, though. Most CI platforms support Mac for
| publishing apps to that platform. For instance, GitHub:
| https://link.medium.com/63hjdbRBQgb and the Safari Web
| Extension command line parts are documented at https://deve
| loper.apple.com/documentation/safariservices/saf...
|
| Plus, you probably still need a Mac or a virtualized Mac
| (for automated tests, for example) because you'll want to
| test your extension with Safari to ensure it works
| correctly.
| contriban wrote:
| 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.
| brutal_chaos_ wrote:
| I think the confusion here is need to own vs need to use.
| jfrunyon wrote:
| You need to own it in order to use it, and you need to
| use it in order to publish an extension for Safari. No
| confusion.
| lstamour wrote:
| 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...
| saagarjha wrote:
| Have you ever looked at the Mac App Store? It is a
| literal dumpster fire.
| herpes wrote:
| Could you give me an example of this please? I'd love to
| see what you're referring to.
| jchook wrote:
| Afaik Chrome does not support the standard, yet Firefox
| supports Chome's API. As a result, most extensions seem to
| use the Chrome API.
|
| Firefox also provides a polyfill to adapt the Chrome API to
| the WebExtensions standard.
|
| More info here: https://developer.mozilla.org/en-
| US/docs/Mozilla/Add-ons/Web...
| TedDoesntTalk wrote:
| > Afaik Chrome does not support the standard
|
| Chrome published the WebExtensions API, not Mozilla.
| Whether or not it's a standard is another question, you
| could call it a defacto standard, but Chrome definitely
| implemented the api that they published.
| SilasX wrote:
| At the end of the day, though, you can't remap keys in a
| fully general way in Firefox[1], so the experience has
| regressed.
|
| [1] Extensions can change it, but they don't take effect
| until the tab for current page has loaded, which often
| defeats the purpose.
| TedDoesntTalk wrote:
| How is that relevant to OP topic?
| sneak wrote:
| 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 wrote:
| 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 wrote:
| Keep in mind that Safari has enough restrictions that
| uBlock Origin developers decided to stop supporting it,
| so ad-blocking is pretty poor there.
| ximm wrote:
| Bookmarklets will die once Content Security Policies will get
| wider adoption, which I really hope will happen soon.
| RHSeeger wrote:
| I sure hope not. I rely on bookmarklets on a regular basis. I
| use them every day.
| jamal-kumar wrote:
| 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
| jfrunyon wrote:
| 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"
| tschiller wrote:
| According to the spec, Bookmarklets should actually be exempt
| from a site's CSP. The reason is that the user's preferences
| should take precedence over a site's preferences
|
| There's an open bug in Firefox about this (because it doesn't
| follow the spec):
| https://bugzilla.mozilla.org/show_bug.cgi?id=866522
| forgotmypw17 wrote:
| Do you know of a replacement for the last resort for
| transforming a web page into something readable for an
| individual with accessibility needs?
| extra88 wrote:
| A browser's built-in Reader Mode (Safari, Mac and mobile,
| Firefox, Edge's Immserive Reader, Chrome has one behind a
| feature flag) can be very helpful when they work. A better
| solution is probably one of the browser extensions, like
| Stylus [0], that enable not just a single user stylesheet
| but the ability to have custom stylesheet's on a per-domain
| basis. On top that personal customization, they can load
| stylesheets others have already created and shared on
| userstyles.org [1].
|
| [0]
| https://en.wikipedia.org/wiki/Stylus_(browser_extension)
| [1] https://userstyles.org
| npteljes wrote:
| Firefox's Reader Mode maybe?
| wwweston wrote:
| Bookmarklets are exempt from CSP by spec.
|
| And as far as I can tell, they should be. They're a natural
| intermediate step between nothing and extensions, and there's
| not really security problems they have that extensions don't.
|
| If there's a problem here, it's that browsers (some, at
| least) aren't following the spec.
| Kiro wrote:
| How does CSP affect bookmarklets?
| extra88 wrote:
| 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.
| flowerlad wrote:
| 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-yo...
| filmgirlcw wrote:
| 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.
| xnx wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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://play.google.com/store/apps/details?id=com.kiwibrowse...
| xnx wrote:
| 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].
| gnicholas wrote:
| Insight Browser [1] supports extensions also, though not
| straight out of the Chrome store. They're on iOS now and I
| think coming to Android soon.
|
| I worked with them to get the BeeLine Reader extension
| available on their browser, and now Insight is my go-to
| mobile browser.
|
| 1: http://www.insightbrowser.com
| syshum wrote:
| If Google demands Firefox limit the capabilities then that is
| what will happen.
|
| Google is Microsoft in the 90's when it comes to the browser
| but sadly there is no one to stand up to them like Mozilla did
| to MS/IE.
| jsnell wrote:
| 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.
| btown wrote:
| This is their charter:
| https://github.com/w3c/webextensions/blob/main/charter.md
|
| And the twitter announcement from the co-chair:
| 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.
| alanpearce wrote:
| This is about extensions, not plugins. The latter would include
| Widevine, H264 and previously Flash.
| chrisseaton wrote:
| > This is about extensions, not plugins.
|
| What's the difference between an 'extension' and a 'plugin' in
| your eyes? These words seem semantically indistinguishable.
| neogodless wrote:
| 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.
| geofft wrote:
| "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.
| DonHopkins wrote:
| 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.)
|
| https://en.wikipedia.org/wiki/HTML_Components
|
| https://docs.microsoft.com/en-us/previous-
| versions//ms531018...
|
| http://lua-users.org/lists/lua-l/2007-03/msg00047.html
|
| LiveConnect:
|
| https://techmonitor.ai/techonology/netscape_ships_liveconne
| c...
|
| 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.
|
| http://medialab.di.unipi.it/web/doc/JavaScriptGuide/livecon
| ....
|
| Chapter 5. LiveConnect
|
| 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.
| meragrin_ wrote:
| 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.
| geofft wrote:
| 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.
| pndy wrote:
| 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
| chrisseaton wrote:
| 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?
| soapdog wrote:
| 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 wrote:
| 'Plugin' in this context refers to NPAPI or PPAPI.
| sirn wrote:
| 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 wrote:
| 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.
| Angostura wrote:
| Not having DRM in-browser would jut mean having to
| download separate applications for each service, most
| like.
| anoncake wrote:
| Good. That would make DRM-infested services less
| convenient and therefore less popular.
| DonHopkins wrote:
| 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:
|
| https://www.oreilly.com/library/view/python-
| in-a/97814919138...
|
| 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. [...]
|
| https://docs.python.org/3/extending/index.html
|
| >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.
| neogodless wrote:
| It's also incredible that the article has the word "extension"
| nine times, and the word "plug-in" zero times, but they throw
| that in the headline.
| tyingq wrote:
| 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 wrote:
| 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.
| phendrenad2 wrote:
| 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.
| MegaDeKay wrote:
| 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 wrote:
| > 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...
| marcodiego wrote:
| 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 wrote:
| Well Microsofts browser now basically chrome now, most chrome
| extensions are compatible.
| jerrygoyal wrote:
| 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.
| dajonker wrote:
| 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.
| throwawaysea wrote:
| 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.
| flowerlad wrote:
| 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 wrote:
| I believe the article is referred browser extensions as plug-
| ins.
| vbezhenar wrote:
| I'd prefer Discord extension rather than Discord app.
| tambourine_man wrote:
| Extensions, not plugins. Think Adblocker, not Flash/Java
| wearywanderer wrote:
| 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 wrote:
| 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.
| altdataseller wrote:
| I hope this means extensions won't be able to track the websites
| you visit.
| mirekrusin wrote:
| Google will surely lobby for that together with extensions that
| remove their own ads.
| hmble wrote:
| Does this mean we can use adblockers on firefox ios in future ?
| Juntu wrote:
| 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 ::/(
| [deleted]
| dartharva wrote:
| Uh oh. Does this mean ad blockers are in danger?
| RedShift1 wrote:
| Why did we need to get rid of NPAPI? This looks like we're re-
| inventing the wheel again?
| DonHopkins wrote:
| NSAPI was horrible in many ways from day one.
|
| 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.
|
| https://donhopkins.com/home/archive/netscape/Netscape-Plugin...
|
| >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.
|
| https://news.ycombinator.com/item?id=19837817
|
| https://donhopkins.com/home/interval/pluggers
|
| https://donhopkins.com/home/interval/pluggers/navigator.html
|
| https://donhopkins.com/home/interval/pluggers/java.html
|
| https://donhopkins.com/home/interval/pluggers/requirements.h...
|
| https://donhopkins.com/home/interval/pluggers/problems.html
| RedShift1 wrote:
| 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.
| geofft wrote:
| 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.)
| qalmakka wrote:
| 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 wrote:
| 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 wrote:
| Could we not have fixed those security issues? What was so
| structurally wrong with NPAPI that it had to go?
| tschiller wrote:
| 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)
| zo1 wrote:
| 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.
| shadowgovt wrote:
| 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.
| Sargos wrote:
| 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?
| zzo38computer wrote:
| 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 wrote:
| 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.
| syshum wrote:
| XUL was still the best, and Web Extensions will never be a good
| as XUL was
| justinhj wrote:
| Great. I'll look forward to the most useful ones getting banned
| on all the browsers at the same time
| hfktnrjek wrote:
| 4 companies, yet only two browsers* between them, with one
| holding 85%+ of the market.
|
| * yes, I know they only share the engine
| SuchAnonMuchWow wrote:
| 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 wrote:
| At least two of them (Edge/Chrome) have extensions that are
| interchangable.
| cm2187 wrote:
| And of which, one which 100%-ish of its revenues are coming
| from the other.
| lbotos wrote:
| Wait,
|
| Safari == webkit
|
| FF == Gecko
|
| Google == Chromium
|
| Microsoft == Chromium
|
| Right?
|
| So 3 Engines?
| IceWreck wrote:
| Chromium is forked from Webkit so the two share a lot of code
| no_way wrote:
| 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.
| stingraycharles wrote:
| 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 wrote:
| 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.
| zwily wrote:
| WebKit and Chromium split so long ago, i don't really think you
| can call them the same engine anymore.
| ozim wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| somehnacct3757 wrote:
| 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.
| tech234a wrote:
| Where did you find the April 2022 date? I couldn't find a
| depreciation timeline for MV2 anywhere.
| somehnacct3757 wrote:
| 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!
|
| [1] https://groups.google.com/a/chromium.org/g/chromium-
| extensio...
| somehnacct3757 wrote:
| 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.
|
| https://developer.chrome.com/docs/extensions/mv2/
| jannes wrote:
| 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
| SquareWheel wrote:
| 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.
| edlebert wrote:
| Also, the engine has little-to-nothing to do with the plugin
| system.
| devfatigue wrote:
| 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.
| avipars wrote:
| Finally!!
|
| just missing those brave devs
| ksec wrote:
| 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-
| mo...
|
| [2] https://www.cnet.com/news/chrome-safari-firefox-and-edge-
| joi...
___________________________________________________________________
(page generated 2021-06-05 23:01 UTC)