I think it is a replacement for the old "Java Applet Window" border on the botton of the window. Whats actually really anoying is, you can't maximize the window anymore (even with signed applets..). There will be always the gap fo r the icon. I already filed a bug a few month ago which has been closed almost instantly after i filed it.

its a shit feature - now I have to explain world + dog why they have a yellow triangle attached on the right side of a window.Damn it - why do applets and java have to be so broken to actually supply to customers

It's also annoying that the 'contentpane border' is BLINKING YELLOW the first second it gets focus! If you mess with lots of modal dialogs in your applet (well... at least I do), both the created dialog and upon closing, the 'parent' will BLINK!

Dear customer,

My applet is dangerous, it has windows, which may confuse you.It blinks all borders as a clear warning to you.We'd prefer a fullscreen shroud, like Vista security popups, and play a sound.As we like to say, a sad customer is better than a hacked customer.

Enjoy shopping!

I think I'm going to window.alert() this message on the frontpage.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I fully agree with Matzon. This security banner is pointless. There are many ways how to forge some system dialog asking for password/etc. Just some image based web can do that with imitation of common OS themes. IE can do fullscreen without problem, etc. Most of people uses default themes of few OS out there... So, please get rid of it. It just complicates our lives for correct usage.

Next issue is with unsigned/signed applets/webstart apps. You either can do very little, or you must have all privileges. Which is very wrong to ask the user, if the app just need for example: fullscreen mode, mic support, file access (at least the last is fixed with JRE 6u10 by allowing JNLP services in applets too). All these things can be done by asking user before first usage (and not before app runs) without exposing bigger risks such as full filesystem access.

nope, you can only with very old version maybe (5.5 and earlier), you cant with 6.0+, user have to press F11 for real fullscreen, website cannot force it.

Quote

Most of people uses default themes of few OS out there... So, please get rid of it. It just complicates our lives for correct usage.

the way it go is more that browser security are higher every day (less freedom ofcourse)

Quote

Next issue is with unsigned/signed applets/webstart apps. You either can do very little, or you must have all privileges. Which is very wrong to ask the user, if the app just need for example: fullscreen mode, mic support,

using micro or fullscreen in flash warn the visitor too and that's a good thing no ?, flash just better know how to make those things look smoother and more natural.

nope, you can only with very old version maybe (5.5 and earlier), you cant with 6.0+, user have to press F11 for real fullscreen, website cannot force it.the way it go is more that browser security are higher every day (less freedom ofcourse)

using micro or fullscreen in flash warn the visitor too and that's a good thing no ?, flash just better know how to make those things look smoother and more natural.

Yes, but notice the important details, that a) users get informed what function app needs, b) app get access to just that function and not whole system... compare to Java where there is scary security dialog with certificate. I don't have anything against that dialog, it's very ok when you need some special stuff for example... but not for common tasks. It's just not right to see too many applets that requires full privileges just for some common thing.

If you drag and maximize you you should see a gap on the right side of the screen.

(tested on win xp)

If you initiate a 'Click & drag' when the browser window is being displayed on anything but the primary display device, it completely stops repainting your window.You have to drag the window onto your primary screen for the repainting to start working again

Also, when you first initiate the Click & drag op (click/drag but dont release), the window dragging appears to be broken. It's hard to determine exactly what is interferring with the dragging.I have to drag/release/redrag for the window to have full freedom of movement across the desktop.

Anyone else experiencing similar behaviour? (this is all with u11 in FF)

If you initiate a 'Click & drag' when the browser window is being displayed on anything but the primary display device, it completely stops repainting your window.You have to drag the window onto your primary screen for the repainting to start working again

interresting, i have a dual head setup too - never saw this behavior. I remember once it wasn't possible to drag the applet out of the main screen at all but i am not sure it it was windows or linux.

Also, when you first initiate the Click & drag op (click/drag but dont release), the window dragging appears to be broken. It's hard to determine exactly what is interferring with the dragging.I have to drag/release/redrag for the window to have full freedom of movement across the desktop.

Anyone else experiencing similar behaviour? (this is all with u11 in FF)

you should see similar behavior with the javafx samples. Something happens behind the scenes if you release the mouse the first time difficult to say what.

Just by building this app i filed around 5 bugs regarding the draggable applet against u10 ea releases. I had the feeling that the draggable applet feature wasn't tested internally at all. It looked for me like the draggable applet was initially never intended to go for production and stay a proof of concept.... well the rest of the storry is marketing.

(technically: what is the best unit test for the out-of-proccess applet? -> make it draggable)

