#OpenJDK 17 sept 2013 log

(16:55:54) xranby: neugens: i have a great use case for caciocavallo web! use penbergs OSv to run browser applets securely sandboxed and use cacioweb to connect the browser to the applet
(16:58:20) xranby: neugens: penberg now work on https://github.com/cloudius-systems http://osv.io/ https://t.co/I0RLjaIT9T   OSv lets java run secure by design inside a virtual machine hypervisor
(16:58:53) xranby: you can then make a secure by design icedtea-web
(17:00:01) neugens: xranby, yeah, this use case has been one of the main ideas behind cacioweb
(17:00:11) neugens: somehow nobody took it seriously though 
(17:00:26) xranby: neugens: hey i love that idea :)
(17:00:44) neugens: xranby, hehe, yeah, i meant somebody but you me and rkennke ;)
(17:00:56) xranby: aww
(17:01:49) neugens: I need to find some time now though to jump on that again, I'm sure there are many use cases for java in the cloud
(17:02:56) neugens: xranby, one thing that was pretty limited at the time was the support for local filesystem access
(17:03:07) neugens: we require javascript for virtually anything
(17:03:17) neugens: I think things are much better now
(17:03:25) ednevill: adinn: ping
(17:04:16) xranby: neugens: if you can get regular sandboxed java apps running secure that is a big win
(17:04:27) neugens: yeah
(17:04:32) xranby: neugens: remember oracle have stopped supporting hte java sandbox
(17:04:43) neugens: swing apps work out of the box
(17:04:46) neugens: not just applet
(17:04:55) xranby: by displaying warnings on all non signed apps that it is insecure
(17:05:13) mr: xranby: Um, no, Oracle has not stopped supporting the sandbox.
(17:05:42) xranby: mr: if you run a sandboxed app you see this: http://labb.zafena.se/oracle/7u40/7u40-worldclock-insecure!%3f%3f!.png
(17:06:10) xranby: mr: try for yourself http://www.timeanddate.com/worldclock/personalapplet.html
(17:06:14) neugens: xranby, but that's unsigned
(17:06:22) xranby: unsigned apps are sandboxed!
(17:06:28) neugens: of course, one may say, who is responsible to sign them
(17:06:48) neugens: anyway, with webjdk you don't run anything on the localhost
(17:06:49) xranby: the java security model have allowed unsigned sandboxed apps since 15years back
(17:06:57) xranby: and now oracle wants all developers to sing the apps
(17:07:00) neugens: execution is all remote, there's no access to local resources
(17:07:04) xranby: and reduce security
(17:07:06) neugens: so no reason to sign anything
(17:07:17) xranby: by then the apps gets higher privileges 
(17:07:25) xranby: since all signed java apps have full access by default
(17:07:35) neugens: yes, but to access the remote system
(17:07:52) xranby: the new java plugin goes againt CERT recommendations
(17:07:58) neugens: I don't thin is comparable
(17:08:06) xranby: http://www.cert.org/blogs/certcc/2013/04/dont_sign_that_applet.html
(17:08:26) xranby: https://www.securecoding.cert.org/confluence/display/java/ENV00-J.+Do+not+sign+code+that+performs+only+unprivileged+operations;jsessionid=2F08DC1B78E8122152A6ADC2EA38B14B
(17:08:56) xranby: neugens: world clock is a typical application that should be run without any privileges
(17:09:17) xranby: and the java security model allows world clock to be run secure inside the sandbox
(17:09:31) xranby: but the new plugin in 7u40 popsup a warning claiming it to be non secure
(17:09:55) xranby: forcing the developers of world clock to sign the app in order to get rid of the warning.. also note the spelling on the warning popup
(17:10:00) xranby: http://labb.zafena.se/oracle/7u40/7u40-worldclock-insecure!%3f%3f!.png
(17:10:28) xranby: "will be blocked in a future release"   thus the sandbox is deprecated
(17:10:32) neugens: yep
(17:10:46) xranby: mr: do you understand my arguing?
(17:11:00) neugens: wouldn't it be better to just run the application on server side? :)
(17:12:02) xranby: neugens: if you can use icedtea-web + OSv you may implement an secure by design plugin
(17:12:18) xranby: that can prevent data breach even if you go outside the java security model
(17:12:26) xranby: or exploitable jni code
(17:12:38) xranby: surely that would be even more secure