Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (489)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (555)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Mozilla Planning to Kill Java  (Read 7494 times)
0 Members and 1 Guest are viewing this topic.
Offline tberthel
« Reply #30 - Posted 2011-10-01 15:31:32 »

They as in browsers developers.

ActiveX crashes a bunch.  Yes it is only IE, but they should remove it since it poses the same issues.

Applets still run in Chrome.  I am betting that Firefox won't remove the plugin and will just do the same thing.

Firefox is not the only browser so Web Sockets is still the same issue.

Offline Waterwolf

Junior Member


Medals: 3



« Reply #31 - Posted 2011-10-01 18:43:03 »

We'rent we talking about Firefox here Clueless
Offline JL235

JGO Coder


Medals: 10



« Reply #32 - Posted 2011-10-01 19:18:13 »

It doesn't matter which way you cut it, the Java plugin has become a very large attack vector in browsers. Until this changes, then it should rightly be blocked by browsers.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 368
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2011-10-01 19:42:54 »

Ironic considering the massive effort that went into Java security design, sandboxes, permissions, code signing, yadda yadda. And still they fail! I wonder why this hasn't yet happened to Flash? Or maybe it has.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #34 - Posted 2011-10-02 00:31:25 »

I wonder why this hasn't yet happened to Flash? Or maybe it has.

An entirely unscientific google for "flash security vulnerability" yields ~7,700,00 hits. It's been the attack vector of choice for years from what I remember, and only recently seems to have got reasonably secure. And now that all of it's low-hanging security holes are closed, hackers have moved on to the low-hanging java holes.

Personally I'd blame this on Oracle bolting new stuff onto java too fast, not doing robust security testing, and then dragging it's feet to actually fix critical vulnerabilities. Sun had a better track record of not letting as many holes into the wild in the first place, and then at least patching them up at a reasonable speed.

If I was a browser developer, I'd be looking at ways to sandbox *all* browser plugins (java, flash, activeX, silverlight, etc.) in some generic way. Chrome half does this by running everything in different processes, but I'm not sure how you'd lock things down tighter and stop the plugins calling any native api calls they want. Maybe if you proxied *all* the native calls so they actually go via your browser sandbox via some kind of dll redirection shenanigans? I suspect this would be a huge amount of work though. A more practical way on a *nix box would be to run the plugins in separate processes under a restricted user account, but I suspect this doesn't work on windows so it'd be a bit pointless since 90% of hacks target windows.

Or maybe as a browser developer I'd be thinking "I already have a language that's sandboxed in a vm I control - it's called javascript, why don't I disable all native plugins and get everyone to migrate to that". And while theoretically a good move it's not really very pragmatic given the state of the web.

Ultimately browser developers are in a tough bind IMHO. They're stuck between several opposed goals (security, functionality, backwards compatibility), and choosing any option is going to leave a large amount of people unhappy.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline sproingie

JGO Kernel


Medals: 202



« Reply #35 - Posted 2011-10-02 00:45:16 »

A more practical way on a *nix box would be to run the plugins in separate processes under a restricted user account, but I suspect this doesn't work on windows so it'd be a bit pointless since 90% of hacks target windows.

It's not only supported on Windows, IE installs a shortcut to run it precisely like that.  It's not the one the average end-user runs by default, because it's really quite annoying unless you've set up the environment to support it (as you might with a kiosk).

The permissions model of operating systems is really a poor fit in today's environment.  To wit: why can't I easily run apps with a subset of my own permissions?   Even stuff like SELinux is about very static contexts without any controls for anyone but system integrators like vendors.

Offline gouessej
« Reply #36 - Posted 2011-10-02 13:19:48 »

It is insane for the browser to have web sockets and activeX yet try to remove java.  It is purely political.

Firefox will just lose more market share.  To many companies depend on Applets.
That is what I tried to explain to Mozilla guys. They seem to be pleased to plan to remove the Java plugin, maybe there is something to do to drive such a removal legally harder if we do not succeed in convincing them technically.

Offline tberthel
« Reply #37 - Posted 2011-10-02 13:58:27 »

With so many security problems with browsers it amazes me that they would blame Java of all things.

Again I think it is mainly politics.  I don't think they will actually do it anymore than chrome has.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #38 - Posted 2011-10-02 14:50:07 »

That is what I tried to explain to Mozilla guys. They seem to be pleased to plan to remove the Java plugin, maybe there is something to do to drive such a removal legally harder if we do not succeed in convincing them technically.

There isn't.  They could decide to stop supporting Javascript tomorrow if they felt like it.
Offline JL235

JGO Coder


Medals: 10



« Reply #39 - Posted 2011-10-02 14:56:05 »

It's not as clear cut as just saying "block access to x", because often want to allow access under certain conditions.

For example if an applet is to be integrated into the webpage, it should be allowed to make calls to the same domain. This should include all of the cookies that the browser would use, including the HTTP only ones, which are blocked from user access. This means the applet needs access to those cookies under certain circumstances (to make the request), but shouldn't allow the user to have access. This extends to things like SSL, which where to the current issue also applies.

Same is also true with running plugins in a separate process. You want to more the plugin out, so that it's more stable and secure, however you also want the plugin to be able to use assets owned by the browser, such as the screen where it is drawn. On MacOS there is currently a bug where the Java applet flickers, because it is unable to get full rights to where it is being drawn, because the security model on Mac OS is much more strict. You want to allow some access, but not all.

