General :
K-Meleon Web Browser Forum
Hey there,
Recent news suggest that Firefox/Mozilla will drop the support for NPAPI plugins at the end of 2016:
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
What is Kmeleons point of view on this? Will NPAPI be continued in Kmeleon or dropped as well with new Gecko releases?
--
EL
Does this mean that I will not be able have a pdfviewer plugin in my root\browser\plugins folder? I currently use npPdfViewer.dll from an old Sumatra version.
NPAPI was the netscape plugin API. In the old days it was bringing to us the integration of PDF views, Flash, Java applets and other things. In the past, like 10-15 years ago it was important to have them. Nowadays, most of the tasks which plugins were invented for can be achieved with pure javascript and HTML5, so plugins are not really necessary anymore for, say, 80% of the use cases.
Therefore the mainstream browsers decided to drop NPAPI support entirely. Since September you cannot use plugins anymore with Google chrome, Opera follows soon, and at the end of next year Firefox will remove them as well, according to the blog post I mentioned above. IE is closing its back door to use plugins via an ActiveX bridge as well.
However, there are some use cases that simply cannot be achieved without NPAPI, or just with huge headaches: whenever you have a web application that needs access to resources outside the browser/javascript jail, whenever you need to run native code for accessing hardware or display native windows inside the browser, you need NPAPI. Or an alternative technology that really works as well and is stable enough to take over.
But in the mainstream browsers they don't plan for that. They simply remove NPAPI and decide that users should live without it. Developers and users who have the formerly described use cases are lost. In two years or so there will be no browser left to support plugins, and a really good alternative is not in sight.
Thats why I am looking for browsers that keep NPAPI support. And thats why I am asking here
.
Edited 2 time(s). Last edit at 10/10/2015 07:00PM by EL.
K-Meleon does not develop its own GRE. And that NPAPI is part of the code that is developed by Mozilla.org and used by K-Meleon.org.
As long as Mozilla does not change the API on which the support for NPAPI relies You can probably leave the code there and compile with it.
But that is just my humble opinion as a layman.
When that code is changed?
You'd have to ask Dorian (chief dev / C dev) - it depends how much work it is - maybe?
Firefox wants to drop the support obviously at the end of 2016 in stable. Then there is still the ESR releases, so I think that the code will be for some more time in some certain Gecko releases.
The Gecko in Seamonkey is older, so maybe the NPAPI will be there a few months longer than in the FF-ESR releases (I don't know about Seamonkey's plans regarding NPAPI at all).
Overall, I guess maybe 2 more years until the code is changed?
They also want to make an Exception for Flash, as it seems. If this is still some kind of NPAPI under the hood, the interface is maybe even continued in the source and just hidden to the outside. This would be good...
Seems NPAPI support according to Wikipedia is moved to/replaced by Google NaCL & PEPER by some browser vendors.
https://en.wikipedia.org/wiki/NPAPI
https://en.wikipedia.org/wiki/Google_Native_Client#Pepper
While Mozilla will not move there currently.
epper" rel="nofollow" >https://wiki.mozilla.org/NPAPI
epper
Another round of propriety plugin architectures like started with MS ocx?
p.s. Breaking old plugin support is the same deal that MS had for Netscape plugins support some years ago.
https://web.archive.org/web/20071016233843/http://www.meer.net/jg/broken-plugins.html
That brought me here to k-meleon on my quest to find a browser that still rendered my then favorite pages. Seems user choices do never matter.
Edited 1 time(s). Last edit at 10/11/2015 06:08AM by guenter.
Yes, just by Google. The others follow in some aspects. But NaCl is not the same as NPAPI, and is in one aspect not a valid substitution: there is no access to system calls, not even in a controlled manner. They state that in their self-congratulatory video here:
https://developer.chrome.com/native-client
Somewhere at minute 18:50. And having not even controlled access to system calls is problematic if you want to, say, access proprietary hardware from within web applications or really want users of a web application to have access to the file system etc., and users can trust you.
I mean I agree that NPAPI plugins are unsafe in that they can be used to do harmful things with the system at user space, but that does not mean that this is the sole purpose of plugins. In the same way you could say that every computer program written in C is unsafe, because it can be distributed over the internet and the C API has full access to the system.
Yes and I at least understand that point. Since PPAPI does not really bring an advantage but is to some extend just a reinvention of the wheel with some minor enhancements especially for mobile browsers, there is not really a need to support it for Mozilla. Their main platform is the desktop, still.
But I don't understand why they drop NPAPI support entirely on the other hand side. It has been there from the beginning, and it still fits well in the Mozilla ecosystem. Instead of throwing out the baby with the bath water and dropping the whole NPAPI, they could make it more secure, e.g. by implementing trust mechanisms (only cert signed or reviewed plugins are executed, something like this).
It seems so... I guess the NaCl/PPAPI thing was not really taking off for Google since 5 years or so. Now they try to push it by disabling NPAPI and pay Mozilla to do so as well. Next, Mozilla includes NaCl/PPAPI into their browser eventually after some more years, when their usage share has dropped more significantly.
Then all of a sudden they recognize that system calls are not that entirely bad, and that in some cases it would be really cool to have them. Then they reimplement that in NaCl, and then we have the same as NPAPI, but it looks different, its from Google and the turn over is complete
I am going to link this topic in the developer forum, maybe thats a better place for discussion (didn't know that a developer forum exists).
Hm agreed, that is a use case for sandboxed environments like Nacl/Pepper.
Or for a sandbox on top of NPAPI, which these plugins must use in order to be enabled.
I favour the Tcl plugin, because it implements just that: Tclets are run in safe, sandboxed interpreters, which have no access to the users system at all. So a Tclet cannot do any harm to the system, even if it is exploited. But features outside the sandbox can selectively be enabled (e.g. per source URL), if the user wants it and trusts the respective source. This is good for intranet applications, where the sources can be assumed to be more trustworthy.
General discussion about K-Meleon
NPAPI support in Kmeleon
Posted by:
EL
Date: October 09, 2015 07:47AM
Hey there,
Recent news suggest that Firefox/Mozilla will drop the support for NPAPI plugins at the end of 2016:
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
What is Kmeleons point of view on this? Will NPAPI be continued in Kmeleon or dropped as well with new Gecko releases?
--
EL
Re: NPAPI support in Kmeleon
Posted by:
JamesD
Date: October 10, 2015 02:14PM
Does this mean that I will not be able have a pdfviewer plugin in my root\browser\plugins folder? I currently use npPdfViewer.dll from an old Sumatra version.
Re: NPAPI support in Kmeleon
Posted by:
EL
Date: October 10, 2015 06:51PM
Quote
JamesD
Does this mean that I will not be able have a pdfviewer plugin in my root\browser\plugins folder? I currently use npPdfViewer.dll from an old Sumatra version.
NPAPI was the netscape plugin API. In the old days it was bringing to us the integration of PDF views, Flash, Java applets and other things. In the past, like 10-15 years ago it was important to have them. Nowadays, most of the tasks which plugins were invented for can be achieved with pure javascript and HTML5, so plugins are not really necessary anymore for, say, 80% of the use cases.
Therefore the mainstream browsers decided to drop NPAPI support entirely. Since September you cannot use plugins anymore with Google chrome, Opera follows soon, and at the end of next year Firefox will remove them as well, according to the blog post I mentioned above. IE is closing its back door to use plugins via an ActiveX bridge as well.
However, there are some use cases that simply cannot be achieved without NPAPI, or just with huge headaches: whenever you have a web application that needs access to resources outside the browser/javascript jail, whenever you need to run native code for accessing hardware or display native windows inside the browser, you need NPAPI. Or an alternative technology that really works as well and is stable enough to take over.
But in the mainstream browsers they don't plan for that. They simply remove NPAPI and decide that users should live without it. Developers and users who have the formerly described use cases are lost. In two years or so there will be no browser left to support plugins, and a really good alternative is not in sight.
Thats why I am looking for browsers that keep NPAPI support. And thats why I am asking here
.Edited 2 time(s). Last edit at 10/10/2015 07:00PM by EL.
Re: NPAPI support in Kmeleon
Posted by:
guenter
Date: October 10, 2015 07:42PM
K-Meleon does not develop its own GRE. And that NPAPI is part of the code that is developed by Mozilla.org and used by K-Meleon.org.
As long as Mozilla does not change the API on which the support for NPAPI relies You can probably leave the code there and compile with it.
But that is just my humble opinion as a layman.
When that code is changed?
You'd have to ask Dorian (chief dev / C dev) - it depends how much work it is - maybe?
Re: NPAPI support in Kmeleon
Posted by:
EL
Date: October 10, 2015 09:18PM
Quote
guenter
When that code is changed?
Firefox wants to drop the support obviously at the end of 2016 in stable. Then there is still the ESR releases, so I think that the code will be for some more time in some certain Gecko releases.
The Gecko in Seamonkey is older, so maybe the NPAPI will be there a few months longer than in the FF-ESR releases (I don't know about Seamonkey's plans regarding NPAPI at all).
Overall, I guess maybe 2 more years until the code is changed?
They also want to make an Exception for Flash, as it seems. If this is still some kind of NPAPI under the hood, the interface is maybe even continued in the source and just hidden to the outside. This would be good...
Re: NPAPI support in Kmeleon
Posted by:
guenter
Date: October 11, 2015 06:03AM
Seems NPAPI support according to Wikipedia is moved to/replaced by Google NaCL & PEPER by some browser vendors.
https://en.wikipedia.org/wiki/NPAPI
https://en.wikipedia.org/wiki/Google_Native_Client#Pepper
While Mozilla will not move there currently.
epper" rel="nofollow" >https://wiki.mozilla.org/NPAPI
epper
Another round of propriety plugin architectures like started with MS ocx?
p.s. Breaking old plugin support is the same deal that MS had for Netscape plugins support some years ago.
https://web.archive.org/web/20071016233843/http://www.meer.net/jg/broken-plugins.html
That brought me here to k-meleon on my quest to find a browser that still rendered my then favorite pages. Seems user choices do never matter.
Edited 1 time(s). Last edit at 10/11/2015 06:08AM by guenter.
Re: NPAPI support in Kmeleon
Posted by:
EL
Date: October 11, 2015 12:16PM
Quote
guenter
Seems NPAPI support according to Wikipedia is moved to/replaced by Google NaCL & PEPER by some browser vendors.
https://en.wikipedia.org/wiki/NPAPI
https://en.wikipedia.org/wiki/Google_Native_Client#Pepper
Yes, just by Google. The others follow in some aspects. But NaCl is not the same as NPAPI, and is in one aspect not a valid substitution: there is no access to system calls, not even in a controlled manner. They state that in their self-congratulatory video here:
https://developer.chrome.com/native-client
Somewhere at minute 18:50. And having not even controlled access to system calls is problematic if you want to, say, access proprietary hardware from within web applications or really want users of a web application to have access to the file system etc., and users can trust you.
I mean I agree that NPAPI plugins are unsafe in that they can be used to do harmful things with the system at user space, but that does not mean that this is the sole purpose of plugins. In the same way you could say that every computer program written in C is unsafe, because it can be distributed over the internet and the C API has full access to the system.
Yes and I at least understand that point. Since PPAPI does not really bring an advantage but is to some extend just a reinvention of the wheel with some minor enhancements especially for mobile browsers, there is not really a need to support it for Mozilla. Their main platform is the desktop, still.
But I don't understand why they drop NPAPI support entirely on the other hand side. It has been there from the beginning, and it still fits well in the Mozilla ecosystem. Instead of throwing out the baby with the bath water and dropping the whole NPAPI, they could make it more secure, e.g. by implementing trust mechanisms (only cert signed or reviewed plugins are executed, something like this).
Quote
guenter
Another round of propriety plugin architectures like started with MS ocx?
It seems so... I guess the NaCl/PPAPI thing was not really taking off for Google since 5 years or so. Now they try to push it by disabling NPAPI and pay Mozilla to do so as well. Next, Mozilla includes NaCl/PPAPI into their browser eventually after some more years, when their usage share has dropped more significantly.
Then all of a sudden they recognize that system calls are not that entirely bad, and that in some cases it would be really cool to have them. Then they reimplement that in NaCl, and then we have the same as NPAPI, but it looks different, its from Google and the turn over is complete
I am going to link this topic in the developer forum, maybe thats a better place for discussion (didn't know that a developer forum exists).
Re: NPAPI support in Kmeleon
Posted by:
KM2005
Date: October 11, 2015 04:49PM
The insecurity is not only with plugins built with the intension to be used maliciously. A large part of the insecurty is with widely used internet-intefacing plugins that are regularly exploited, ie Flash, Java, Acrobat Reader--which at times are updated only for security reasons every few weeks, or so.Quote
EL
I mean I agree that NPAPI plugins are unsafe in that they can be used to do harmful things with the system at user space, but that does not mean that this is the sole purpose of plugins. In the same way you could say that every computer program written in C is unsafe, because it can be distributed over the internet and the C API has full access to the system...
Instead of throwing out the baby with the bath water and dropping the whole NPAPI, they could make it more secure, e.g. by implementing trust mechanisms (only cert signed or reviewed plugins are executed, something like this).
Re: NPAPI support in Kmeleon
Posted by:
EL
Date: October 11, 2015 07:14PM
Quote
KM2005
The insecurity is not only with plugins built with the intension to be used maliciously. A large part of the insecurty is with widely used internet-intefacing plugins that are regularly exploited, ie Flash, Java, Acrobat Reader--which at times are updated only for security reasons every few weeks, or so.
Hm agreed, that is a use case for sandboxed environments like Nacl/Pepper.
Or for a sandbox on top of NPAPI, which these plugins must use in order to be enabled.
I favour the Tcl plugin, because it implements just that: Tclets are run in safe, sandboxed interpreters, which have no access to the users system at all. So a Tclet cannot do any harm to the system, even if it is exploited. But features outside the sandbox can selectively be enabled (e.g. per source URL), if the user wants it and trusts the respective source. This is good for intranet applications, where the sources can be assumed to be more trustworthy.
English