Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4 5 6
  ignore  |  Print  
  Discuss the future of 4k contest  (Read 27301 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Knight


Medals: 15


falling into the abyss of reality


« Reply #60 - Posted 2013-09-20 16:51:43 »

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?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #61 - Posted 2013-09-20 18:09:34 »

Funny, I wrote a code very similar, wich can load a Java4k jar (in pack.gz format) locally
and 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  Smiley

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.

Time flies like a bird. Fruit flies like a banana.
Offline Damocles
« Reply #62 - Posted 2013-09-20 19:46:45 »

Quote
What are you using for handling gzipped jars?

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Groboclown
« Reply #63 - Posted 2013-09-24 21:29:36 »

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.

Offline Groboclown
« Reply #64 - Posted 2013-09-25 01:24:49 »

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.
Thanks for the reference.  I'm now maintaining this over in my sourceforge project: http://sourceforge.net/p/groboutils/java4k/ci/default/tree/

Offline Groboclown
« Reply #65 - Posted 2013-10-07 02:21:40 »

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.

Offline zeroone
« Reply #66 - Posted 2013-10-07 17:58:40 »

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

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #67 - Posted 2013-10-07 19:07:21 »

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.

Time flies like a bird. Fruit flies like a banana.
Offline zeroone
« Reply #68 - Posted 2013-10-07 19:25:57 »

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

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #69 - Posted 2013-10-08 04:11:39 »

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)


"Experience is what you get when you did not get what you wanted"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #70 - Posted 2013-10-08 05:16:18 »

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.

Time flies like a bird. Fruit flies like a banana.
Offline moogie

JGO Ninja


Medals: 15
Projects: 6
Exp: 10 years


Java games rock!


« Reply #71 - Posted 2013-10-08 08:33:33 »

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.

Java4k RIP 2014
Offline pjt33
« Reply #72 - Posted 2013-10-08 14:16:55 »

...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...
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.
Offline Groboclown
« Reply #73 - Posted 2013-10-08 14:50:19 »

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.

Offline moogie

JGO Ninja


Medals: 15
Projects: 6
Exp: 10 years


Java games rock!


« Reply #74 - Posted 2013-10-09 20:57:53 »

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

Java4k RIP 2014
Offline pjt33
« Reply #75 - Posted 2013-10-10 07:29:09 »

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

JGO Ninja


Medals: 15
Projects: 6
Exp: 10 years


Java games rock!


« Reply #76 - Posted 2013-10-10 07:57:58 »

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 warnings
2. Launcher (jar) - for those who have java installed and are savvy enough to know how to launch executable Jars
3. Launcher (native) - for those without java, are comfortable with installing native applications.

Java4k RIP 2014
Offline zeroone
« Reply #77 - Posted 2013-10-16 22:31:58 »

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.
Offline Apo
« Reply #78 - Posted 2013-10-17 14:34:34 »

I like the idea from zeroone!
Offline moogie

JGO Ninja


Medals: 15
Projects: 6
Exp: 10 years


Java games rock!


« Reply #79 - Posted 2013-10-18 05:58:09 »

Could we obtain one digital certificate owned by java4k.com for all the entries?

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.

Java4k RIP 2014
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #80 - Posted 2013-10-18 06:06:34 »

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)

There's quite a long thread here: http://code.google.com/p/jzebra/issues/detail?id=155


Time flies like a bird. Fruit flies like a banana.
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #81 - Posted 2013-10-18 08:33:43 »

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

Cas Smiley

Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #82 - Posted 2013-10-19 06:22:00 »

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

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

Time flies like a bird. Fruit flies like a banana.
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #83 - Posted 2013-10-24 06:51:33 »

Why dont you have a set time for making the games, and then you export it with the JVM so that the casual user doesnt get the security warnings and they dont have to install a jre?

Smiley
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #84 - Posted 2013-10-24 08:40:54 »

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.

I could go on.

Cas Smiley

Offline lcass
« Reply #85 - Posted 2013-11-06 19:43:59 »

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

JGO Wizard


Medals: 68
Projects: 4


I always win!


« Reply #86 - Posted 2013-11-12 20:38:50 »

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

Not so long until December 1st... I'm gonna come up with some ideas Smiley

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #87 - Posted 2013-11-14 01:26:32 »

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.

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #88 - Posted 2013-11-14 09:39:24 »

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 Smiley

Offline zeroone
« Reply #89 - Posted 2013-11-14 20:59:23 »

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 Smiley

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.
Pages: 1 2 [3] 4 5 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (35 views)
2014-12-15 09:26:44

Mr.CodeIt (26 views)
2014-12-14 19:50:38

BurntPizza (54 views)
2014-12-09 22:41:13

BurntPizza (87 views)
2014-12-08 04:46:31

JscottyBieshaar (49 views)
2014-12-05 12:39:02

SHC (64 views)
2014-12-03 16:27:13

CopyableCougar4 (67 views)
2014-11-29 21:32:03

toopeicgaming1999 (127 views)
2014-11-26 15:22:04

toopeicgaming1999 (118 views)
2014-11-26 15:20:36

toopeicgaming1999 (34 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!