Has anybody filed a bug report or an RFE that we can vote for on either security granularity or the Sun-endorsed extensions thing? IMO this stuff is almost so badly broken, or at least so hostile to both user and developer, that it could qualify as a bug. The security model is plain effed for applets, it’s been well known bad security practice for years to grant full permissions to anything that doesn’t need them, and a model that requires full permissions to display 3d is just messed up and broken. This really should be fixed, stuff like this does more security harm than good…
Just to point out that the ‘weird symbol’ is really not-fully-thought-through…
If you maximize a window, the icon is exactly over the close button (!) in the titlebar, making it hard to close the darn thing.
I still think dialogs are not a good idea for applets in general. Applets are applications embedded in webpages, every user notification schould also be inside the browser and scroll with the page.
The only exception are applets which are invisible or have small bounds which could fallback to the current behavior.
regarding the “weird” symbol issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6749517
btw: ea u12b02 is available with initial 64bit plugin
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695
I agree, especially because popups are so annoying.
I wonder if there are users out there who are so accostomed to closing popup-ads that they just close security dialogs without reading them. Or they just go with the default, which is “cancel” for self-signed applets. It would certainly explain a lot.
The importand thing is telling the user what he did in this situation. E.g an canceled applet could contain a standardized banner telling the user that it has been canceled by him and if he clicks on the applet area it will relaunch. solved 
[quote]I wonder if there are users out there who are so accostomed to closing popup-ads that they just close security dialogs without reading them. Or they just go with the default, which is “cancel” for self-signed applets. It would certainly explain a lot.
[/quote]
I refuse several security dialog including lot of webstart asking privilege including some showed here, not because I think there is a virus or anything, just bacause I dont want for example that webstart or signed applets install something in my computer or because I have other application opened and I dont want them to be crashed due to lack of memory or other
EDIT: because… hum… I could not understand what I wrote , so even if my english is worse I think I wrote this post a litlle bit too fast 
I wish that were possible with the Java security dialogs. Right now if someone clicks cancel, they have to restart the browser just to get the question again.
Yeah that’s another thing, how many people think those dialogs are malware? Typical IE+MySpace users, I’m looking your way Oh well, they probably don’t want to play games anyway.
this is actually what i had in mind, this functionality should be provided by the browser plugin rather than by the application.
RFE:
-replace dialogs with in browser rendered content
-specify a default behavior which solves the “user canceled applet” + “applet failed to load” scenarios by providing a default relaunch button rendered instead of the failed applet
what do you think?
Prototype it and show us.
Cas
maybe i would give it a try… if webstart would be open source…
I didn’t see any yellow sign for java applets, ??? ??? I only got those when I am running webstart application.
[quote]Most people I know ignore the warnings and if its possible to turn off the warnings they will.
[/quote]
you can do it with IE, but really dont this is a bad idea.
[quote]this is actually what i had in mind, this functionality should be provided by the browser plugin rather than by the application.
RFE:
-replace dialogs with in browser rendered content
-specify a default behavior which solves the “user canceled applet” + “applet failed to load” scenarios by providing a default relaunch button rendered instead of the failed applet
[/quote]
I think that possible to use a workaround simulating that for self signed (or for people with lot of money that can afford two certificate…) it is probably already possible using two similar applet version server side signed with two different certificates, first you try to load the first one then if it fail you warn the user on a nice way and pretty window “hey you cannot play doing that …blabla…” then you propose him to click somewhere to start again and then load the second signed Applet… maybe a work around but I realize that it is a bit too much complicated to be usable
If you maximize a window, the icon is exactly over the close button (!) in the titlebar, making it hard to close the darn thing.
I think that got fixed in 6u12 (btw, early access builds are available at http://jdk6.dev.java.net, b02 has slightly different warning icons).
Also, as I mentioned, there’s an API which allows you to place the icon.
Dmitri
The icon besides the applet window is really strange, true, but what’s the big deal anyway?
Applet’s shouldn’t have any pop-up windows in the first place. If you’re annoyed by the icon, just realize that your users are at least as annoyed by your popup, so do the most sensible thing and just get rid of the popup.
Regarding the permission dialogs problem, I think many of those could be handled if there would be a number of standard GUI controls that don’t need extra permissions, like print buttons, ‘go full screen’ buttons, browse buttons etc. If the user clicks such a button, he implicitly gives permission.
Excuse me…? Not every applet is a game.
There are situations where a Dialog (with a lot of components, not just yes/no/ok/cancel buttons) makes perfect sense in an applet.
But every applet is embedded in a webpage, and most of them are games (hey isn’t this java-gaming.org? ;)), and as such I don’t think it’s such a big deal. An applet breaking out of the browser is IMHO generally annoying, like other pop-ups for which we have popup blockers.
Of course there are some cases where dialogs make sense and of course the strange icon has to be fixed/removed, but maybe those cases would be better suited to JWS? And maybe it’s better to have such applet dialogs internally inside the applet?
I guess we won’t agree on this one (luckely we don’t need to)
Anyway, JWS’s reliability is worse than that of applets. Applets can cause the browser to display the yellow-plugin-installer-bar, while JWS simply shows the plain XML, which is a very bad user experience. Further, there are many bugs in JWS, like the ‘it worked the second time’ behaviour which occurs way too often, even in 1.6.0_u10.
Applets shouldn’t be second-rate citizens. Applets, like other applications, have just the same reason for having multiple windows like other application - jws. The Irony here is that WHEN an applet is properly sandbox, we are STILL warning the user that they have a suspicious-beware-cant-hurt-you-anyway window : If the windows is from a signed applet - and thus 1834984920% more unsafe, the user is never shown a warning. :persecutioncomplex:
There should not be a warning - EVER. It simply doesn’t make sense. Not only because I can do it using javascript to open a new window with an applet in it - but also because there is absolutely no reason what so ever in warning users about a window.
Hehe, you’re absolutely right!
Maybe we (well, me anyway) have to reconsider what an applet is and what the goals are.
They were typically always these small embedded parts of a webpage used for small games, banners and menu’s and such. But with full applications running from the browser (RIA) becoming more popular, java Applets should be able to be the platform of choice for that.
So yeah, I have to admit I have to reconsider my previous standpoint that popups from an applet are annoying :persecutioncomplex:. In many cases they are, but it should at least be possible to do without annoying everyone with intrusive pointless warnings.
But what do you all think about my previous idea about standard GUI controls that implicitly grant extra permissions (browse buttons, full screen buttons etc)? Might be worth an RFE, as I think it could solve many security dialog annoyances.
Would be too much limiting. And there is already support for such things in JNLP services (from 6u10 also for applets). It just needs to expand provided functionality.