All I'm saying is, if it was as simple as "block access to x feature", then all these security issues would have been solved about 10 years ago. For that reason, it might be more tempting to say "HTML5 is the future" and just block Java, rather then trying to fix these issues.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 368
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2011-10-02 15:09:21 »

It would have been better if they'd simply allowed Java to just do anything Javascript can do. As in, that, and only that.

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #41 - Posted 2011-10-02 17:08:19 »

That's kind of the idea of sandboxing.  The problem is that the sandbox appears to have leaks.  I wonder if the push to make the verifier faster also made it a good deal more lenient.
Offline tberthel
« Reply #42 - Posted 2011-10-02 19:43:41 »

That's kind of the idea of sandboxing.  The problem is that the sandbox appears to have leaks.  I wonder if the push to make the verifier faster also made it a good deal more lenient.

They could force sandboxing all applets.  That would also remove the need for the security dialog.

Flash has more leaks than Applets do when you don't use a security dialog (keeping it in sandboxed mode).

Although, many business applets would still need to turn on or install a plugin that allowed for unsecured applets.

I actually think they should have had 2 plugins 12 years ago. Then you would have the sandboxed way not only by default but would also require installation of a non-sandboxed capable java plugin.

I think I said this over ten year ago to a Sun employee.  Oh well.

Online kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #43 - Posted 2011-10-02 23:08:06 »

Funny thing is the whole situation could probably be averted before Mozilla make a rash decision like blocking Java, if only Oracle reach out to them and address the issue quickly. One of the main rationales behind such a move is the uncertainty on when Oracle will release a fix or even if they are aware of the bug. This is something Adobe have done really well with Flash and why browser vendors haven't been as concerned about taking action themselves against the Flash plugin and its security holes.

Oracle should be pretty concerned about loosing 20-30% of their plugin market share, especially as they've already invested so much into JavaFX 2.0. However its likely Oracle will just continue giving the silent treatment to issue.
Offline JL235

JGO Coder


Medals: 10



« Reply #44 - Posted 2011-10-03 01:59:16 »

Funny thing is the whole situation could probably be averted before Mozilla make a rash decision like blocking Java, if only Oracle reach out to them and address the issue quickly. One of the main rationales behind such a move is the uncertainty on when Oracle will release a fix or even if they are aware of the bug. This is something Adobe have done really well with Flash and why browser vendors haven't been as concerned about taking action themselves against the Flash plugin and its security holes.
This is a really good point. Firefox blocked Silverlight a year or two ago, but only for a couple of days, because MS stepped up and fixed the security hole.

By saying "were only supporting this if it's safe", and actually sticking to that, it's sending out a message to Adobe, MS, Oracle and other vendors, that they need to take security issues seriously. In the long run, that's a good thing.

Offline Z-Man
« Reply #45 - Posted 2011-10-03 06:18:14 »

I actualy think it would be good for Mozillia to block applets, and not just because I think applets suck Wink but because of what kappa and JL235 mentioned (and the security hole). I think that if a large browser like Fireox blocked applets it would force Oracle to take notice and at least fix the security holes. I'd even like it to go a step further and have browsers block Applets until their improved all together not just security patches. Thats my two cents anyway.

Z Pointing
Offline gouessej
« Reply #46 - Posted 2011-10-03 08:21:37 »

That is what I tried to explain to Mozilla guys. They seem to be pleased to plan to remove the Java plugin, maybe there is something to do to drive such a removal legally harder if we do not succeed in convincing them technically.

There isn't.  They could decide to stop supporting Javascript tomorrow if they felt like it.

I don't think about Javascript and I don't think Flash vulnerabilities are only something of the past. If they block Java, they have to block Flash too. I think what the Mozilla Foundation is doing does not respect some European laws even though I think Oracle should fix these vulnerabilities as soon as possible.

Offline Spasi
« Reply #47 - Posted 2011-10-05 16:40:04 »

Some interesting data: How Windows get infected with malware. Are they blocking Adobe Reader next then? Yawn
Offline JL235

JGO Coder


Medals: 10



« Reply #48 - Posted 2011-10-07 06:51:46 »

Some interesting data: How Windows get infected with malware. Are they blocking Adobe Reader next then? Yawn
Yes, in Chrome, it uses it's own PDF viewer for extra security and reduced startup time.

There has also been a lot of movement to make Adobe Reader much safer on the web. PDF files are also far more popular then Applets, so people actually care.

Online kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #49 - Posted 2011-10-18 22:06:36 »

Mozilla announced today that they have decided not to block the Java plugin. Annoucement found here.

The reason for them backing off seems due to the fix for the vulnerability which Oracle finally released today. Oracles slow reaction here could have had some pretty disastrous consequences for the Java plugin (i.e. 30%+ market share instantly wiped out).
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (12 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (27 views)
2014-08-22 19:31:30

atombrot (40 views)
2014-08-19 09:29:53

Tekkerue (38 views)
2014-08-16 06:45:27

Tekkerue (34 views)
2014-08-16 06:22:17

Tekkerue (24 views)
2014-08-16 06:20:21

Tekkerue (34 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (47 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!