Weird symbol on java applet windows

Java 2D
#21

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

Example:

  • user goes to webpage
  • applet loads, security dialog says “grant access to printer? y/n”
  • user gets scared, says no, or just navigates away completely.
    vs.
  • user goes to webpage
  • applet starts up, user happily clicks around, paints pretty picture
  • user clicks “print”
  • security dialog “grant access to printer?”
  • user is fine with dialog, since they initiated the whole process, clicks yes

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.

#22

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

Yes, that’s the general idea. Not sure about programmers-reason thing, one can
give 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, but
only the client can control that through the policy file) that app can request, and if apps needs a
specific permission, it can request it in some way (during packaging, probably).

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

Dmitri

#23

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.

#24

Yes, that makes sense.

Dmitri

#25

[quote]Quote from: irreversible_kev on Today at 10:12:17 AM
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?
[/quote]
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 :-X…

http://www.java-gaming.org/index.php/topic,16911.msg132800.html#msg132800

http://www.java-gaming.org/index.php/topic,16911.msg134132.html#msg134132

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

scenario could be for example :

=> in applet :
getPrivilegedClassInstance(Robot)
=> sun dialog asking if user want to allow mouse and screen access
trows RefusedPrivilegedClassException
or
return new Robot

#26

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.

#27

I just think the whole security thing completely lost its focus on the use cases.

I believe that a signed applet should be granted any and all permissions automatically by default by a standard Java install unless revoked by a user.

That is, signed by a root CA, not self-signed.

Cas :slight_smile:

#28

I believe that a signed applet should be granted any and all permissions automatically by default by a standard Java install unless revoked by a user.

You mean, without the security dialog?

Dmitri

#29

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

#30

Yes, I mean without any security dialog.

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.

I now don my flameproof underpants and await your roastings.

Cas :slight_smile:

#31

About the 3D acceleration:

I think that it should display some warning dialog (instead of normal security dialog and ideally just embedded into applet area as mentioned by someone so it doesn’t block browsing in other tabs) that 3D acceleration is going to be used and what risks it posses, which unfortunatelly are because of bad drivers… Though JRE 6u10 and it’s out-of-process ability can fix a lot (eg. disabling any D3D usage and not messing with browser process).

The warning dialog should ask only the first time. It could detect if 3D is alright when the applet/application ends successfully and mark that the user shouldn’t be asked again as it’s working for him.

This should cover both of JOGL/JOAL and LWJGL. OpenGL API is pretty secure by design (don’t know how JOGL handles it, but for example LWJGL is checking inputs and tracks state to prevent any bad memory access), so it shouldn’t be problem to allow it’s usage for unsigned applet/app.

#32

The question is, why you need signed application? I bet it’s because of 3D acceleration. If that would be handled gracefully (as outlined in my previous post here), it would leave signed applications only for special purpose things, where I find current security dialog a very proper solution. I agree with Matzon that signed code shouldn’t be allowed to run by default.

#33

It works like this:
An additional jar is added to the applet archive list, which is signed containing a loader class and a custom classloader. When this loader class is called it replaces the loaded securitymanager with its own (after the user has accepted the security question), which basically allows everything. Now you can tell the loader class to load a jar, it will load its classes through the custom classloader which has the original classloader as a parent. The beauty of this, is that the security popup is deferred until the unsigned applet loads the loader class from the signed jar.

I agree the current way it works (security popup) is fine for privileged actions, the user can accept it or not. And we developers can detect if the user accepted or not and act accordingly. Instead of using an “extensionloader” like I outlined above it would be nice if the JVM did this for us, check if an privileged action is invoked, check if the user accepted the security popup or not. Of course with this security popup it should have an option “reject”, “accept once” and “always accept (for this applet)”.

#34

[quote]A signed applet isn’t in the least bit safe - it can do anything.
[/quote]
Yes, and that is why it shouldn’t be allowed to run - by default.
We should however, work on allowing as much as possible without annoying the developers and end users - and still keep it safe.

When I run an exe file, its an active conscious thing I do. Having all sorts of applets execute isn’t one (especially from shady sites).

#35

[quote]When I run an exe file, its an active conscious thing I do. Having all sorts of applets execute isn’t one (especially from shady sites).
[/quote]
+1

yes and even if they are signed/verified and from great compagny this is bad things, I mean if I go to sun web site and they have put a signed applet to do something great, I dont want this applet to be able to access my computer and for example I dont want him to write file even if those writing are not intended to hack or break anything, I just dont want new files in uncontrolled folders on my computer without having previously granted permission to it.

This is only a very simple example but even well written code that are not intended to break or hack can do computer dammage or cause dammage to the end user and end user should be able to go anywhere on the Web with NO risk except if he know.

#36

You’ve got a point about applets executing whether you like them to or not - rather like Flash executes whether you want it to or not. But that’s why I suggest having the ability for users to turn the dialog back on if they want to.

It would indeed solve the vast majority of problems if we had that endorsed library Sun-signed thing (so we could get LWJGL signed for example and then it wouldn’t need any further permissions) but as you can see even JavaFX fell foul of the whole issue on its maiden voyage and screwed it up, so fat chance of that ever happening.

Just 1 further point you might want to chew on: you lot are all geeks. Proper, high-order grand wizard pointy propeller head geeks. You know about this stuff and even more strangely, you care. You are fundamentally interested in how things work and what they’re doing. But the rest of the world does not give 2 shits. They just want stuff to work (which is largely why they click yes on nearly any dialog - “Do you want to grant permission to DodgyCorp.ru to access your computer so you can play Craptris?”) Given that, they don’t care about files being written to their hard drive any more than they care about how much heap the VM allocates on startup. They don’t care, they don’t understand, they don’t even want to understand. All that matters to a normal person, a non-geek, is that the machine does what it is asked!

Cas :slight_smile:

#37

I agree to the geeks thing.
Most people I know ignore the warnings and if its possible to turn off the warnings they will.

#38

and just as important, that they dont do stuff I didn’t ask them to do :wink:

I realize your point, many users really are clueless and will say yes to anything, and then complain afterward. However if Sun sets the bar for security too low, they will get flamed.

#39

True, true… And (I assume) we’re all good geeks here, but we know there are evil geeks too. The problem with the web is that you can easily stumble upon a website you didnt want to (redirect, wrong click etc). And if such a page contains an evil applet that screws the computer without notice, the user probably wants to disable all applets, and asociates applets==bad, and then we’re all back in 1997 again :confused:

A popup doesnt have to be bad, can be userfriendly and maybe popup only once per author (signer) if you tell it so, it can simply say something like: “Yes i want to play games from this author”. The notice must be clear (the flash way), and prefably be skinnable in some way, because Sun’s own look&feel doesnt look/feel too good.

#40

Skinnable dialog = scope for abuse.

But a single, userfriendly dialog that appears but once ever for any particular signing certificate would suffice, and I’d like to be able to turn it off or have it follow other OS settings (eg. on Vista, UAC)

And likewise any Sun-signed code need have no dialog at all.

Cas :slight_smile: