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:

Funny, I wrote a code very similar, wich can load a Java4k jar (in pack.gz format) locallyand run it.

the Stub method:

public boolean isActive() { return true; }is important, as some games wait for it to become true.

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.

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).

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.

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.

Groboclown put together a great set of ANT scripts two years ago. It's what I used for the 2012 competition. It does proguard, packing, gzip, etc, even with different block sizes. I think I had to get proguard and a 7zip separately and configure the script with their locations, but having that toolkit does lower the entry bar significantly.

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).

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.

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.

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.

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.

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.

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.

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.

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...

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).

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:

1. Applets - for those who trust and do not care about warnings2. Launcher (jar) - for those who have java installed and are savvy enough to know how to launch executable Jars3. Launcher (native) - for those without java, are comfortable with installing native applications.

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 googled around to see what other people are doing. The zebra folks do a free and a paid version of their product, with only the paid for version having proper traceable code signing.

In the end they went for providing a root certificate that users could download and install to allow the use of a self-signed applet. Since it is now possible to state that the applet must run in the sandbox with the latest version of java, it would be possible to specify that entrants must include that in their contest entry, which would reduce the risk of rogue code, as sandbox escape exploit code would need to be included. (This would also help with the previously mentioned reputation issue)

Hm you must be joking if you think anyone sane is going to install a root cert.

Cas

You are trusting the author of the software whether the certificate is traceable or not. The only difference is that the author is verified. If we made a root cert for java4k, but did not distribute the signing key, but instead wrote an upload script that signed the code and included 'Permissions: sandbox' in the manifest, then used the java version parameter to ensure that users with older java installations didn't inadvertently run code that wasn't limited to the sandbox, then we would have a reasonable level of security. It would be possible for someone to write malware, but unless it escaped the sandbox via a bug (which is a problem already), java4k would be safe. If someone wrote malware, then uploaded it to java4k, then grabbed the jar and hosted it elsewhere, it would only pose a risk if they also tricked users running old versions of java into installing the java4k root certificate. If they were going to do that, they could make their own root cert just as easily and trick folks into installing that (with the advantage that they would not have rely on users running old java versions). Overall the size of the attack surface is quite small.

The only difficulty I see is providing an easy way to install the root cert. If we limited browsers to IE and Mozilla, it would be easy. Just click on the .cer and install it in the browser keystone, which I believe is checked for applets and webstart. However I don't think this works for all browsers, so I suggest providing an executeable jar that installs the certificate. If we were really clever, the executable jar would check the java version and refuse to install it on old versions of java that don't support the permissions manifest entry. That reduces the attack vector surface to miniscule levels. To mount an attack would now require finding an exploit to escape the sandbox on the latest java and remain within the 4k limit, which is harder than just finding an exploit and hosting an unsigned applet (which will still run at present).

Installing a root certificate is just another huge barrier in the way of anyone caring about Java4K.

And relatedly, a root certificate is a serious thing. If they're not kept in exquisitely safe places, then if it got lifted you'd then have a neat little back door on to a bunch of people's computers. Additionally a root certificate usually comes with some sort of guarantee from the owners that they will actually verify the identity of subcertificates that they sign with it - that is, they provide a chain of accountability and trust. If you're just going to allow any old Tom, Dick or Harry to sign code with the root cert without verifying who they are then it's a pretty small matter for me to make a Java4K entry anonymously which contains a remarkably small number of bytes - just enough to open an AWT window with "HAHA! L4m3r! Pwned!" in it as it goes about deleting everything it can from your C:\ drive by writing zeroes over it. And you'd never find out who did it.

Just looking over this I think my faviroute idea is using the internet only as a download host for the loader and also for storing the projects.Using the launcher to view,download and upload the contest entrys would neaten everything up and would be a lot smooth but also a lot more manageable for the organisers as they could directly control traffic.

I feel like all this talk of signing, certificates and launchers makes things a whole lot messier, and uninteresting. We're forced to focus our efforts on deployment rather than making great small games. My brain hurts.

Signing applets won't get people to run them. It's not a guarantee of "there be no malware here" anyway.

Creating a non-solution is not a solution, only a waste of time, or as some geeks call it: "fun".

Java4K is a fun coding exercise which... most of the time, produces a game. It is probably the biggest repository for Java games and java related projects we have currently... (or in our case, ever) other than this site. Programmers exercise or not, it is a pretty fair contest and one that improves each year. As far as I know, I think the contest is fine as is.

It isn't Java4K that is causing the problem, it is Oracle and its disregard for the safety of Applets. The only plan that I agree with is possibly having a separate launcher (.jar) for the Java4K games. The limitations would still be the same, but it'll give the users a more secure? way of accessing the Java4K content if they don't trust Applets. For all those that still don't mind, then the regular Applet version is still hosted on the site.

Oracle don't have any disregard for the safety of applets - they're patching them like crazy. The problem is that major holes still keep turning up and the very idea of having this thin membrane of security between your computer and the entire internet is of dubious wisdom. I've turned applets off - permanently.

Oracle don't have any disregard for the safety of applets - they're patching them like crazy. The problem is that major holes still keep turning up and the very idea of having this thin membrane of security between your computer and the entire internet is of dubious wisdom. I've turned applets off - permanently.

Cas

I am told the same by anyone to whom I send the java4k.com link. Maybe I should spend the time learning about HTML 5 games.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org