4 ms·

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.
  - zo1 5y ago
    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.
DonHopkins 5y ago
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-API-Feedback.txt 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://news.ycombinator.com/item?id=19837817 https://donhopkins.com/home/interval/pluggers https://donhopkins.com/home/interval/pluggers https://donhopkins.com/home/interval/pluggers/navigator.html https://donhopkins.com/home/interval/pluggers/navigator.html https://donhopkins.com/home/interval/pluggers/java.html https://donhopkins.com/home/interval/pluggers/java.html https://donhopkins.com/home/interval/pluggers/requirements.html https://donhopkins.com/home/interval/pluggers/requirements.h... https://donhopkins.com/home/interval/pluggers/problems.html https://donhopkins.com/home/interval/pluggers/problems.html
geofft 5y ago
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.)

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

DonHopkins 5y ago

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-API-Feedback.txt 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://news.ycombinator.com/item?id=19837817 https://donhopkins.com/home/interval/pluggers https://donhopkins.com/home/interval/pluggers https://donhopkins.com/home/interval/pluggers/navigator.html https://donhopkins.com/home/interval/pluggers/navigator.html https://donhopkins.com/home/interval/pluggers/java.html https://donhopkins.com/home/interval/pluggers/java.html https://donhopkins.com/home/interval/pluggers/requirements.html https://donhopkins.com/home/interval/pluggers/requirements.h... https://donhopkins.com/home/interval/pluggers/problems.html https://donhopkins.com/home/interval/pluggers/problems.html

geofft 5y ago

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