Needs to load an appropriate security manager too.
Though whether you’d want the security to be as strict as applets, or relax it somewhat is another topic.
Off the top of my head, stuff that is impossible with unsigned applets but is potentially valuable in 4k entries:
Reflection, file access to rt.jar, custom composites, Robot usage, FSEM, ports for MP.
What were the rules for signed applets in the past? Were they ever tested?
Agreed, I use that to detect when to terminate the applet. It should return false, when the window containing the applet is being closed. Ideally this should go false prior to the window being closed 
I also agree that a security manager would be a good idea. However it would still be nice to have the option of additional access rights. I have an idea that’s been on the blocks for a while that uses the microphone. Also 2 years ago I submitted a signed entry that did networking. Still I’d be perfectly happy to submit a plain sandboxed entry this year.
[quote]What are you using for handling gzipped jars?
[/quote]
I dont have the code here right now.
(wrote that secretly at work)
But im using the GZIPInputStream to get the .gz “component” and then extract it with the java.util.jar.Pack200 unpacker to unpack that.
You can also look in the jar then for the classname of the main class (usually there is just one for the applet)
For a GUI, it would be nice to have the description texts + a thumbnail beeing displayed when selecting one game of the list.
i think appel could help out with preparing that in a more streamlined way (provided as an online java4kDB.txt kind of file with text and link paths to the games).
For legal reasons. The jar probably have to be downloaded on demand.
There was also the year that allowed using the small library for uploading high scores to the java4k site. I don’t know if we want to continue using that.
FYI, the Interactive Fiction game contest used something similar, where all the game entries were bundled into a single file that allowed you to select which ones to play. This also helped out the judges to better track what they played.
Thanks for the reference. I’m now maintaining this over in my sourceforge project: http://sourceforge.net/p/groboutils/java4k/ci/default/tree/
I finished up a rough cut of an applet launcher at my 4k mercurial repository based on Sunsword’s version above. It includes a restricted security manager (but not bullet proof - I really dislike the policy file stuff), can load pack200 and jar files, and can pull in either local files or read the applet off a web page. It has trouble stopping applets, though.
A bit of extra work could get it pulling the list of submitted files from the Java4k site to allow a selection.
It is really unfortunate that applets and webstart have fallen out of favor. The security warnings these days scare away most. And, if you are not using Windows, chances of a successful run diminish further.
The idea of a loader is interesting, but it also raises some problems. If a pack200 jar is no longer considered as an executable deployment unit, then its only purpose is to prove that the game is compressible down to 4K. The loader could just run a bunch of uncompressed class files directly. From a similar vantage, some hypothetical, super compressed, proprietary pack4K format could be created just for the loader.
Someone compared J4K to the demo scene and I personally view it similarly. For instance, their 256 byte assembly demos usually require VMs like DOSBox to run. But, you could always fire up a real (old) PC to prove that it works. They never introduced the idea of a loader. If the spirit of the contest is to live within the constraints of Java, then we should not invent a new platform.
All that said, I would like to see J4K take a completely new direction by removing the compressor and the platform/loader out of the equation entirely. Instead of measuring the size of the deployment unit, measure the size of the source. We could have some process strip out white space and comments and declare that as the size. In addition, only distribute the source code. Let anyone interesting in playing/voting compile it themselves.
Considering my commented source usually comes in at 16k or even more, I suspect that even obfuscating it would result in getting significantly less code under the 4k limit.
Agreed. But, it presents a new coding challenge. Games under a 4K source code constraint would contain fewer features than a pack200 game. It could be thought of as an entirely differently category of games within the contest or a completely different contest altogether. I would go as far as limiting the source files to ASCII encoding (all byte values of the file less than 128).
if its going to be under 4k source code, I feel like itd probably drop down to text based console level of games, and extremely rudimentry with less diversity.
I looked at about the top 20 games in java4k original source codes. and they average about 45-55Kb (uncompressed pure text form). So the 4k compressed games are already usually pretty limited.
In the comparison if we were to do not do a ‘compressed’ version. We coulld just say limit it to 48kb uncompressed (or 32kb or 64kb)
I just checked last years entry - 49k, which is one of my larger efforts due to being almost totally procedural and scads of comments. Some of my entries from earlier years were significantly smaller. It would probably be less than 32k obfuscated. I’m not sure that I like the idea though. It doesn’t solve the fundamental problem of applet security, unless everyone compiles the applets themselves, which is not an efficient use of peoples time. I think this approach would work better with javascript. If push comes to shove, I’d rather everyone submitted an executable jar, although that carries an uncomfortable security risk.
On the whole I prefer the idea of a loader application. I wonder whether it’s possible to write one as a traceable signed applet. I’m conscious that there is a risk of such an applet being repurposed to load malware, so it would need to be tied to java4k.com and run any loaded code in the security sandbox. Perhaps it would be safer (and easier) to supply it as an executable jar, and embed a 4k game browser function within it.
Alternatively we could write an executable jar that installs a root certificate. Either run keytool which is supplied as part of the JRE, or possibly do it programatically. Then we submit our unsigned entries and Appel signs them with the key, or the key is made available and we sign them. I think the former would be safer and could be automated.
I like Alan_W’s suggestion of providing the java4k organiser with an unsigned version which is then confirmed to meet the 4k limit as per usual, then using a free certificate obtained from a valid certificate vendor, perhaps http://www.comodo.com/home/email-security/free-email-certificate.php or http://www.startssl.com/ (have never used/not affiliated with any provider) sign the jar and host on the existing java4k website.
The signing can easily be a simple script so the extra effort for the organiser would be minimal.
I also like it as it would mean the least amount effort for the end user… i.e. no change.
[quote=“moogie,post:72,topic:43899”]
Certificates aren’t freely interchangeable. The ones you link are respectively for signing e-mails and for TLS. StartSSL do sell code signing certificates for $60, but that’s not free.
In addition, the extra effort for the organiser is only minimal if the organiser is willing to take the reputational risk of signing any code without reviewing it. Maybe Appel is willing to do that: I know that I wouldn’t be.
A sandbox approach is less risky for everyone.
I don’t think anyone is suggesting that we invent a new platform. I believe the suggestions are for giving users a method to play the games that don’t involve either big scary warning messages from the browser, or the difficulty and cost in setting up signed applets.
Using the analogy you give with the demo scene, a user could theoretically still load the jar or pack200 file through an older browser and custom httpd server, and still run the game. A launcher would just make it easier.
To me, any change that still has a size restriction would present the same kind of “compression battle”, only with different tools and coding techniques.
Sure if that is a concern then feel free to disregard my suggestion. I guess for myself I am not entirely sure that there is a conceptual leap between serving unsigned java4k applets vs signed java4k applets in regards to reputational risk… both are served from the java4k domain and are thus implicitly endorsed.
Perhaps I am just being a little slow today but I am not sure how a separate launcher will provide any more secure sandbox than the applet browser plugin? surely if malware can get around the applet sandbox it can get around any custom sandbox that might be utilised?
How would the end user obtain the launcher? To keep the experience to the user painless as possible then it would have to be an applet or webstart application and so still require signing to get rid of scary dialogs…
The launcher wasn’t my suggestion, but what I understood is that it’s about ease of use rather than a “more secure” sandbox. The ease of use of applets is on the way down, webstart sucks, and we may already be at the point that an executable jar with a .bat file for Windows users is easier to launch than an applet. (I know that applets seem completely broken for me at home, but I haven’t yet prioritised putting in a few hours to debugging that).
Ah I understand now. This leads me back to my original suggestion in this thread of having multiple ways for a user to play the game:
Could we obtain one digital certificate owned by java4k.com for all the entries? The entrants could submit pack200 jars that satisfy the size requirement. Then, the submissions could be repackaged into larger jars that are signed for distribution. And, browsers that have trouble with pack200 won’t have to deal with it.
I like the idea from zeroone!
This is what i was proposing… ( see http://www.java-gaming.org/topics/discuss-the-future-of-4k-contest/30600/msg/286293/view.html#msg286293 )
But there was a concern that there is the potential for tarnishing the certificate’s owner’s reputation if a malicious entry was submitted and served from java4k domain. ( see http://www.java-gaming.org/topics/discuss-the-future-of-4k-contest/30600/msg/286313/view.html#msg286313 )
I still think it is the best solution so far and the risk is low.