5 ms·

Yes - also even a user who only wants to use client side Java outside of the browsers may be in trouble because of the automatically installed browser plugins t

by sixbrx 14y ago

Yes - also even a user who only wants to use client side Java outside of the browsers may be in trouble because of the automatically installed browser plugins that are part of the Java installation process. It's incredible how far and fast client side Java has fallen because of Oracle's tepid response to security concerns. I've developed many internal apps for client-side Java and supported them for over a decade. I don't think I'll develop another.

pifflesnort 14y ago
It has nothing to do with Oracle's response -- the Java sandbox is simply broken, and has been known to be broken for at least the last 5 years. There's no fixing it, the approach is fundamentally flawed and fundamental to Java. This doesn't mean that Java for client-side applications is broken, as long as you don't rely on web based distribution and browser sandboxing.
- tjoff 14y ago
  "This doesn't mean that Java for client-side applications is broken[...]" I don't know. Java on the desktop requires administrator privileges to be able to notify me that an update is available. Also, it tries to install a virus in the form of "Ask toolbar" every frigging time.
  - sp332 14y ago
    Try installing using http://ninite.com http://ninite.com, and use msconfig to make sure "Java Platform Auto Updater" is disabled from your startup.
- BigBlueSaw 14y ago
  Can you elaborate on "the approach is fundamentally flawed"? Don't we rely on a similar sort of sandboxing for Javascript in the browser?
  - benmmurphy 14y ago
    java sandbox has a massive surface area. conceivably any class in the jre could create a hole in the sandbox. modern browser sandboxes appear to be stronger because they rely on an unprivileged process which communicates with a broker interface. the broker code is much smaller than the jre code so it is easier to verify. however, there has been sandbox bypasses. the adobe sandbox bypass was a bug in the broker interface and it can be possible to use local kernel exploits to bypass the sandbox as well.
martinced 14y ago
Oh you don't know my misery : ( I'm actually working on a desktop app used by hundreds of people (and installed by thousands) and my entire business model is being an ISV: trying to sell that Java app to people. The less Java installed, the harder my life becomes ; (
- limmeau 14y ago
  Are there JREs which you can secretly include in your package, so that it looks like a few-hundred MB native application which happens to be implemented in Java?

by sixbrx 14y ago

pifflesnort 14y ago

It has nothing to do with Oracle's response -- the Java sandbox is simply broken, and has been known to be broken for at least the last 5 years. There's no fixing it, the approach is fundamentally flawed and fundamental to Java. This doesn't mean that Java for client-side applications is broken, as long as you don't rely on web based distribution and browser sandboxing.

tjoff 14y ago
"This doesn't mean that Java for client-side applications is broken[...]" I don't know. Java on the desktop requires administrator privileges to be able to notify me that an update is available. Also, it tries to install a virus in the form of "Ask toolbar" every frigging time.
- sp332 14y ago
  Try installing using http://ninite.com http://ninite.com, and use msconfig to make sure "Java Platform Auto Updater" is disabled from your startup.
BigBlueSaw 14y ago
Can you elaborate on "the approach is fundamentally flawed"? Don't we rely on a similar sort of sandboxing for Javascript in the browser?
- benmmurphy 14y ago
  java sandbox has a massive surface area. conceivably any class in the jre could create a hole in the sandbox. modern browser sandboxes appear to be stronger because they rely on an unprivileged process which communicates with a broker interface. the broker code is much smaller than the jre code so it is easier to verify. however, there has been sandbox bypasses. the adobe sandbox bypass was a bug in the broker interface and it can be possible to use local kernel exploits to bypass the sandbox as well.

martinced 14y ago

Oh you don't know my misery : ( I'm actually working on a desktop app used by hundreds of people (and installed by thousands) and my entire business model is being an ISV: trying to sell that Java app to people. The less Java installed, the harder my life becomes ; (

limmeau 14y ago
Are there JREs which you can secretly include in your package, so that it looks like a few-hundred MB native application which happens to be implemented in Java?