> Removed support for Netscape Plugin API (NPAPI) plugins other than Flash. Silverlight, Java, Acrobat and the like are no longer supported.
Good bye, you will be missed (not).
Good bye, you will be missed (not).
I'd like to say they won't be missed, but I've got a state Medicaid portal that uses some annoying Java applet to handle authentication I have no choice but to deal with (I've actually got a little flask web service that uses Selenium and Firefox in Xvfb just to log into the stupid thing and return the authentication cookies, since Chrome ditched NPAPI a while ago and IE isn't a sane option).
I won't be sad when applets finally go away, but that day is not today for me and it's going to really screw things up :/
Even today, Firefox decodes all video (even h264) on CPU.
Which causes, with 4K 60fps video, 50% CPU load on an entire core for me.
The bugs on bugzilla are all marked "WONTFIX", and Linux seems to be an afterthought.
And Mozilla, which explicitly writes
Out of Scope
- Linux testing
Is that a punch line? Because it sounds like one. What is that, like, 6.25% of your total CPU power?
I say this because many people have machines with CPUs that can't decode 4K 60fps video in realtime at all. So your stat sounds like a great deal to me.
Having said that, hardware video decoding is important for this very reason. It's a shame that the situation isn't better on Linux. It seems like, no matter what site or browser--Chrome or Firefox--VLC always plays the same video with far less CPU usage.
Which pushes you beyond what a single core is capable off.
The mpv plugin worked as well for HTML5 video with hardware acceleration.
Now, well, not anymore.
Another internal tool to rewrite from scratch, yay.
> Acrobat and the like are no longer supported.
Is the build in PDF viewer still burning through battery power like the electric heater it turned my laptop into the last time I used it? Been some time so that would be interesting to know.
> Another internal tool to rewrite from scratch, yay.
If you care about security in the slightest, you should probably already have done that.
> > Acrobat and the like are no longer supported.
> Is the build in PDF viewer still burning through battery power like the electric heater it turned my laptop into the last time I used it? Been some time so that would be interesting to know.
You can still use an external reader of your choosing; for example I'm using the marvellous Okular. You just can't use an NPAPI-based PDF reader plugin.
Signed internal only use tool. Not running untrusted applets anywhere. Also no time to rewrite bug free working code.
> You can still use an external reader of your choosing;
So the answer is that it is still that bad? I guess I can just browse the web using wget and less if external tools are the next big thing. /s
These plugins have been click-to-play in the major browsers for a long, long time.
Obviously they still provide some attack surface, but the biggest threats today don't come from plugins, they come from the main browser functionality, thanks in no small part to all the things browsers now have to provide so we can still do useful things that we used to do with plugins.
> > Another internal tool to rewrite from scratch, yay.
> If you care about security in the slightest, you should probably already have done that.
What has one to do with the other
Or, if the application is not strongly coupled to other server-side systems, make it standalone with a Swing, JavaFX or whatever front end.
However, another difficulty with using browser file upload controls was that, for security reasons, programatically (JavaScript) putting a file to upload is forbidden (readonly form attribute) by the respective browser API spec, so in the end the GUI part had to be coded in the Java/applet, too, when the HTML GUI would have been preferable.
So my point is that Java applets in recent years weren't used for GUIs so much as they were used for piercing the browser sandbox, and I don't see a solution for this problem now that applets have gone.
Yes, I'm slightly bitter. I'm starting to think the Suckless guys have the right idea...
Now I have to disable dns entries.
I know, I know.
Still, it means I'll be missing that silverligh support.
Bradesco's fortunately works on any browser.
Many Chinese ecommerce and government sites require their own "security" NPAPI plugins. These don't work in Chrome, but the large majority of users in China run hybrid browsers that use both Blink and Trident (IE) engines so these sites that require NPAPI plugins can be seamlessly loaded in a Trident tab. The user doesn't know the difference.
I doubt they will give up these "security" plugins, so the answer will most probably be an even more invasive system process. It seems that some banks are migrating to Warsaw, which is known for among other things causing problems with IPv6 (http://ipv6.br/post/bug-em-plugin-de-seguranca-de-bancos-blo...).
Are Java applets and Silverlight apps demonstrably less secure than Flash?
Just as a naive metric, if you look at the CVE database, there have been a total of three CVEs for Silverlight last year; whereas for Flash... well, I stopped counting.
I don't know of any bank or government agency that uses Flash, but I certainly know that the Hong Kong government uses Java on some of its websites.
It feels like Mozilla is keeping Flash around just because it's more popular with browser gamers and video watchers. I don't think that's doing the right thing.
That's exactly right. The amount of Flash content dwarfs the amount of other plugin content.
Banning other NPAPI plugins doesn't avoid the Flash security problems but it does avoid the other security problems. It's a step forward, but it's not the final step.
Personally, I'm hoping we see a WebAssembly build of Flash eventually (once WA is featureful enough to support it), at which point the native plugin can die without breaking (as many) old sites.
drm something something...shall I remind spotify web player still uses flash.