So what would you like to see? What's the scenario you'd like your users to go through?

For the following cases: - unsigned applet (doesn't go full screen, or even maximize window) - signed applet which attempts to execute some privileged operation

We're discussing changes that could be made (probably in jdk7 time frame) so nowwould be a good time to speak up (but be reasonable)..

Ideally, I'd like to see no warning for unsigned applet unless it gets maximized.

The problem is, of course, that showing a window is already a privileged operationin some sense. It didn't make sense to disallow it for unsigned applets, so they put a warning on it instead.

The only reason I heard of for having the warning banner is to avoid spoofing - presenting a user with a false page and leading them into entering their info or something.It would seem that if someone managed to stick a malicious applet onto apage you'll have bigger things to worry about, so may be this should be reconsidered.

For signed apps, there should be a way to specify exactly which privileged operations it is intended to perform, and perhaps ask the user to allow/deny particular operations.

It would probably need to be done before the applet is started instead of when the operationis about to be performed.

It would probably need to be done before the applet is started instead of when the operationis about to be performed.

Here ( http://demo.dzzd.net/FPSSample9/ ) is an example of an applet that starts without any security dialog.Then, when the user requests to use better mouse control (that requires the use of the Robot class), a security dialog pops up.

It is a definate improvement over having a security dialog at startup as it gives a chance for the applet to inform the user that a security dialog will pop up.

In the short term, I'm told that there's an internal API (in com.sun....) which allows the developer to control where the warning icon is placed (within window bounds, and it's guaranteed to be visible).

So you could place it in the title bar, for example, so it's less prominent. Not much help for undecorated windows though.

It would probably need to be done before the applet is started instead of when the operationis about to be performed.

(the following on a purely theoretical level, ignoring pesky technical issues)

Does it really make sense to put the allow/deny queries before the app has even started? This is exactly the kind of clunky user-unfriendly experience which people have grown to hate about existing applet/webstart security model. At the point where the user is asked to make a decision they don't know what they're granting permissions for - they don't have enough data to make an informed decision. IMHO they should be asked when the app actually tries to use the functionality, when they know the context it'll be used in.

The important thing about the above is that the average case of the user who turns up, makes a bit of a picture but doesn't want to print it never sees a scary security dialog.

Asking at start up makes even less sense when an app wants multiple permissions. If you load an applet and the first thing it asks is "grant access to hard drive", "grant access to network", "grant access to printer", "grant access to bank account" then they're going to run a mile. But if permissions are asked individually as required by the app then it's generally a much smoother and less scary experience.

As a side bonus, if you ask the user and they refuse then app code can catch the security exception (or similar) and provide a helpful message to the user ("We noticed you refused access to the hard drive. This means your preferences won't be stored"). Again this reduces scariness and makes the experience smoother without compromising security.

Here ( http://demo.dzzd.net/FPSSample9/ ) is an example of an applet that starts without any security dialog.Then, when the user requests to use better mouse control (that requires the use of the Robot class), a security dialog pops up.

It is a definate improvement over having a security dialog at startup as it gives a chance for the applet to inform the user that a security dialog will pop up.

Nice. How does it do that? Reload a signed version of the applet or something?

where <PROGRAMMERS-REASON> = "To enable the easier to use first person shooter mouse control."

This example might look a bit ugly but to be honest its already ugly in the sense that it is scary.

Yes, that's the general idea. Not sure about programmers-reason thing, one cangive a reason like "give me this permission and you'll be rich!" =)

Basically, I think there would be a known list of permissions (which already exists, butonly the client can control that through the policy file) that app can request, and if apps needs aspecific permission, it can request it in some way (during packaging, probably).

When such applet is loaded, user will be presented with a dialog listing requestedpermissions.

I agree with the replies, in that we need this granular access (I think it already exists in applets - or at least I seem to remember back in the old days).

But from my point of view, there are two groups of application those that can run with as little permission as possible and those that need permission.Adding the granular access makes this better for the group that needs the access. However for the rest of the applets/jws applications that run with basic permission, are already sandboxed. So no need to warn the user about _any_ _thing_. No 'Warning: Applet Window' or Yellow exclamation mark - whats the point? I could just have well opened a browser window with an applet in it - instead of an applet window.Fortunately, you fixed the remote connection from applets in update 10. Should have been done *years* ago - but it is here now - just have to wait ~ 5 years for people to upgrade.

Witness the JavaFX mess with native components that required a user to accept a SECURITY: DANGER! DANGER! dialoge before they watched a video stream.

Flash - although it has issues also - has a LOT better user experience, and we need that same 'feel' when launching our applets or jws.

(the following on a purely theoretical level, ignoring pesky technical issues)

Does it really make sense to put the allow/deny queries before the app has even started? This is exactly the kind of clunky user-unfriendly experience which people have grown to hate about existing applet/webstart security model. At the point where the user is asked to make a decision they don't know what they're granting permissions for - they don't have enough data to make an informed decision. IMHO they should be asked when the app actually tries to use the functionality, when they know the context it'll be used in.

The important thing about the above is that the average case of the user who turns up, makes a bit of a picture but doesn't want to print it never sees a scary security dialog.

Asking at start up makes even less sense when an app wants multiple permissions. If you load an applet and the first thing it asks is "grant access to hard drive", "grant access to network", "grant access to printer", "grant access to bank account" then they're going to run a mile. But if permissions are asked individually as required by the app then it's generally a much smoother and less scary experience.

As a side bonus, if you ask the user and they refuse then app code can catch the security exception (or similar) and provide a helpful message to the user ("We noticed you refused access to the hard drive. This means your preferences won't be stored"). Again this reduces scariness and makes the experience smoother without compromising security.

Quote from: irreversible_kev on Today at 10:12:17 AMHere ( http://demo.dzzd.net/FPSSample9/ ) is an example of an applet that starts without any security dialog.Then, when the user requests to use better mouse control (that requires the use of the Robot class), a security dialog pops up.

It is a definate improvement over having a security dialog at startup as it gives a chance for the applet to inform the user that a security dialog will pop up.

Nice. How does it do that? Reload a signed version of the applet or something?

nop, it works the same (with some improvment) way as the hardware switch (H key)

- This method was initied a long time ago by Thijs and me. It is probably at the origin of "working" JOGL applet and JOGLAppletLauncher ..... not mentionned anywhere ...

the idea behind is to request right to a loader and use this loader to perform remote or local privileged package/class loading at runtime.

In this sample there is no "break" on the game : for example hardware switch or mouse control switch is done at runtime and loading (for hardware) use streaming no game lock. the applet remain the same and only few class get privileged right

I agree, on demand security permission dialogs are probably the best solution but there should be also a checkbox like "don't ask me again for this application" for the users which think to know what they are doing.

Maybe it would be even possible to open a dialog right after JRE has been installed which allows the user to opt in some options like "always allow media" or "always allow hardware acceleration" which can be of course only done for official sun libs (e.g javafx stuff).

The only question remains what to do with libs like LWJGL? I really don't know. A similar approach is possible per library or certificate but i am not sure if it is already to complicated for the average user.

But why not start with the easy things first ? A nicer looking security dialog could be rendered undecorated on top of the applet and scroll with the page instead of the ugly window... There is currently also a default behavior missing which defines what happens if the user does not agree with the security permission. Something like "application canceled by user click here to reload applet" would be IMO sufficient for applets.

signed applets should behave exactly like a non-singed applet - until it tries to do something that requires access. Then the dialog shown will also contain some info about the application being signed. Of course, one can execute someking of grant-<permissions>-permission-thingy in the start of an application to get it over with, so to speak.

Signed applets should NOT be alllowed to run - unless I have allowed it. The potential for a CA to give someone a cert is too high.

A signed applet isn't in the least bit safe - it can do anything. People seem to be getting all confused about what signing actually does. It doesn't make anything safe. It just means you can guarantee that the code hasn't been tampered with since whoever it was signed it did the signing.

The fact is if you're worried about websites that put up malicious keylogging applets or screen spoofers or hard-drive bashers... then somebody somewhere has to sign those applets and that those somebodies will be therefore traceable. So those sorts of applets will exist in the sorts of places where people who are Good Citizens in the first place aren't going to be going to.

Matzon has big paranoia about applets being allowed to run if signed when he hasn't explicitly allowed it - but I bet you he's perfectly happy to download a .exe installer and install anything on his hard drive at face value. That's where it all breaks down. People already are entirely happy to compromise their own security by clicking "yes" when they want to run something when they honestly have no idea what it's really doing.

I realise this probably puts me firmly in the firing line for every security pundit and paranoid netizen floating around here but you have to ask yourselves - what really are the advantages of the scary dialog? What are the advantages given users actual behaviour? How might you get rid of the security dialog if you wanted to but if you're paranoid ensure that it comes back? So I say: remove it by default for signed code, and allow power users to turn it back on. Sod the granularity stuff, they'll take bloody years putting that into the JRE. You know what Sun are like.

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