Slashdot Mirror
Ask Slashdot: Options After Google Chrome Discontinues NPAPI Support?
An anonymous reader writes: I've been using Google Chrome almost exclusively for more than 3 years. I stopped using Mozilla Firefox because it was becoming bloated and slow, and I migrated all my bookmarks etc. to Chrome. Now Chrome plans to end NPAPI support — which means that I will not be able to access any sites that use Java, and I need this for work. I tried going back to Firefox for a couple of days but it still seems slow — starting it takes time, even the time taken to load a page seems more than Chrome. So what are my options now? Export all my bookmarks and go back to Mozilla Firefox and just learn to live with the performance drop? Or can I tweak Firefox performance in any way? FWIW, I am on a Windows 7 machine at work.
Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.
It is a mistake to discontinue the NPAPI: there are *lots* of commercial/corporate/etc. plugins using it (!)
Keep an older copy of Chrome around?
Manual installs always offer this as an option, if you have disabled the autoupdate (which sucks a ton of bandwidth anyway).
If your Firefox install and profile are reasonably old, you'll probably have a bunch of cruft. Start fresh (reinstall and start a new profile), import bookmarks, install only the addons you need. Should be plenty fast after that.
Only problem is that it seems for every new version that comes out, you have to install more and more addons just to keep the browser the same. You could always just use Firefox only when accessing a site that requires java, and use another browser for everything else.
auto-disable and minute long startup times, I haven't seen a java web page in years.
It's interesting to note that while CS departments are pushing ever more extreme forms of static typing, javascript has won in the most used platform. They never seem to notice that.
http://lifehacker.com/turn-on-... I've noticed a speed bump doing that, and the usual addons for ad blocking etc.
http://chimpbox.us
While it's a good idea to push the discontinuation of NPAPI, I think Google are being too aggressive in their phase out. ... and they'll end up shooting themselves in the foot.
Hasn't stopped them before. Google could give a shit really about what the developers and customers want with Chrome. Just like the BS they introduced with the walled garden approach. Thousands of "don't do it's" were ignored.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
From the Chromium Blog:
In April 2015 NPAPI support will be disabled by default in Chrome and we will unpublish extensions requiring NPAPI plugins from the Chrome Web Store. Although plugin vendors are working hard to move to alternate technologies, a small number of users still rely on plugins that haven’t completed the transition yet. We will provide an override for advanced users (via chrome://flags/#enable-npapi) and enterprises (via Enterprise Policy) to temporarily re-enable NPAPI while they wait for mission-critical plugins to make the transition.
Yet people are happily using insecure bug-ridden flash crap every day.
Tweak firefox with:
new tab, type "about:config" into the address bar.
find "network.http.pipelining" and set it to "true"
find "network.http.pipelining.max-optimistic-requests" and set it to 8
find "network.http.pipelining.max.requests" and set it to 32 if it isn't that already. Don't take this one too high.
They sentenced me to twenty years of boredom
Hell must have frozen over. People on Slashdot are actually *recommending* Internet Explorer.
Google announced in September 2013 that it would phase out NPAPI support in Chrome during 2014.
NPAPI support is disabled by default since April 2015 (version 42) for Windows and OS X, but can be turned on in the settings.
Google plans to drop Chrome NPAPI support from all platforms in September 2015.
I wont call 2 years warning aggressive. I would call it more then a fair warning.
And if web-apps or plug-in's are not up to modern standards by now. Then extending to time they have to fix it wont help. Because the only things that's not updated by now wont be as long as they do not have to.
Now they are being forced to do it. And it comes as a chock for some that they only got 2 years warning.
Per the Java support site, go here: chrome://flags/#enable-npapi
They probably won't support enabling it forever, but for now it's a workaround.
Good point. They'll probably just charge forward without caring who they leave behind.
But things like this is why corporate IT is still clinging to Windows XP and IE8 in droves. They'd rather stick with what's installed and working than spending the time and money to upgrade.
This is only a problem because you insist that everything happen in one piece of software. That is not a requirement, or at least not one you shared with us.
If you want to complete a task that requires a particular piece of software, use the required software for that task. Then use whatever software you want for all other tasks. This will not only let you use the browser you want for most things, but will let you optimize the NPAPI browser for that particular use without worrying about security and updates and whatnot.
It didn't happen if there are no pictures. Seriously, I can't image that Chrome is 10% faster or slower loading web pages than Firefox. Let's see some hard data showing that Firefox is slower.
You did get the part where he's talking about using Java for work, in a secure environment, yes? You aren't seriously claiming that everyone that uses SuperMicro servers doesn't care about security because their IPMI interface is a Java webstart application, are you?
I mean, for my own part, I have two choices when doing hardware tests of our appliance builds: I can drive across the Twin Cities from my home office and stand at the R&D rack in a cold and noisy staging area for several kickstart/chef bootstrap/chef converge cycles. Conversely I, as a professional, can assume the risk of using a Java IPMI interface to access a server I physically took from a box and placed in the rack of a secured staging room over a secured subnet accessed over a secured VPN connection on my development VM (with a weekly maintenance snapshot, taken every Monday morning, which I don't hesitate reverting to 'cause SystemD, but that's another story), using HTTPS with the SSL cert from that box I physically placed in the rack.
If you are somehow cracking past all those barriers into the imaging subnet of our R&D department's subnet, you've already got half a dozen usernames and passwords and have changed a cert that lives on a box whose OS has an average lifespan on the order of an hour (that is, owning that box isn't incredibly useful in and of itself). Even at that point, the new SSL cert is going to tip me off. But if somehow you managed to get past all that, with all that knowledge just to infect my desktop VM, it seems to me that you already have the keys to the kingdom, so to speak.
That is all to say, just because someone has, or even chooses, to use Java doesn't mean they don't care about security. I'm sure I don't need to explain to you of all people (I read your username and it immediately rang a bell; a quick Google search confirmed my suspicion - I run a lot of code you wrote, and most likely vice versa but to a much lesser degree)that security is about defense in layers, attack surface, vectors and risk/reward. I'm sure there are plenty of other people that use Java in their professional lives that understand and accept the risk of how and where they use it.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
How about users of enterprise software, managed switches, Cisco gear, and embedded appliances for whom their shiny Windows 7/8/10 (for those corps that would run 8 or 10 - I'm sure they exist somewhere), Fedora 22, Mac OSX-latest still can't access said software, hardware, appliances? You do understand that I didn't write SuperMicro's Java interface and I'm not at will to upgrade to software that doesn't exist on something I didn't make regardless of how shiny my frakkin' operating system is, right?
You are correct, however about not being "forced" to do anything. What is going to happen is that when all of our stuff stops working on Chrome, we'll all use Internet Explorer because that's all that will work and IT will start enforcing it. Meaning I can count on the day where IT officially won't support my Linux laptop even though they turn a blind eye right now because I can operate without Windows. Same goes for my boss that runs a Mac.
It's a win for management who have been taking a political beating/PR hit for the move from Google Accounts for Domains (or whichever the enterprise suite is) to strictly Microsoft though. Which is a bit troubling since prior to acquisition there was hushed talk about the new management not being too keen on us in the R&D department using, writing and contributing to open source projects.
In summary, breaking an interface to other things breaks stuff on ALL supported platforms, because end users can't upgrade software they didn't write or compel their upstream provider to care what Chrome does; it doesn't matter what version of which operating system you're running. There are also unintended consequences for breaking stuff that corporate customers use, and those of us that have a foothold with Open Source in the company are collateral damage.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Enabling NPAPI in Chrome Version 42 and later As of Chrome Version 42, an additional configuration step is required to continue using NPAPI plugins. In your URL bar, enter: chrome://flags/#enable-npapi Click the Enable link for the Enable NPAPI configuration option. Click the Relaunch button that now appears at the bottom of the configuration page.
All except PNaCL, which most npapi plugins could be recompiled to within a few days work...
Not exactly. PNaCl plugin run in a restricted sandbox, they are severly limited into what they can execute and which API they can call.
That's not the case with NPAPI: an NPAPI plugin can basically call any API it whishes (e.g.: call the OS's media API).
The closest thing to PNaCl in the Firefox world isn't NPAPI, but ASM.js, that two only runs a very limited set of API (e.g: only use WebGL) and is restricted to what it can do.
Saddly, a lot of the Java applet aren't actually "write-once run everywhere" as Java was intended to be, but rely on native libraries that are packaged together.
(This is also is the reason why some popular Java applet won't run easily on Linux 64bits without some tweaking).
These external DLL/so are clearly out of what the PNaCl model authorises. You can't do a PNaCl-port of Java instead of NPAPI and keep such functionality.
And such thing are really popular in the corporate world: .so) for all media access.
- Cisco's WebEx conferencing platform - which is immensely popular in the corporate world - relies on native libraries (.DLL or IA32
Without it, all you're left with is using a phone connection to the conference, and you miss screen sharing/webcams.
- Several VNC plug-ins use similar native libraries for low-level access - (including popular ones to remotely admin servers from the lights-out web console)
etc.
All these won't require a simple recompile. .so files gets rewritten from scratch to be able to used from within the restricted context of PNaCl.
They would require that :
- Java gets ported to PNaCl (or the apps themselves get re-compiled targetting PNaCl instead of JVM).
- Extra functionality that the applets pack into external
(That would be great. It means less risks of hacking as everything fits within the PNaCl restrictions, and also as PNaCl is bytecoded, you get tweak-less support for x86_64, ARM, etc.)
Or:
- rewrite the whole functionality from scratch using HTML5/Javascript and using modern API.
(Even better in my taste).
What will probably happen:
- Internet is back as the corporate standard, because 2/3 of all the used business App (like most of the things running on Java in the corporate world) aren't straight recompiles.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]