I wonder if I should post it here or on the LWJGL forum but hopefully most people look at both places

I have an applet that works fine in eclipse and worked fine with the JOGL applet loader but when running it with the LWJGL one I run into a security problem.

All I do is:new URL(getCodeBase(), "pictures/" + name)(I tried it with one parameter as well as without a subfolder but it always gives the same error, doing .toString() on the URL gives me the correct URL so it isn't a problem with a slash)

The error I get is:SecurityException: denied access outside a permitted URL subpath

Do I need to sign my applet when using LWJGL even though I create a connection to the same server as where the applet is located?

just a quick update, I've managed to get the current LWJGL AppletLoader to work when using a crossdomain.xml file such as http://kappa.javaunlimited.net/temp/crossdomain.xml just put that on the base of your domain where the applet is hosted, its not a proper fix but should get you going for now, will update you once a proper fix is found.

there is an issue. JOGL is just openGL drivers, and in themselves, openGL drivers are completely benign. I can fully appreciate why it's been given a secret cert. LWJGL on the other hand also includes JInput and "LWJGLInput". Input is a different kettle of fish. Input allows 1 pixel wide applets to sit quietly in other tabs reading your keyboard strokes while you log in to Natwest Bank in another tab.

What will have to happen is that we'll have to couch the input initialisation stuff in a privileged access. So the LWJGL libraries can be used by unsigned applets and webstarted applications, but attempting to use input will require privilege escalation and therefore fully signing your applet.

<edit>And LWJGL display fullscreen support likewise opens the possibility of a crafty phishing attack, so that'd have to be wrapped too.

there is an issue. JOGL is just openGL drivers, and in themselves, openGL drivers are completely benign. I can fully appreciate why it's been given a secret cert. LWJGL on the other hand also includes JInput and "LWJGLInput". Input is a different kettle of fish. Input allows 1 pixel wide applets to sit quietly in other tabs reading your keyboard strokes while you log in to Natwest Bank in another tab.

What will have to happen is that we'll have to couch the input initialisation stuff in a privileged access. So the LWJGL libraries can be used by unsigned applets and webstarted applications, but attempting to use input will require privilege escalation and therefore fully signing your applet.

<edit>And LWJGL display fullscreen support likewise opens the possibility of a crafty phishing attack, so that'd have to be wrapped too.

Cas

web browser based security is always an headhach... anyway about the security did you thought of screenshot ? because a "1 pixel wide applets" could monitor your screen too and show a lot of personal information peope would like to mask.

What will have to happen is that we'll have to couch the input initialisation stuff in a privileged access. So the LWJGL libraries can be used by unsigned applets and webstarted applications, but attempting to use input will require privilege escalation and therefore fully signing your applet.

<edit>And LWJGL display fullscreen support likewise opens the possibility of a crafty phishing attack, so that'd have to be wrapped too.Cas

Unfortunate about the fullscreen issue. Is it possible to make security popups at runtime?For example, if the webstart opens in window, then requests fullscreen, first show security popup.

However I'd say the easiest way to go about this is don't sign jinput.jar with the magic certificate (LWJGL doesn't really need it except if you want to use controllers) and disable fullscreen for the LWJGL jar that is signed with the magic certificate, if you need those features just grab the standard LWJGL jars and sign them yourself.

So LWJGL would just provide lwjgl_applet.jar (same as lwjgl.jar but no fullscreen and signed with magic certificate).

The hardest part is getting Sun to give us a magic certificate or agreeing to sign jars for us

it is the case, well at least from my tests, unless theres a way to create and poll a Keyboard without a Display. So really its just JInput and Fullscreen that would need extra security permissions. Could alternatively just bind exiting fullscreen when escape key is pressed (like Flash).

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