Slashdot Mirror
Firefox's Blocked-By-Default Java Isn't Going Down Well
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. "
Users hate authorizing things, and become trained drones blindly okaying everything anyway.
As security models go, it's a poor one.
They should probably get their heads checked, why are they making Java apps for webpages still?
I'm not a developer, but I'm pretty savvy with computers. So the first time I got that message, I went and updated Java. Fixed it, right? Nope. So I clicked around, and finally accidentally clicked on the little red icon up in the menu bar. Success! Now it gave me an option to run it. Which popped up another window asking for permission. Dear Firefox: You have a small portion of the browser market. Making yourself a nuisance by breaking big pieces of the web is not intelligent. It just drives people to chrome, or IE. Especially everyday users who don't want to screw around and just want things to work.
moving away from a dependence on proprietary plug-ins
Like the browsers themselves?
Hey maybe we can get all the people at Adobe and Oracle laid off the same week. Wouldn't that be fun?
Isn't it great how the web is moving away from "proprietary plug-ins" and straight into proprietary mobile devices?
And look at the web users cheer. The people who built the web would recoil in horror at what you have allowed to happen to the Internet.
I give it five years, maybe six, and the Internet will be completely walled off by a McDonalds logo.
Firefox will be exactly what Scott Adams predicted...
http://dilbert.com/strips/comic/1995-03-25/
Applets may be "The Debil", but they also fill a need that can't be filled by Flash or HTML5.
Mozilla needs to get over themselves.
Java is huge in the business back end, but front end Java just leaves a bad taste in the mouth of users. Slow, bloated, painful to use and kinda salty.
Yay me!
We'll see. I've been running the FlashBlock plugin for years (to manually enable flash elements) with VERY FEW adverse effects. I doubt having to manually activate Java elements will be any worse.
sig: sauer
There are two ways to improve security - lock out the user, or educate them.
Locking out the user is great - but it only works on NEW products, and if you don't have competitors. The reason it works well on NEW products is that the user isn't conditioned on what to expect. Remember, trying to change how people use their computer is an uphill battle. It works well when the do not believe they have alternatives.
Educating the user is harder, but that is the real fix. You aren't improving security by saying 'As responsible devs, our software won't do what you want'. Instead, make a two minute video showing them how $technology is flawed, and make them watch it ONCE. Then, let the choose whether to block $technology or live with it. Because right now they get fed up with Firefox (NOT Java), and click the little blue e.
And yes, it isn't a great hassle to keep using FF when you allow users to "click to allow $applet". But the pain is that I need to look at the little red icon in the address bar to permanently enable something. You might say that if I can't handle this additional step, I shouldn't be making a choice on whether to run an applet or not (but that is a bad road to head down). You could have just made a popup when I run an applet that says "Do you want to remember this setting?" - it doesn't fix the security problem, but the current solution doesn't either. At least this way, I don't feel frustrated at my browser for someone else's (Oracle, in this case) screw ups.
How to enable Java if its been blocked
So, now, the lastest version of Java (7.45) is considered outdated.
Absolutely brain-dead decision.
You are being MICROattacked, from various angles, in a SOFT manner.
Oracle Java has ALSO decided, due to the persistent security problems due at least in part to having concurrent (i.e., old) versions installed (and the fact that the largest exploit kits have used Java as one of their main vectors for some time now, alongside Adobe Reader of course) to disable Java plugins in the browser by default in recent updates.
So, what's the big deal? This is the correct decision from a security perspective. I can't remember the last time I saw someone on the World Wide Web actually USE a Java applet for good, rather than for evil. And I'd have noticed, because even after all these years, it still runs like an absolute dog. It's the kind of thing you might use on a local application (such as Minecraft, which is what I think probably most people who still have it installed use it for now, albeit they'd likely have the 64-bit version which wouldn't have a working browser plugin in a 32-bit browser anyway!) or an intranet site (which is your administrator's problem, to re-enable it for that site only, or to use a different browser for the web and the intranet, which you can totally do and is good practice).
I've got many other criticisms about Firefox recently from a security and performance perspective - let's face it, it's just not the zippy, efficient browser it used to be, even relatively-speaking, it's lost its mojo and the security team have a reputation for having a slow, and fairly arsey, response - but this seems to be the right decision and they should be lauded for it. IE has also done it, as has Chrome.
From Link:
First I've heard that Java 5 and 6 are not considered dead yet.
You are being MICROattacked, from various angles, in a SOFT manner.
> 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 for a list of recent problems.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
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.
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, 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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If you are still developing/depending on applets, 1995 called they want their stupid ideas back.
Hi 2013, this is 1995 calling. When your new shiny toys have the portability and performance and flexibility that we had nearly two decades ago, and developers can write software using them with a reasonable expectation that it will still be working in 5 or 10 years (or even 1 or 2 years) without needing constant maintenance, then you get a vote. Until then, we'll keep our "stupid" ideas, because they've been helping us get useful work done since before you were born. Kthxbye.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You do understand that without those Bad Things you so hate, there probably wouldn't be a Web worth saving, right? Someone has to pay the bills, and if you're not going to pay for content, you're not going to accept advertising, you want full privacy and security when using services you're not paying anything for... Who is going to write the cheque?
I hate DRM and spammy ads and privacy invasions as much as anyone -- more that most, probably, given that I really do give up on some things most people accept because I refuse to support the intrusions. But still, we live in the real world, and you can't just wish Bad Things away without proposing Better Alternatives. BTW, "everything I want should be free and unencumbered" is not a viable Better Alternative.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The number of support e-mails in my inbox this week from those users suggests that they aren't too happy about being "defended" in this way.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.