Improving applets/jws games with a certified gaming extension API

Networking & Multiplayer
#1

Hi,

As I really appreciate the forthcoming integration of applets support in JOGL (based on the Sun trusted certificate), I think it would be nice to generalize this approach to a subset of currently “untrusted” API calls in order to enhance java online gaming without relying on self certificates (or even on trusted certificates that might not be apreciated by online players).

What I’d like to have is a set or sun certified jars (like jogl.jar) used as middleware for java game dev, which could provide :

  • access to joal/jinput (ode ?) from applets (same stuff as the “jogl applet” currently in dev)
  • access to a single local drive directory for game installation/state saving. The access would be granted in the same manner as an installer (“where does the game should put its files ?”) and the API would deny access to any other file location.
  • access to a network API allowing games to rendez-vous/communicate (TCP/UDP) with each other, without being able to connect elsewhere (the API should provide a GUI listing possible connection adresses with registered gamers user identities, and would deny contacting any other host).
  • access to full screen/rez change after prompting the user with a standardized window.

These APIs would allow java games developers to cover a broader range of games types without risking the security of the players.

And of course, Sun (or java.com) would provide a web page detailing these features, showing examples of JWS/JPI security warnings that our websites could link to in order to gain the confidence of our potential players.

The user experience would become :

  • hey, let’s have a look at this new online/downloadable game
  • I’m on the game web page, and there’s a link to java.com/.../extended_gaming_api.html describing what will happen when I start the game
  • I download/start the game, and there’s a security warning dialog, looking exactly like the one of java.com, let’s trust it !
  • the game begins, provides an installer for local files, explaining it will not be given access to any other part of the filesystem : I accept
  • the game shows the “rendez-vous” standard dialog, and I login and connect with my friends
  • I play and enjoy this game : java is great for online gaming, and my antivirus software is happy with it !

What do you think of it ?

Lilian

p.s : if someone from Sun thinks it’s a good idea, but lacks the resources to develop it, I’ll be willing to do it contractually and provide the product to Sun’s gaming team for approval and integration.

#2

I’m opposed to this. Apart from the fact I don’t use JOGL so it’s no good to me, this is precisely what code signing is supposed to be for! And if you need persistence, you can communicate with the server or you’ve got the preferences APIs. I most certainly wouldn’t like an untrusted applet to have access to any networking APIs that allowed it to communicate with anything else other than the server it came from.

Cas :slight_smile:

#3

The preferences API requires code signing, so it’s useless for unsigned applet/JWS (well JWS has its own jnlp.prefs class, but applets don’t). And it works for small resource, not large ones (try and save the state of a single person RPG in 2kb).

When you accept a certificate , you basically grant full access to your computer, what I propose is an API that works like the JNLP services, and always ASK the user whether he grants the access or not. Personally I’d rather rely on the latter.

For instance, you discover a new game from a new editor, there nothing preventing it for installing spyware,browser toolbars or whatever on you computer once you’ve accepted its certificate and its EULA if provided.

With my solution, you know for sure it won’t do anything outside what the gaming extension provides, as the game code remains unsigned.

The alternative is to provide the same API with another provider (like puppygames), but unfortunately you don’t have the same marketing power than Sun.

Lilian

#4

Largely speaking, if I trust something, I want it to do anything that it feels like. It can format my harddrive if that’s what it wants, because I know who’s responsible. I think that the extra confusion around sub-permissions will probably just, well, confuse already fairly braindead users even further.

Cas :slight_smile:

#5

I vote against it too.

As I understand it, the input stuff can be used to poll input devices even when your applet does not have the focus… so it can easily be used for spying. Combine that with open communication on the network and you have no security at all. You can sniff passwords as the user accesses their bank account in another browser window and send the data to anyone on the net.

Cas’ is right. There is a reason for the applet sandbox and signing code to get privileged access.

#6

That kind of feature has been in use for java web start applications for years (the jnlp services)… you just have to provide a different API than the unsafe one.

For instance, the file access in JNLP is done by a FileContents, not a File, so you can’t use an InputStream(File) to read the files everywhere.

As for gaming or network API, the same approach could be taken (like allowing poll of keyboard only when the applet/application has focus, and using network IO only to communicate with targets selected and approved by the player).

In the desktop java world, it has quite a lot of supporters

Lilian

#7

And how do you suppose LWJGL and SWT support this ?

#8

My proposal is for a java gaming extension with the “Sun” brand. This is already the case with jogl as the certificate signing it is coming from Sun.

If the API is open, all the JWJGL users could use it (look at the SPI specs for JNLP : different implementations for the same results) though with their own certs, not the one from Sun), and try and build a name and brnd recognition in the gamers community.

Think about the benefits : you can deploy free(or not so free) games, without requiring code signing for your codebase, and rely on a trusted API coming from a trusted source (Sun or lwjgl.org) : this is a win for you (no more signing) and for your users (no need to trust you, only the extension mecanism). Something other technologies can’t propose.

For SWT, I’m sorry I like this framework but i don’t see how it could be included in the extented java gaming API. my idea is more to have a clean, neat and secured implementation of useful untrusted APIs to leverage the gamers experience, not to adapt everything to fit in :wink:

So for LWJGL : good idea and good promotion for the lwjgl brand , for SWT : sorry.

Lilian

#9

I’m kinda fed up with Sun-branded stuff stomping on everything like this… I’d rather the status quo were maintained. Signing works for me just fine.

Cas :slight_smile:

#10

I understand your point of view even if I don’t agree with you.

I will also continue signing my apps and will try to gain confidence of the gamers the usual way : " use a trusted certificate", “use an up to date antivirus software” and “google for company reputation/problems”.

Lilian :slight_smile:

#11

Actually I almost agree with you… but the issue is that Java is already horribly bloated and complex and no-one ever really agrees on an implementation that suits everyone, and what we end up is, say, autoboxing, java.util.logging, java.io.File, and other atrocities. Best to leave it out if there’s not unanimous agreement!

Cas :slight_smile: