This could be interesting for folks around here:
http://java.sun.com/developer/technicalArticles/GUI/SecurityWarning/AppletWarning.html
The article discusses the evolution of the warning banner, and also explains the new API for specifying the location of the warning icon…
Dmitri
It still doesn’t appear to be much use 
I think the whole thing needs rethinking a bit.
Also why is it that when I go to see demonstration code, not even Sun uses applets?? Can you even imagine a Flash site not showing its demos off as Flash applets?
Cas 
Good point about the demos. I’ll pass it on.
Dmitri
To clarify: the demo is there, but it’s not an applet but a webstart-ed app… Is that what you meant?
Yeah. This stuff should be easily demonstrable in applets shouldn’t it?
Cas
I expected an applet too.
Edit: Hmmm - update 12…
it’s funny they don’t work on resolving those issues, but make them more appealing to the eye.
users still will be appalled by them, no matter how nice.
And they SHOULD be, or it would be a huge security issue.
It’s trivial to make an invisible applet pop up a window identical to, say, an msn messenger login dialog.
The warning icon in u12 is really much better, I can’t imagine that someone would have problems with it.
I suspect that the little warning triangle wouldn’t stop the sorts of people dumb enough to fall for that from entering their ID and password anyway.
Perhaps that warning dialog just needs to be a whole lot friendlier looking - ie. assume applet is friendly.
Cas
maybe java applets are not as wide spread, because you can’t do that
or was that a joke?
if not:
sure, java could do that, but even html could look like msn messenger. what’s the deal?
sun could go and warn people starting their browsers?
for a browser plugin, the sandbox should be anything in memory, a local cache (minimal or based on browser cache) and the web.
exclude system wide file access and other sensible system features and thats it.
essentially that would be about on par with flash (maybe not technically, but from user experience) and flash is also a common resident on your browser.
The other part is… you could still make a signed applet that did that, and people would still click yes on it. Some won’t, but how are you to know whether the app’s actually doing anything unsafe or not?
Cas
Er, the point is that the signed applet acceptance dialog should CLEARLY point out who signed the applet, and the user should be able to trust this (because the certificate is, in turn, signed by a trusted root). If the source of the signature can’t be located, this should also be CLEARLY pointed out to the user.
Then it’s not an issue of “do I trust this random website”, but “do I trust this company”.
Allowing unsigned applets to pop up arbitrary new windows is a massive security issue. Not having the warning about sign origin be clear is also a massive security issue.
I want java to stay something people consider fairly safe to use. If a lot of phishing attempts start using java popups, it’s going to start hitting the news, leading to IT managers removing java from the installations even more than now. And in the long run, it’s going to lead to a lot of bad-will.
Just look at what happened to activex. It was a great technology, but the security wasn’t there.
I think possibly a default setting of “show nothing if it’s properly signed” would be best for the general population, and “show scary dialog” if it’s not properly signed, and “prevent it running at all” if it’s unsigned. At issue is the nature of the trust granted by signed code.
Consider:
Fancy match 3 game applet wants to access filesystem to scour credit card details or somesuch - crim signs it properly - users will click Yes, give me all permissions anyway, in order to get to the content. We can see here fairly clearly that signing has protected no-one: users click Yes when they want to see stuff. That’s why they are happy to download and install things too - they want to see stuff. Unfortunately there’s a proportion of paranoids that won’t click Yes on anything - and doubly unfortunate because they are right to do so.
How can this be solved?
One thing I had thought of is that being signed by Sun would endorse something as safe, and require no verification dialog. We could, f’rexample, get LWJGL signed by Sun and that’d help our applets a lot. Or someone could write a sandbox filesystem implementation that allows free capped access to just a single safe directory effectively giving applets limited but significant safe storage. Etc. I dunno, but it’s the only workable solution I could think of. Either that, or Sun become a CA and perform QA on applets to ensure they’re not doing anything sneaky.
Cas
I also agree that a special golden certificate should be supported which does not show any dialog. This would make things like JavaFX and hardware accelerated applets (e.g. LWJGL, JOGL) a much better experience.
not going to happen…
Not only can api’s like lwjgl go fullscreen - but it would also be impossible for sun to know whether the binaries are safe or not. even with a source drop, they would have to comb through the code and changes every time. snowballs chance in hell.
the thing with certificates is that they can be pulled/banned pretty fast, besides project owners can take responsibility right? like be contractually bound not to do anything wrong (criminal sanction?).
As for fullscreen you could have a system like Flash where pressing escape forces a fullscreen exit.
The question is how can Java be moved on at a satisfactory rate without having to rely on the glacial progress of JDK releases? Why indeed should users trust Sun any more or less than they trust anyone else? Some sort of endorsed extension deployment mechanism is what’s needed here. Perhaps once an extension has been OK’ed once by a user it’s automatically trusted from that point onwards? Perhaps code using extensions that have been OKed shouldn’t bring up a dialog?
Cas
[quote=“princec,post:18,topic:33154”]
Isn’t that the way it works now?
I don’t think so… I think each individual certificate needs to be accepted (and there’s an option for accepting a cert. in perpetuity).
What I was thinking was more along the lines of… Imagine Java as just the core plugin at the centre of an ecosystem of other plugin functionality. Such ecosystem might contain JavaFX, LWJGL, JOGL, JUnity, JFlash (hehe), etc. Rather like when you go to visit a website that requires a plugin you don’t have, you’re prompted about installing it (usually with some degree of hassle) - except in this case, the root of it all is Java, and it’s easy to install as a result. So these plugins are to all intents and purposes to be treated just like their “native” equivalents: that is, a user trusts the plugin, not Java itself, to maintain security. This is already the situation to some extent. What it means is that the onus of trust is on the plugin vendors, not Java, to keep themselves secure. For users, it means accepting a one-time installation of a little extension in their JVM but no further dialogs.
You’d still want to have the standard JDK enforce its standard security wrt. windows and so on as that’s built in to Java through and through. If a user wants to use an applet with an SWT plugin then it’s up to SWT to put up their own warning triangles.
To be honest though it should be down to the operating system to enforce security and sandboxing at this point. Vista does it ok.
It’s kinda like totally cross platform ActiveX with the attendant security worries I suppose, but the added benefits that certain things will become possible without any true security risk. It’s worth pointing out that the sorts of supremely dodgy “screen copying” applet behaviour and “identical to MSN Messenger login” behaviour applets are going to be found only on the sorts of sites where a fool and his money deserve to be parted. No-one with legitimate aim would host such an application.
Cas