What if... Java Self-Updated Like Chrome
Chris Koerner
Moandji Ezana
What if Java self-updated on end users machines?
Mark Fortner
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Fabrizio Giudici
wrote:
> Java can be configured to automatically update on Windows:
> http://java.com/en/download/help/java_update.xml. On Linux and OS X, the
> package manager, and Mac Update mechanism usually takes care of that for
> you.
The only embarrassing moment in my career happened at the times of Java
1.3 (don't remember precisely). The day before the official acceptance
tests everything was fine. The day of the official acceptance tests, in
presence of a big boss of the customer, everything failed. I don't recall
precisely the details (it should be stuff circa 2000/2001), but our Java
Web Start got an update when running the acceptance tests and got a change
in the management of digital certificates. Before the update, the JRE was
able to access the certstore of Internet Explorer. After the update it
wasn't. We were using a customer self-signed certificate that the official
procedure presumed was loaded by first connecting to the website home
page, then it would have been available to the Java applet that was going
to run. Without the certificate, the applet was completely broken.
The incident was understood a few hours later and caused no big
consequences, because the customers' technicians understood what happened.
But, you know, a failure, even temporary, in face of a non technical boss
*may* have bad consequences even after a clarification.
So, for an industrial environment, auto-update for me is a big NO. In the
sense that I must be able to control it: I will always explicitly put a
dependency on a specific Java version. We can say that auto update may
even occur, but not replacing the older version, and the newer won't be
used until somebody first tests everything in a pre-production environment
and then gives green light for production.
For end users, it makes probably sense because they are not technical,
lazy and wouldn't run the update manually, thus exposing to potential
security flaws. But for sure an automatic update, sooner or later, is
going to break some piece of software. Probably in most cases it's a minor
damage than a security breach.
Short story: ok to automatic updates, but there must be a switch. I
personally would always switch it off, even for personal use.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
Oscar Hsieh
Java historically have problem with backward compatibility specially on the Swing side. Yes my previous company has a internal swing app and we never never never update client's JVM and every time we update (from 1.2 -> 1.3 and 1.3 -> 1.5) there were always small issues here and there.
But you are right, there is no reason Java cannot do that.
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/V6IJJs2ocIsJ.
ebresie
Eric
Casper Bang
But then Chrome showed them differently, and now even Microsoft is going to start self-updating the browser.
clay
install/maintain a system wide Java and simply embed the JVM into
applications.
IntelliJ does this. New Java games like Wakfu do this.
Then those end user applications could use an auto-update mechanism as
appropriate.
clay
prompts for an update, which is probably safer for a developer
audience. Neither program expects the end user to have a system level
Java runtime installed. That is the ideal model.
Simon Ochsenreither
I can understand why a _few_ applications want to ship with their own JVM (IDEs, medical devices, nuclear facilities) but outside of that, this behavior should stop.
Attackers currently attack old Java installations because the Update system is not working as good and fast as it should.
If this issue gets solved, the only thing which changes is that attackers will switch to attack applications with old JVMs embedded.
Best thing which could happen is that Oracle just disallows bundling an internal JVM with an application.
Then those end user applications could use an auto-update mechanism as appropriate.
Most companies have very strict and time-consuming rules about testing an releasing an update. How exactly will people explain to the CEO that they will need to stop working a few days on their assigned work, just to update a third-party piece shipped with the application, retest it and update everything around it? (Documentation, web site, support, ...)
clay
> Attackers currently attack old Java installations because the Update system
> is not working as good and fast as it should.
applets embedded into a web page.
If a JVM is embedded in an app, such as an IDE or a game or some
productivity app, there really isn't much surface area for an attack.
The embedded VM isn't going to be running potentially dangerous web
applets like the system-wide VM is responsible for. If a client is
running a video game based on an old JVM, what kind of security
attacks could exploit that?
Ricky Clarkson
Also an embedded JVM causes fewer headaches for corporate users.
If Oracle's installer worked without admin rights it could update less annoyingly and then games could bundle it but have it update itself on install.
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
Simon Ochsenreither
If a client is running a video game based on an old JVM, what kind of security attacks could exploit that?
Does the term "multiplayer" sound familiar to you? Not many games these days are shipped without some component talking to a network.
I would suggest having a look at Minecraft for example ...
clay
embedded Java make security risks worse than C or other dev platforms?
As long as the embedded VM isn't being used to run potentially
malicious applets and web start programs from around the Internet,
users shouldn't be at any more risk than with any other mulitplayer
game written in C.
On Jan 21, 9:55 am, Simon Ochsenreither
Fabrizio Giudici
> How does a multiplayer game present security risks? And how does an
> embedded Java make security risks worse than C or other dev platforms?
>
> As long as the embedded VM isn't being used to run potentially
> malicious applets and web start programs from around the Internet,
> users shouldn't be at any more risk than with any other mulitplayer
> game written in C.
A security risk can potentially arise when the VM is launched, not
necessarily as an applet, as in general security risks are everywhere
(even though I think most of security holes were with applets).
Sure, Java is more secure than C. But when a C-based application exposes a
security risk, the bad press will be for the application. If the problem
is with Java, the bad press will be for Java (and it would be the same for
Silverlight or Flash, etc...).
