The security tripwire being tripped is the fact that you are downloading a ZIP from the Web. McAfee will give you this (the amusing ‘annoying software’ warning):
I guess I could pay McAfee to trust my web site 
Wouldn’t that be a McAfee issue and not an OS issue? McAfee and Symantec, while popular, create some of the worst products in the virus scanning field. Do yourself a favor and give AVG, Avast, or any of the other scanners a look. Zip files aren’t unique to Java or any specific application so everyone would face the same issue.
I don’t use it. My beta testers use it. I can hardly tell them: get a different antivirus program!
Why not using Winclam? Symantec already did some false claims about an Android application allowing to display what the camera see in the background. “Trusted” computing isn’t trustworthy. I’m fed up with all those gatekeepers (including the one under Mac OS X 10.8 ), those tolls, those inproductive companies (CA), the application stores, we should just burn them (please burn the banks too).
Give them a piece of cake, maybe they’ll become more cooperative ;D I do so with my girlfriend… sometimes it works.
Don’t forget the first rule of Fight Club, gouessej. 8)
I’ve been trying to persuade this one to get rid of McAfee for years. Her reasoning is: “I have to pay for McAfee, but AVG is free. Ergo, McAfee is better!”
I think there might also be this reasoning: “McAfee gives louder, scarier warnings. Therefore McAfee is better.”
I’ll definitely give the cake methodology a try.
I think you misunderstood - by default most Linux distributions generally lets you install any old shite, and doesn’t put any impediments in front of the user to doing so. There’s no warnings about unsigned code.
Windows and MacOS no longer generally have people running as root either but it doesn’t stop malware from doing what it does. Even when it does need root users are happy to put in the administrator password to get what they want…
Cas 
Really? If we’re talking proper installation, as in packages, then I’ve been seeing warnings about unsigned code for years!
All that package stuff… that’s for official distro stuff. For anything else, anything goes… just look at our games for example. They’re just a .tar.gz. You just unzip and double click to run. They could do absolutely anything :o
Cas
Archives aren’t installers. Packages can run scripts as root. In comparison your “can do anything” is quite limited, assuming you’re not making your users run your game as root. Packages are not just for distros - they’re also the way to achieve certain forms of OS integration if you need it.
Compare this to downloading and running something on Windows or the Mac. And remember - you don’t need to be root to do naughty things.
Cas
The first rule of Fight Club is: You do not talk about Fight Club
???
Well, it looks like Oracle is rolling this out in January: http://www.oracle.com/technetwork/java/javase/overview/ria-checklist-2055184.html
I thought the solution to this problem would be to write an uploader that creates an executable out of compile jars and libraries, but now Cas has me paranoid that even that won’t work. More research is required.
However, this might impact more than just applets and webstart. It looks like this will impact jars of all kinds: http://docs.oracle.com/javase/tutorial/security/toolsign/receiver.html
It looks like the only way to run jars is for the end user to mark the signed jar as trusted using the keytool command? This puts a lot of responsibility on end users, who have no idea how to do any of this stuff.
Is this seriously the case? And how does this impact executables, which are just running jars behind the scenes (I think)?
Maybe I’m misunderstanding here, but why would you think that an executable jar won’t work? If you’re using WebStart, then yes, you’ll fall under the new lock down procedures. If you’re launching it locally, then there are no restrictions on your application by default. As a side note I’ve just noticed that NetBeans now has the option to package an application into a standalone MSI or EXE installer. ;D
I could be mistaken, but if you go on to read the next part of that trail, it notes that in order to enforce security on an application you have to explicitly pass the “-Djava.security.manager” flag to the JVM at start up. Furthermore, if you jump to the article about controlling applications linked from that page, and go to the second page called “Observe Application Freedom”, the very first line states “A security manager is not automatically installed when an application is running”.
From what I gather, the article you linked to is explaining how an end user/organization can optionally lock down local applications since such restrictions are not present by default.
If the end user has gone through the steps needed to lock down local java applications, then using the keytool command probably isn’t an issue for them. As this is an “above and beyond the defaults” feature, I’d wager that acceptance/rejection of a certificate in the case of a regular user launching an applet/WebStart application from their browser will still be handled by the standard security popup and its don’t trust/trust/always trust mechanism.
I think this is the “exceptional” case, and not the default rule. Executables, which are just running jars that they extract from an internal resource bundle behind the scenes as you suspected, should work as normal with no extra intervention on the end users part.
Ahh okay, I understand now. I thought the security manager would be enabled by default, but I should have read more before flipping over my desk. Thanks for clearing it up for me.
I get why they’re adding the security manager, but I would guess that people who are technically savvy enough to enable it aren’t the ones being exploited in the first place…
Anyway, looks like my project over winter break will be to write an uploader that takes jars and libraries as input and outputs an executable file. Sounds painful, but hopefully it’ll help novices who just want a quick way to show off their programs.
I have the feeling that it’s geared more towards paranoid corporate IT departments who need a way to allow Java to run, but still want to control what applications it can run by default. Without that ability, they are faced with an “all or nothing” scenario with Java.
Considering both NetBeans and Eclipse are starting to offer the ability to create packaged applications, have you considered seeing if one of their platform API’s could be leveraged to automate the compiling/packaging for you? It would probably save you a lot of blood, sweat, and tears that would come from developing a packaging tool chain from scratch. 
Haha that makes sense, considering my company’s IT department’s reaction to the first wave of Java exploits was to silently uninstall Java from all company machines overnight. Pretty funny day for the Java developers!
That’s an interesting idea. I’m still in the very early stages of thinking about how to solve this particular problem, but if I could just write a handy “here’s how you create an executable from eclipse” and then allow users to upload executables, that would be awesome. I wonder if there are eclipse plugins for exporting to executable? To the google!
Hi
Since Java 1.7 update 51, unsigned and self-signed applications / applets are blocked by default, I realized it yesterday. You can find more information about that here:
https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias