Firefox's Blocked-By-Default Java Isn't Going Down Well 362
JG0LD writes "The Firefox web browser will, henceforth, require users to manually activate Java objects on sites that they visit, Mozilla has confirmed. This even affects up-to-date versions of Java, which you can see on the block list. The change is aimed at improving security and moving away from a dependence on proprietary plug-ins, but critics say it will cause untold headaches for developers, admins and less-technical end-users. "
Re:Headaches for developers? (Score:5, Informative)
In my case, applets for doing signatures with USB signature tablets. Can't do that in JavaScript.
Re:Already considering uninstalling firefox (Score:5, Informative)
It just drives people to chrome
Good luck, Chrome has the same behavior. Even with a signed applet and updated Java, Chrome users had to click twice to run.
For the /.ers astounding by the persistence of Java applets, I was working with JMol [sourceforge.net]. I bypassed the issue by switching to the HTML5-and-JavaScript version and using the applet as a fall-back.
Re:Already considering uninstalling firefox (Score:5, Informative)
Well, if you're in Norway then 800-900,000 people use it daily and 2.9 million occasionally to access their bank and various other public services through BankID [bankid.no]. They are moving away from Java now after all the security issues, it was announced in April but hasn't happened yet so with this I expect Firefox usage here will drop like a rock.
Re:Headaches for developers? (Score:4, Informative)
I don't know... they built a substantial client-side Java app some years ago, it still works, and they don't feel the urge to reinvent a perfectly good wheel. E*Trade Australia still uses client-side Java.
Re:Headaches for developers? (Score:5, Informative)
Because Java allows native access to USB hardware. Haven't seen that in Javascript.
And no offense, but do you know what a digital signature is? Having the source code to the algorithm doesn't affect security. That would be like saying "I know how AES works, therefore I can decrypt all AES-encrypted data!" Doesn't work that way.
Nice SNAFU by Mozilla (Score:5, Informative)
How to enable Java if its been blocked [mozilla.org]
So, now, the lastest version of Java (7.45) is considered outdated.
Absolutely brain-dead decision.
Re:This is not security!!! (Score:1, Informative)
8 out of 10 browser exploits in the wild get in through Java.
Oracle is now involved (Score:4, Informative)
From Link [mozilla.org]:
First I've heard that Java 5 and 6 are not considered dead yet.
Re:I don't understant the hate (Score:5, Informative)
> I don't get it why people hate Java applets so much they want them to go altogether.
Because Java applets are a honking big security hole, and currently the most-often-used attack-vector to take over unsuspecting users' machines. See http://www.cvedetails.com/vulnerability-list.php?vendor_id=5&product_id=1526&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=6.99&year=0&month=0&cweid=0&order=1&trc=35&sha=d158a5520a2bc52f7443268daaab5851ced00564 [cvedetails.com] for a list of recent problems.
Re:What need? (Score:4, Informative)
Java is needed to do banking in many places, the FF change gave me 30 minutes of "wtf?"; trying to work out why it kept complaining about insecure applet, when running newest Java had me perplexed.
If I had an alternative to FF on Mac and Java, I'd ditch FF for this stunt in a heartbeat.
Uses of Java applets (Score:5, Informative)
Must we have this troll comment every time someone mentions Java applets?
Java applets are commonly used, as they have been for many years. According to this Chromium blog post from September 2013 [chromium.org], 8.9% of Chrome users had launched something using the Java plugin in the past month.
Among the common uses that get mentioned every time this discussion comes up are: public access to banking and government systems in various countries, games, user interfaces for devices (scientific equipment, network infrastructure, all kinds of examples), access to local hardware devices that aren't yet available via newer technologies, some popular teleconferencing and VPN software, and little demo graphics written by academics to go on their web sites a decade ago that are still just as relevant today.
In other words, just because you don't use Java applets yourself or know when they're still useful, don't assume everyone else is in the same situation.
Re:Didn't they learn from Microsoft? (Score:5, Informative)
Actually it's not an authorization dialog, but a "click-to-play" on the embed objects. You can get the same functionality already by setting plugins.click_to_play to true in about:config. That is just going to be a default setting on new installs, but you can set it to false. I set it to true myself, because it is useful to not have arbitrary Flash code to just start running (and playing).
The gamble Mozilla makes is that because of the extra step, companies will move to putting content into HTML5 rather than external plugins, because it makes their website more clunky. They also do replace external PDF viewer plugins with a HTML5/JS based one [mozilla.org], so it is a coherent strategy towards open technologies. There are plenty of benefits if it works out, security is one of them. And it's a phased, non-invasive method, which can be disabled.
Re:Didn't they learn from Microsoft? (Score:5, Informative)
Chrome ? I wouldn't count on that:
"By the end of 2014 Google intends to completely remove the Netscape Plug-in API."
http://www.infoq.com/news/2013/09/NPAPI-Depricated [infoq.com]
Re:Didn't they learn from Microsoft? (Score:4, Informative)
If there was a better cross platform alternative I'd switch to it.
you don't need flash (Score:2, Informative)
html5 can replace flash, check this link on how firefox can replace flash [lwn.net]
still not perfect, but getting better. it will replace flash, just like PDF.js can replace PDF plugins in browsers
They do have a VM (Score:5, Informative)
I guess they can even run javascript inside the same VM, so a unified approach.
In fact they already have a VM they use for javascript (the whole -Monkey family), and their VM is even able to compile to native. Not only JIT, but even more so for specially crafted javascript called ASM.js (it standard Javascript, that only use those features which translate nicely into machine code: doesn't use dynamic typing, only uses safe typing, etc.) enabling near-native speed for some code.
In theory, it should be possible to create a process which recompiles java byte-code into ASM.js and feeds it into the VM for nearly-native speeds.
In practice, Java is a huge pile of complicated mess, and thus lots of applications end-up being highly dependent on Sun/Oracle/IcedTea Java and not run well on any other implementation (like GCJ), mostly because of missing classes or whatever. So you'll end with something as good at running Java as currently Gnash is at running Flash - more or less works broadly on theory, but breaks on lots of specific cases. Given the current market for java (bazillions of inhouse applet in businesses) it is going to be hard to test every case. Whereas Gnash only breaks on some stupid casual games and video player for cute kittens (and pr0n), a Java-reimplemented-in-the-browser would probably break business intranets and core business applications.
The only possible solution, is implementing only the bytecode execution itself (transcode Java bytecode into ASM.js - like pluging GCJ to LLVM to emscripten to odinmonkey, for example). Ant then re-use the opensourced classes from IcedTea and co. But then you're again running the original java with all the original bugs, only on a different platform. If a bug in the official libraries enable an attacker to steal encryption keys from other apps, this is still going to put your bank's e-banking applet at risk, no matter if said applet runs on an uncrashable Mozilla OdinMonkey VM or the official Oracle JVM.
And Google recently developed an efficient sandbox called NaCl, so why not follow them? They could even run Java inside NaCl to add another layer of security.
NaCl isn't really a sandbox. It's only a special way to package executable native code, with limitation of what said code can do. It's some security restrictions (NaCl applications can only run a subset of the whole API available to normal applications and aren't allowed to run some instructions), stacked on top of the pre-existing Google Sandboxes (each into its own process)
Even if you use a JVM running as a NaCl application, you've only partially solved the stability problems (JVM crashes less, and when it crashes, it doesn't take the whole browser with it). You haven't solved security (obscure stupid java classes leaks encryption keys or password due to bad design).
Also note that NaCl is completely against Mozilla's approach and will never get implemented. Mozilla simply doesn't want binary code, because it's limiting (NaCl only runs on x86 and ARM), and still a security problem (even if it's much better then ActiveX, you're still sending executable code from the internet into a browser).
Still PNaCl is probably where everything will be heading: this time it's not the actual binary which is shipped, but the previous step in the compilation process - the LLVM bytecode. Google can still compile it into NaC (and run better security checks at compile time). And mozilla can use it to compile it with emcripten into ASM.js. It's now much more portable (you could run it on MIPS for exemple), and much more secure (when compiling ASM.js, memory access are translated into read/writes to/from an array instead of random memory writes).
Hell, they could even run the complete browser inside NaCl, so Firefox would run on Chrome too :)
If you want, you can even use Firefox to run one of the virtual machines written in Javascript, boot a virtual Linux distribution and run Chrome on it.
Re:you don't need flash (Score:4, Informative)
just like PDF.js can replace PDF plugins in browser
pdf.js is garbage. I never thought that anyone could write a PDF reader worse than Adobe Reader, but they did. It butchers at least half of the documents I view – other open source alternatives such as Sumatra handle them just fine. And even when it does work, it's incredibly slow, and the rendering is crap quality.
The Mozilla team really needs to give up on the experiment of PDF via JavaScript, and add a working viewer that uses native code.