New feature: applets?

General Discussions
#1

I’ve been giving this some thought, and I really can’t imagine a safe way to embed applets in JGO.

The problem is that applets are allowed to connect to their ‘codebase’. This rules out hosting jar files and class files on JGO, because the applet can make HTTP request to the SMF forum, having the same privileges as the member that is viewing the forum: if somebody were to open a hostile applet, it would potentially modify that member’s posts on the forum. Even worse, if I were to open such an applet, it could take over the entire forum in a matter of seconds.

You could suggest we would remove the upload feature (attachments / avatars) so that people wouldn’t be able to upload their jars/classes/applets there, and hence wouldn’t be able to use JGO as a codebase. We would really have to disable all attachments, because uploading a *.jar as a *.txt, would still enable the JVM to load it as an applet.

The alternative would be to make some kind of an AppletViewer, like included with the JDK: loading the applet in an external process, in its own Frame, with a SecurityManager that basically allows nothing at all, as the codebase would be the local machine.

I might be missing something, so if you think there is a reasonably simple solution to this problem, please share!

#2

personally, I’d rather not have embedded applets on the forum. Better to keep them in a different location or site.

#3

maybe with an IFRAME (pointing to the host Applet domain) will do the job better, no security problem and more possibilities, also Applet still sucks when they start, probably it should only start when user click on a preview image

#4

I like the iFrame idea, I have seen really nice implementations of applets that load once you click on an image. comes across looking very “flashy”

Somthing else to consider, it may be better if people who know what they are doing use applets anyway.
So it may work nicer if applets are embedded using a custom codebase and hosted offsite.

Another solution is an Applet within an applet, similar to the LWJGL appletLoader. but that sounds like a bit of work to setup.

#5

Seems like a can of worms to me! I’m quite happy to click on a link or a screenshot that takes me to the game.

#6

as flash video it is more user friendly especially when one want to show something in a mini-applet, little game, little demo, sample…

[quote]Another solution is an Applet within an applet, similar to the LWJGL appletLoader. but that sounds like a bit of work to setup.
[/quote]
not that much, it is pretty trivial, here is a sample

#7

Then the applet tag would have to be hosted on that other domain… it’s not like you can do

#8

It must not be possible ? cross-domain scrpting is a well know security hole usually well handled by browser, no ?

#9

Also, other then playable games there is no real reason to have an applet anywhere, ever :slight_smile:

Something like a clone of the java4k site would be a better place to keep applet games.

#10

Since most people can make their own hosting, the main disadvantage there is that links eventually may well die. The same problem remains in linking to hosts via whatever tricks you guys might come up with.

Perhaps recommending people to put games into existing sites like GameJolt or JavaGameTome would be a solution, as that would also increase both the chances of gaining more exposure and longterm survival of the links, and since that sort of service is probably not the aim intended for launching directly from the forum.

Both activities, making your own hosting ( for the in-progress version ) and releasing to a ‘publisher’ of sorts once the game is playable, could be considered essential to the craft so makers should be encouraged to do both. Hosting builds basic understanding of html + how anybody can host their own stuff with a little work. Publishing gives you an idea of how hard it is to get more than a handful of people to play even passable games…

#11

There are specifications and implementations. The differences are bugs, of which there are many.

#12

maybe in that case flash (video embeded) could not be considered secure too (I “suppose” flash plugin have bugs too ?), also links to website with signed applets should popup a scaring alert, anyway you are right there are probably others ways that are a lot more secure than IFRAME, I was just thinking it would be the most user friendly and the easiest to setup.

#13

I would argue that all forum admins are going to be using secure browsers. If some user with an older browser gets their session hijacked, the damage possible is minimal (and they deserve it :)).

However, many applets (even if hosted elsewhere and just linked from here) ask for full permissions and can take over your machine at that point, no matter what. If we were being paranoid about security, we wouldn’t allow links to applets or JWS that ask for full permissions.

+1 for the iframe solution.

#14

I don’t think there’s really a need for applets here, so I wouldn’t waste time on that.
Every remotely serious developer has ways to host an applet, so links to them are just fine by me.

#15

There is no such thing as a secure browser. There are zero day exploits in every browser.

#16

The more important point is that it doesn’t matter: as soon as you click “Yes” to the security warning, I own your PC if I wanted to. There is no need to get all nervous about iframes if you aren’t nervous about that.

We could also just provide a zip file with instructions on the command line parameters needed to run it. ::slight_smile:

#17

The problem is the same with unsigned applets.

#18

Which we do nothing about. It is normal or even expected for people to post a link to a JWS or applet that requests full permissions. Unsecure is unsecure. Might as well embed an iframe in the forum.

#19

It seems that every solution has its down sides. Its just unfortunate that flash is some what seamless in comparison to Java. Whats more, It sux that applets dont have a paramater to prevent auto start.

if an applet loads another applet in a seperate classloader wont that prevent the client applet from getting access to resources outside of the classpath?

#20

A solution begging for problems.

A good old url to the applet html page is sufficient.

My middle finger is still functional, which means I can easily open that link in a new tab and safely keep browsing the JGO forums :slight_smile: