Stanley Ho's Blog

Deployment: Goodbye scary security dialog box!

During the post-Tiger planning, we talked to numerous developers to determine what features and enhancements we should work on in Mustang. Many feedbacks we received are related to the user experience in Java Web Start, especially around the security warning dialog box for signed application.

Comments

• I'm very excited about this. I think it will go a long way towards making JWS applications easier on the user.

  Posted by: keithkml on April 30, 2005 at 12:39 AM

• Personally I think "Run" "Don't run" (or Run and Cancel) would be better names for the buttons. For years and years usability people have recommended descriptive button names, and "Continue" and "Cancel" are too generic and meaningless together.

  I also think the phrase "The application security certificate is not valid" is confusing and too wordy. I suggest "The publisher could not be verified" like in Microsoft's IE run dialog.

  Posted by: keithkml on April 30, 2005 at 12:43 AM

• Also, the dialog you get from the "More Information" link should be more user-friendly. A short sentence at the top of the certificates window would go a long way without requiring a lot of work.

  Posted by: keithkml on April 30, 2005 at 12:55 AM

• Also, while you're updating security usability, I suggest changing the status bar for untrusted JWS application windows to say "Untrusted application window" instead of "Java application window"

  Posted by: keithkml on April 30, 2005 at 12:58 AM

• After installed mustang, the old shortcut - javaws on the desktop worked normal. But, the About dialog displays '1.6.0-ea (build 1.6.0-ea-b34)' , isn't the former one, i.e. 1.5.0_02,this information is inconsistent with the 'Target' of the shortcut, which actually locate in directory of 1.5.0_02 [ right click the shorcut | see Target on Shortcut tab]

  Moreover, if you create a shorcut targeted to the installed 1.6.0-ea, when you try to run it , nothing happen.

  
  -----------------------------------------------------------------------------------
  java version "1.6.0-ea"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b34)
  Java HotSpot(TM) Client VM (build 1.6.0-ea-b34, mixed mode, sharing)

  Microsoft Windows 2000 [Version 5.00.2195]
  ------------------------------------------------------------------------------------
  

  Posted by: pprun on April 30, 2005 at 03:00 AM

• I am very concerned about this! A lot of phishing scams on the internet are directed at technically unsophisticated users.

  While it is very pretty, I this dialog does not clearly reflect the risks involved. It only takes a few people getting burned with JWS, to kill this very valuable technology. Microsoft would make sure it's headline news!

  People should not be developing any JWS applications that require signatures, or any special permissions, outside of a corporate environment. Corporations can issue their own security certificates, and make sure they are supported on their own machines, to supress this dialog from even popping up. Given that context, this is an extremely serious warning; I think you are playing with fire, in our collective houses as developers, and those of our users, by toning it down.

  I recommend something a little more truthful, like:

  
  Warning: This application is untrusted!
  Running it will very likely cost you your data, your money, and your job!
  Are you really sure you want to proceed?
  

  Posted by: cajo on April 30, 2005 at 05:35 AM

• At the risk of being pedantic, what is it, really, that you want the dialog box to say? If I ask you this question across a table, I'm betting that the English that you use to tell me what the potential problems are with running this particular application will be clearer than anything that's currently in this dialog box (or its current incarnation). So let's work it through, right here, right now in this comment section. Stanley, as a user, what problem are you interrupting my workflow to tell me about?

  Looking forward to your response, and then we'll go from there.

  Posted by: ljnelson on April 30, 2005 at 07:19 AM

• With Verisign giving out certs to companies named "Click here to continue" or to Microsoft hackers the whole trust hierarchy is broken and ultimately useless. With a little extra work most applications can be written to work properly in the sandbox. Source: http://www.ScheduleWorld.com/itsYourLife.html

  I don't know the policies of cert authorities, but by their actions it's as if the cert sales people are working on commission and will bend or break their own policies to get that cert sale.

  Over the long haul folks will use applications they don't have to trust (unsigned, sandboxed) versus applications that they have to trust. My app uses server and client side digital certificates that I manage myself. While it would be nice to also have those certs signed by a third party I can't find a reputable cert authority I can trust.

  If Sun wants to make the desktop better, please include testing all new features and bug fixes inside the JWS environment. For example, some major screwups that Sun would have avoided are:

  XmlEncode, XmlDecode. That's right, the fundamental Object persistence mechanism shipped with the JDK was released broken wrt unsigned JWS and remained broken for a long time. (It may still be broken as at least one vendor reports their product doesn't work with 1.4 because of this)
  java.util.Logging. That's right, the fundamental Logging mechanism shipped with the JDK is broken and remains broken to this day wrt unsigned JWS

  IMHO there are are other far greater problems with the desktop experience. For example:

  parts/packages (like jardiff). The fundamental ability to build and deploy modular programs was broken for many years and is only just fixed in 1.5.0_02 - no backport to 1.4.x is planned.
  No JWS socket service. The fundamental ability to work together with other services and applications is non-existant. You have to write your own .java.policy manager to enable this (which has to be signed to update the .java.policy file, ARG!!!)

  There are lots of other minor nits, but why bother pointing them out? I stopped keeping a list because it's clear Sun doesn't understand the requirements of the desktop. The more I think about it, the more I wonder if they really care. After all, Sun can say it is working hard on the desktop but if they aren't addressing the fundamental desktop problems then it's hard to believe them.

  It seems that even when Sun 100% agrees in writing that fundamental problems should be fixed it takes them an enormously long time to get to it (take SocketService for example, 4876235). I don't mind waiting a long time for the little things, but it's incredibly frustrating when fundamental problems are not addressed.

  On a positive note, I'm quite pleased to see Sun is trying to tap into the Java developer community by providing a process to accept patches and by providing early access releases of the new JDK - which should help catch major screwups like the ones mentioned above from making it to the public.

  Posted by: markswanson on April 30, 2005 at 07:25 AM

• THANK YOU THANK YOU THANK YOU!!!!!!!!!

  I applogize and will ... try to think of something to help Sun, open to suggestions!

  There are 2 screens! This one shown is for unsigned applciation by an un-authenicated vendor. Users should be discouraged to download.

  The 2nd differenet and important screen is when a vendor does autheticate themselfs by a 3rd party and does sign the jars as him authorizing them as safe and accepting liability. THAT IS THE KEY SCREEN. That should say something: "Would you like to deploy this signed Java application by an Vendor authenticated by ?". (Currently the signed jars screen is scarry !- I have no problem with non signed jars and non-authenticated vendors from being scarry; - above case.). We want to encourage users to deploy java apps; we want to discorage vendors from including own jre w/ app; we want to encourage vendors to authenticate themselfs.
  Also, this one screen should allow some customization on top like Application Icon and Applciation name. This prevents 2 spalsh screens when I start JNLP. Once applciation is approved, the bottom warning message does not display at splash, only top part.
  This String "Would you like to deploy this signed Java application by an Vendor authenticated by ?" - or similar; should be ported to java 1.5, while we wait for 6.0 to be widley deployed by users. It may be harder to change the screen handling, but certanly replacing a text string is easy in 1.5. (That would remove the signed scarry screen for the 1.5.04x). This way vendors can stop shiping own JRE w/ their applications, and we can get deploy Java applciations. It should be just as easy as deploying a a Flash plugin buisness application. Get a newly formated PC, and go to a flash application. See how they deploy. Also, Mike, in user interface of Sun said he would help. Maybe he should come up with the string to use for signed jars by authenticated vendors. Example is when one runs a JDIC applciation, this is Sun code, signed by Sun, and authenticated.
  I too would be glad to help. If you want me to check out source of 1.6 or 1.5 to find those strings. The goals is to level the playing field so WebStart can dominate.
  Again, thanks Stnley. I applogize and promise to try to behave. I was just trying to get attention, and... maybe it help.
  .V
  netsql at roomity.com - in case you want to sync,.

  Posted by: netsql on April 30, 2005 at 07:35 AM

• Well, I just went to the Sun bugdatabase to check out the RFE I mentioned: 4876235. It's reported as fixed! Well, that's just frickin' awesome. The frustration in my little rant above came from a belief that it would likely never happen - but it's here!!! I don't mind eating a bit of humble pie over this at all! Countless numbers of folks are going to lead happier and better lives because of this. :-) WooHoo!
  

  Posted by: markswanson on April 30, 2005 at 07:45 AM

• To cajo: I don't know who you are, or what could possibly have caused you to hold the opinions that you have, but I think you completely disagree with the majority of the world about many things.

  You say "People should not be developing any JWS applications that require signatures, or any special permissions, outside of a corporate environment." Why not? Should no one develop native EXE programs for Windows, or native .app programs for Mac, either? Should everyone just convert to unsigned applets which can't access the hard disk or network?

  I think you were joking when you said "very likely cost you your data, your money, and your job," but you must realize that it's completely untrue. I've run many, many signed but untrusted JWS applications (like JDiskReport, Puzzle Pirates) and none of them have ever cost me any of those three things.

  Posted by: keithkml on April 30, 2005 at 10:38 AM

• I have updated my blog with a few more screenshots. Tell us what you think.

  
  > keithkml:
  The "More Information" link will show a new "More Information" dialog in the upcoming Mustang b36, and it should make the security warning dialog very user-friendly. We will blog about this among other user experience changes when b36 is out.

  
  > netsql:
  Many developers demand a fix in a 5.0 update release; we understand the needs, and we certainly want to get the fix right. One option under our consideration is to backport this new security warning dialog box from Mustang. Of course, this is not an offical commitment yet, and we cannot proceed with this option until we finalize the UI design and implementation in Mustang first. So, help us get the words out! The more feedbacks we receive, the sooner we could finalize the UI design and consider the backporting option.

  
  > markswanson:
  4876235 (SocketService) is fixed in Mustang. However, there will not be a new JNLP API for this fix as the synopsis implies; instead, a security warning dialog box will be triggered when your unsigned code attempts to access the socket without proper permissions. We will blog about this among other Mustang deployment features in the near future, stay tuned.

  
  - Stanley
  

  Posted by: stanleyh on April 30, 2005 at 10:52 AM

• > keithkml:

  Your response clearly puts you in the category of people I am trying to protect. You are right however; in this capacity, unfortunately I have to "disagree with the majority of the world," including you.

  By your admitted actions, it is clear that you do not yet understand that when you click "continue," you are authorising an application to potentially take away your money, your data, and your job.

  You also do not understand that I am on your side!

  Posted by: cajo on April 30, 2005 at 01:13 PM

• cajo we are on the same side because we both want a better user experience for Java application users. However, your use of the words "very likely" implies to me that most people who run a single untrusted application will lose their jobs. I don't think that's true.

  I've been a developer for 8 years and I understand what happens when you run a program. I think most users understand this too, especially when shown the JWS warning dialogs. Windows XP SP2 has made people more aware of this, as well, and I think most Linux users know, so this dialog does not need to display much information.

  You should also keep in mind that if JWS has a scarier warning dialog than Windows, Linux, or Mac web browsers do for downloading native applications, people will avoid using JWS in favor of natively packaged installers, just to make it easier for the user. So, I think the Java development team must keep that in mind.

  Posted by: keithkml on April 30, 2005 at 03:51 PM

• Howdy, just a quick note on the shield icons.

  The difference between the "i" in the first screenshot and the "!" is very subtle. Perhaps you could consider something like a shield with a tick for the first screen, a "?" for the second and a "X" for the third.

  Cheers
  Andrew

  Posted by: pietschy on May 01, 2005 at 06:36 PM

• I would say there are too many words at the top which need to be parsed and are pretty much duplicated next to the shield. How about something short like, "Verified", "Invalid Certificate", "Unknown Source".
  

  Posted by: virtualrob on May 01, 2005 at 07:44 PM

• This is a great step forward. I think there could be a few more improvements:

  
  - Do the messages still make the dialog box look scary to your users?

  
  Nope. But I think they need more explanation.
  The header (in the white) is too big (i.e. too much information for a header) and yet there is still not enough explanation for novice users. I think the header should simply ask "Grant full permissions to signed application?". Then, directly below the header (and above the application's name) should be a simple but complete explanation of what is happening, depending on the situation:

  For a valid, trusted certificate:

  This application is requesting full access to your computer.
  The application has been signed using a security certificate to guarantee the identity of its publisher. The security certificate is valid and was issued by a trusted source.

  
  For an invalid, trusted certificate:

  This application is requesting full access to your computer.
  The application has been signed using a security certificate to guarantee the identity of its publisher. The security certificate was issued by a trusted source, but has expired or is not yet valid.

  
  For an invalid, untrusted certificate:

  This application is requesting full access to your computer.
  The application has been signed using a security certificate in an attempt to guarantee the identity of its publisher, however this certificate was not issued by a trusted source.

  
  I know some of this information is already written in the little box down the bottom, but that box is below the Continue/Cancel buttons and has a really small font, which means no one is ever going to read it!

  
  - Do the messages reveal proper level of security related information?

  No. I think cajo is right in that these new boxes fail to convey the seriousness of what is being requested. Particularly the first box: it is essentially saying that "This Application is Okay", but it doesn't say that you are letting it access every file on your hard drive.

  
  - What improvement do you like to see in the new dialog box?

  As well as those above, I think the following would be improvements:

  I agree with Andrew that the shields are not too meaningful and are too similar. There was probably already a big argument about this in the HCI department, but I think you should be using red for untrusted certificates, not orange. The symbols inside the shields should also be more distinct as he point out (10% of men have a colour vision deficiency, so they only see the symbol, not the colour).
  The shield (or whatever it becomes) should be in the top-right, aligned to the right of my proposed descriptions above, not at the bottom-left where it can be ignored.
  The use of "Name:" as a label for the application's name is ambiguous. I think the label should instead be "Application:"
  "Always trust content ..." should not be selected by default at any time. This should be a decision that the user makes conciously.
  I would also like to see an "Always trust this application" option. I think that, just because the user wants to trust the publisher for this application doesn't mean they ALWAYS want to trust applications from that publisher. However, I think this and the existing checkbox might be better placed if hidden in a "More Options..." section.
  I also agree that 'Run' is a better button label than 'Continue', though this doesn't fit with the question I proposed for the header.

  
  Once again, this is great work and thanks for getting it underway. It is definitely more user-friendly, but I think it's very important to have the consequences be more clearly stated.

  Graham.

  Posted by: grlea on May 01, 2005 at 08:16 PM

• Another thing, "has expired or is not yet valid."???? Computers have had less-than and greater-than operators for decades, and the computer doesn't even know if the signature date was in the past or the future?? We can do better than this.

  Posted by: keithkml on May 01, 2005 at 10:32 PM

• Personally, I still think that non valid (according to certpath credential) certification should be put as a red sign !

  To overcome this red sign, devlelopper will have to enter in declarative mode.
  Going to declarative mode means that before the application is launched you are asking the SecurityManager some credentials you wish they could provide you.

  This means, that at the time of the warning screen you could have the full list of permission used by the application.
  With those information you might be able to give extra advice to the users on the exact risks and impact of executing this code.

  Once the user will agree, then the application will be granted ONLY the permission it has applied for. When meeting any non-prerequested Permission, this would result in a SecurityException !

  Such mechanism will not have impact on the J2SE security, as the maximum permissions you can get is the same as the one defined for the security level chose (and for the context you are running into).

  The only difference is that, you will push more information to the user for him to make his choice, and you can make sure the application is not trying to fool you.

  This techniques will mean that for an RiA than need to connect to several datasource website, but does need any local file usage, the user will be able to give only these rights, and not enable acess to the local files.

  Any thoughts ?

  Posted by: bjb on May 02, 2005 at 05:04 AM

• Looks nice, much better than old one. However, one bug, or annoyance; on Linux (I don't have Windows box handy), when app is already downloaded and then started again (starting fast, without a need for download), splash screen shows and stays for a very long time, floating over new Security Dialog Box, thus blocking the view.

  Posted by: selendic1 on May 02, 2005 at 06:53 AM

• Downloading and running software outside of sandboxes is a really dangerous thing to do, irrespective of signatures. I do not believe the dialogs inform of the risks.
  

  Posted by: tackline on May 02, 2005 at 10:51 AM

• I like the screenshots. To those of you still whining that the new dialogs do not make say something like this:

  Warning: This application is untrusted!
  Running it will very likely cost you your data, your money, and your job!
  Are you really sure you want to proceed?

  ... give me a break! That is the very thing we're trying to avoid going back to. If Java's dialogs are any scarier than the native warning dialogs, no one will use the applications. The new dialogs are far more consistent with the native dialogs. Good job Sun!

  Posted by: cowwoc on May 02, 2005 at 11:06 AM

• This is a very irresponsible move.

  End-users should never accept a certificate dialog. 99.44% of end users have no way of understanding what this dialog means.

  JWS started out doing this right. In an intranet, security certificates can be installed by system administrators so that they are transparent to the user. On the open internet, the sandbox has been relaxed slightly with the JWS API (FileService,
  PrintService, etc.)

  Using these APIs, an app can be implemented to be safe and useful in the sandbox. See for example http://horstmann.com/violet.

  Why do so few apps use these services? Because the APIs are painful, and the implementations are buggy.

  Here is what Sun should do:

  1) Put the JWS API inside Mustang so that it is easier for developers to access
  2) Fix the idiotic file save mechanism so that the library--and not the poor application programmer--buffers the output
  3) In general, make the API so that a JWS application can be produced with a minimum amount of additional engineering
  4) Provide a programmatic way of detecting JWS!!!
  5) Gracefully deal with security issues, e.g. in the JFileChooser dialog
  6) Be serious about fixing security-related bugs such as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4741757

  This can be done, folks. The alternative--to endanger end-users because you are too lazy to do the heavy lifting--is something that we all know from Microsoft, and they do not have a good long-term success with that strategy.
  

  Posted by: cayhorstmann on May 02, 2005 at 12:26 PM

• A correct behavior would be to offer an additional button for applictions signed with invalid certificates to run the application but force it to run constrained in the sandbox.

  Posted by: peterenglish on May 02, 2005 at 01:35 PM

• Still useless.
  I tried to deploy an application with JWS without a "trusted" certificate - resulting in that scary dialog. Even my friends (who helped testing and by definition trust me) didn't continue when they got the warning!
  "...trust the origin of the application..." would not do it. With the low level of knowledge of most users noone would dare to trust the origin of the application. What is the origin? Is it me? Is it Sun? Or is it someone else that my customers or friends don't know?

  Now I just put an executable jar-file on the website to download, it runs without restrictions, and everyone is happy.... Great - but what is the point in having JWS then? The idea is really good - I would love to be able to use it.

  Posted by: bentzn on May 02, 2005 at 01:54 PM

• I realy think that people that say that said it should still be scarry are not sincere. People that test it on end users are sincere, and .... it still sacares users even when it's signed. Can we change words more? Can we fix it in 1.5? Can Mike in UI look at it?
  .V
  

  Posted by: netsql on May 02, 2005 at 02:47 PM

• bentzn: There are two distinct use cases for JWS.

  1) Run internet applications in a better sandbox than applets (in a frame, limited ability to save and print)

  2) Run intranet applications with pre-installed certificicates

  Using JWS (or any other technology such as ActiveX) to run code from the open internet is dangerous. Your friends know in their gut how dangerous it is, so they won't click through the dialog. Making the dialog friendlier doesn't change the danger.

  Learn how to use the JWS API and make two versions for your app: one safe trial version and one full-featured version for local installation. Beat on Sun to make this process less painful.
  

  Posted by: cayhorstmann on May 02, 2005 at 03:02 PM

• cayhorstmann: How can it be more dangerous than simply downloading an executable jar-file (or any exe-file) and run it from the desktop? If my customers are willing to trust me enough to do that, they ought to be willing to trust me using JWS too. To me it's just a question of convenience because JWS has some really great functions to update the software. (Obviously I haven't really tried it out yet).

  Posted by: bentzn on May 02, 2005 at 03:32 PM

• cayhorstmann: Your two use cases do not apply to me, nor to almost all of the JWS programs I use. JWS provides a powerful cross-platform versioning, compression, auto-updating deployment system, and limiting it to just sandboxes or intranets is unnecessary and, anyway, does not match what most programs I use and develop want.

  Posted by: keithkml on May 02, 2005 at 05:40 PM

• One more comment (I had to sleep on it): As far as I can see, JWS has the potential to blast .NET out of the sky - even before it takes off. -But it never gets there, because "we want to protect the user by scaring him away from getting the convenience of just click-and-run". How about a demo-CD with some app on it? -or a downloaded driver from a thirdparty? Should the computer not warn it's user that _any_ code is potentially very dangerous? -expect a revision of the Windows-startup-image... :-)

  Posted by: bentzn on May 03, 2005 at 12:19 AM

• I'd agree the shields are way too similar - especially if you're red green colour blind. If you want them to convey meaning, make them very different.

  Posted by: pete_kirkham on May 03, 2005 at 02:02 AM

• It's a catch 22 situation: the more responsible/honest you are, the more needlessly frightened your average end-user will get. Ironic, but true! Your average end-user has no real understanding of computer security - witness how many of them 'post-it' their password to their computer monitor. They are quite happy to install countless native applications simply because they don't think about the risk, and the install process doesn't mention any possibility of risk. But as soon as an installer is responsible, and draws the risk to their attention, they panic. (It's a bit like eating fast food - if you actually knew what got ground up and put in your burger you wouldn't eat it. Ignorance is bliss!)

  Phrases like "this application wants full access to your computer" frighten people. "FULL ACCESS??? WHY DOES IT NEED FULL ACCESS???" (Best when said in Homer Simpson voice.) The fact that pretty much every other application they've installed also has full access totally escapes them.

  I suggest a 180 - let's come at the problem from a totally different angle, by championing the virtues of Java while also couching things in a way which the end-user can relate to. How about something akin to...

  Java has the ability to control the way Java applications access your computer, which has many _security benefits_. This software, however, wishes to be granted the _same priviledges_ as the other non-Java applications installed on your computer. It is recommended you do not run software with such permissions (Java or otherwise) unless you _trust_ the authors.

  The underscores delimit hyperlinks which open a window with more details.

  Posted by: javakiddy on May 03, 2005 at 02:53 AM

• javakiddy: Good remarks. I agree. Only I would like to completely remove any warning other than "You are about to download and run an executable file from foobar.com. Do you want to continue?".
  If the doctor tells the young mother that there is some risk of a certain vaccine that the child will get meningitis and maybe even die, he will never be allowed to perform the injection. Several vaccines actually has that risk! -but they protect kids from getting don't-remember-the-name - so the bottomline is: it's an advantage to get the vaccine.
  
  (It's only on cigarette-packages that "This will kill you" doesn't work :-)

  Posted by: bentzn on May 03, 2005 at 08:55 AM

• This dialog is as useless as the IE Explorer dialogs for the same reason. TRUST IS A STUPID CONCEPT. Who cares that some sales-droid at Verisign has cashed the check from spammers-r-us.ru ?

  
  JWS and Java's strength is its ability to protect against code that is assumed to be suspect. Leverage the fact that unlike .NET the user is does not have to trust anyone.
  Properly done people should prefer to run Java apps rather than .NET apps. But this will only happen if Sun plays up Java's sandbox's ability to protect users from an application's bugs, a corporation's greed, or a trojan attack. All the problems with spyware, trojan horses, etc. could be stopped with java and a proper sandbox that my Mom could construct.

  The dialog being discussed should make the announcement about what is being run, yes. But as it stands I wouldn't click yes for my own application!

  Rather than just giving the user a chance to make one of two uninformed choices . Tell them the consequences of his actions, and I don't mean the boilerplate of "You could die!"
  I mean a dialog that can let the user make a meaningful, informed decision.

  Example:

  "This application, 'Peter's CoolApp", is asking to run. If you allow 'Peter's CoolApp" to run, it has asked for permission to do these actions. Select the actions that you feel comfortable allowing 'Peter's CoolApp" to do:

  
  [x] Write up to 1mb to c:\tmp\jws\scratch\'Peter's CoolApp" (This is a low risk activity) [Link to how this could be abused] [Browse...to select a different directory)]

  [ ] Modify the entry [\\Computer\...\'Peter's CoolApp"] (This is a mediium risk activity) [Link to how this could be abused]

  [ ] Write toC:\WINNT (This is a high risk activity) [Link to how this could be abused]

  [ ] Send information to http://spamers-r-us.ru (This is a high risk activity) [Link to how this could be abused]

  Additional Security:

  [x] Automatically log all actions that "Peter's CoolApp" performs

  [x] Automatically log any information that "Peter's CoolApp" sends back to http://spamers-r-us.ru

  [x] Automatically review any information that "Peter's CoolApp" attempts to send back to http://spamers-r-us.ru

  
  The buttons would then be : "Run 'Peter's CoolApp" with selected permissions" or "Don't Run 'Peter's CoolApp"

  The low risk activities maybe be automatically selected and the medium/high risk would be automatically unselected.
  It is the application's job to deal with life in the sandbox the end-user has constructed for it. But now the application gets a chance to run in at least some manner and the user doesn't have to 'trust' anything.
  

  Posted by: patmoore on May 03, 2005 at 12:57 PM

• "You are about to download and run an executable file from foobar.com. Do you want to continue?". -- that was a good suggestion.

  there are 2 cases, one: software vendor did not compleately reigtster and just used a temp trial or self signed even. In this case, it should be a strongest warning! just like beta sofware.
  case 2, they did full level authethication as vendor and signed all the jars w/ a comercial high level cert. in this case, have NO WARNING, just a small text on their custom splash screen like this: "authenthicated vendor foobar.com by thawarte" . Going beyond ceomercial autorization used for email and https for bank transaction's is iresponsible. so I say, no screen for certified vendors.
  also, I think there are fake posters here, that are arguing aginst deployment that are no delpoying swing.
  in any case, end user testing of the 2 cases should validate. the programmers opinions does not matter. We need more swing apps shipping so help us.
  the wordsimthing fix " "You are about to download and run an executable file from foobar.com. Do you want to continue?" can be easily applied to 1.5, do you want me to make the diifs?
  .V

  Posted by: netsql on May 03, 2005 at 01:36 PM

• So netsql, if I pay Thawte and get myself a certificate, I'm allowed to run any code I want on your computer, immediately without a single prompt? How does this work? Do we all automatically trust people who have $200, to have their way with our computers without asking us?

  Posted by: keithkml on May 03, 2005 at 08:25 PM

• Here's a few points I hope we all agree on...

  * Words like 'trust' and 'authenticate' are not understood by end-users, at least not in the computer security sense.
  * End users do not consider installing new software to be a security risk. If anything, they worry more about it changing desktop settings or stopping other software from running than opening up a spam relay or emailing their credit card details to an unknown source.
  * Because of the above, any discussion of security (even a responsible one) is likely to panic them. Ignorance is bliss. Knowledge makes them nervous (as they generally don't read the details - see next point).
  * Long involved texts will not be read by the end-user - even if they involve form elements such as checkboxes to enable various permissions.
  * Not providing some form of a security dialog for JWS applications which are required to go 'beyond the sandbox' is irresponsible.

  This presents us with an interesting dilema. Other software effectively trades on the ignorance of the end-user. They barely mention trust or security, and as such the end-user assumes they are safe. The more open JWS is about security, ironically, the more the user thinks about it, and the less likely they are to install a JWS application.

  To take a step back from the immediate argument - I wish Sun would have spent more time promoting Java's security benefits in the past. Back when Java first appeared I knew of sys admins who would disable Java on their network's installed browsers ("nasty security risk") but keep ActiveX switched on. If they are confused, God help the poor end-user. The ability of JWS to be honest and frank about security would be greatly helped if the end-punter instinctively associated words like 'secure' and 'sandbox' with the Java brand. (I don't believe it is beyond the witt of most end-users to understand the concept of a sandbox, so long as someone takes a few moments to explain it!)

  Posted by: javakiddy on May 04, 2005 at 02:32 AM

• I agree with the JavaKiddy.
  netsql: As keithkml I think it's a bit dangerous to believe that a vendor with a valid certificate of any kind should be considered trustworthy.
  The sandbox-concept is very good - only I can't use it, because my apps need full access to resources.
  Why not just - amongst ourselves - be happy with using a good, safe and secure language for making great software and let our apps have the same premises as any other apps when deploying. I don't need to tell my customers that my software is safe because I use a particular language - I expect them to trust me as a supplier. If they didn't, they wouldn't do business with me in the first place.
  Again: I strongly recommend only using that "You are about to...."-warning. That would really get us going. I personally would start deploying all apps with JWS if it went that way. As it works now it will never happen.

  Posted by: bentzn on May 04, 2005 at 04:04 AM

• bentzn: "I expect [my customers] to trust me as a supplier. If they didn't, they wouldn't do business with me in the first place."

  Maybe they just don't have a choice? How many people are forced to "trust" Microsoft to produce secure software. Due to bugs, sloppy practices, it has turned out that that trust was misplaced. How do they know their trust in you is not also misplaced? Why are you demanding that they trust you completely with the contents of their hard drive? If you were to knock on your customers' doors and ask for the entire contents of their hard drive in person, would they 'trust' you enough to give it to you? But that is what you and every other company distributing software for Windows does right now.

  Rather than focus on authentication, focus on authorization. What permissions, what authorization as a developer do I need to ask for from my customers? As a developer am I asking for permission to do things that if my customers knew about they would be concerned?
  Think about when the spyware issue started blowing up. Intuit was forced to change the way they enforced the license to TurboTax. Gator, et.al. started getting the bad rap that they did. People like my mother, and babysitter are asking me about security issues. My simple answer is: "Use Firefox, and never download anything from the internet."
  Java's sandbox, properly explained, is a way for users to know that once again it is safe to download from the internet. As it stands right now people, even computer ignorant people, are learning the absolute mantra of "Never download and install from the internet".

  JWS's dialog should properly reflect that. Think about this dialog:

  Good news, 'Peter's CoolApp' can run in such a way that it can not be spyware. This is being enforced by Java. Go ahead and have fun playing this game on company time."
  Java, making it save to play on the internet, once more
  [Run] [Don't run]

  Or:

  "Peter's CoolApp" can run in Safe Mode, bu it is asking for permission to save some information to the hard drive in a location that is not being used by any other program. [Link to more detail] [Link to reason "Peter's CoolApp" claims to need this permission for]
  Java, making it save to play on the internet, once more
  [Run with full permissions] [Run with selected permsssions] [Don't run]

  
  Java's security model should be a marketing plus and JWS should help deliver that plus. Think about it as some thing that could be bragged about by the smaller , less well known companies or individual developers:
  I have this cool new Kazaa replacement. But unlike Kazaa you don't have to worry about spyware in it. Java will enforce that this program cannot install spyware programs. Click here to run it!
  

  Posted by: patmoore on May 04, 2005 at 07:50 AM

• Let us respect the final user! These messages about certificates are non-informative for user and do not explain him the problem of security. I'm sure that 90% of internet users don't know anything about certificates and verifying. The message must be oriented to security than a sertificate and may be something like this:

  The application published by attempts to run untrusted code on your computer. Digital signature was veryfied and is valid. If You trust press "Continue".

  The application published by attempts to run untrusted code on your computer wich has no valid security sertificate. This may cause harmful effect on your computer. If You understand what you are doing and sure that You want to run this code press "Continue".
  

  Posted by: nullpointer on May 04, 2005 at 08:26 AM

• patmoore, I like your idea of explicitly referencing spyware and viruses. I think your example text needs reworking, but I think you might be on to something. Many users don't know what security or trust are, but they certainly know what viruses are.

  Posted by: keithkml on May 04, 2005 at 10:35 AM

• patmoore: Believe me, my customers do have a choice... :-) Furthermore: Despite all terrible stories about the shortcomings of MS Windows, none of my users have even considered using anything else. For the sake of clarity I shall be glad to repeat: none!

  
  I think that as the user has chosen to use an OS (secure or insecure of his choice) and he has chosen to use my software by clicking the link on my website, then I will not ask him "What you're doing right now could be pretty stupid... Are you sure you want to do it?" - and I will not use any technology that asks him that question! - Users don't like to be insulted when they are paying for it too.

  As soon as you start explaining about the wonders of something, the enduser will start asking himself why you are doing excactly that.

  Many of my customers don't have any idea of what a "certificate" is. They don't have a clue who VeriSign or Thawte is. It is of no value to them! "It ought to", I hear you say... -Yes, but in real life it doesn't - at least in my real life with my real customers.

  
  I suggest two versions of dialog-boxes:

  1) Valid certificate, checked by VeriSign, Thawte or any other CA

  "You are about to download and run an executable file from foobar.com. The file has a security-certificate that is valid and issued by XXX.

  Do you want to continue?"

  2) Invalid or no certificate

  "You are about to download and run an executable file from foobar.com.

  Do you want to continue?"

  The first is for users and developers who want the extra security by using a valid certificate (I would consider that too in some cases), the second is for plain and ordinary file-download-and-run.

  The user will obviously not continue if he does not trust foobar.com, you don't have to ask him explicitly. Let the user decide if he wants to trust spammers-r-us.ru. That is not up to us.

  
  Another problem of promoting the security too much is that you have to be reeeally sure that it actually is safe - and stays safe.

  Posted by: bentzn on May 04, 2005 at 12:09 PM

• Great discussion, why not talk about this in 2001? anywho:
  "Why not just - amongst ourselves - be happy with using a good, safe and secure language for making great software ?" - I use software profesionaly to make money for my organization. If we use it amogst ourslefs, then it's a hobby. So we can't limit the audience.
  "discussion of security (even a responsible one) is likely to panic them. Ignorance is bliss" - GREAT point.
  "if I pay Thawte and get myself a certificate, I'm allowed to run any code I want on your computer, immediately without a single prompt?" - yes, becuase there is libality in law. If I damage your computer, and Thawte or someone ids me, they know who did it. If Thawte can't id me, then they are resposible. So certified/signed... no screen, ignorance is bliss. What does Flash run time instaliation of the plugin do? Ignorance! Go to MM site and run their business applications, flash or flex.
  "You are about to download and run an executable file from foobar.com. Do you want to continue?" - thats's good for self signed.
  1.5?!
  .V

  Posted by: netsql on May 04, 2005 at 12:42 PM

• netsql: With "amongst ourselves" I meant "be happy amongst ourselves"... I don't believe in trying to convince the user that the alternative we are using is the best and safest ever. Boy, can it backfire....

  
  Liability.... It doesn't have to damage the computer to be harmful. Microsoft has something in the Windows' EULA about "data gathered by support-functions can be used by Microsoft and their partners to improve their products" - that gives a carte blanche to use anything from that computer - and it was the reason why I started to use Linux for SW-development.

  I don't expect to be able to drag MS to court if - by some miracle - I find out that they have used my code or looked into my usepattern of webpages on my computer. Has any of the spyware-makers ever been held responsible for invading peoples privacy?

  
  And: Maybe we can be sure that blackhats.ru are responsible of stealing the creditcard-database - we know excactly which P.O.-box they use in downtown Tibirsk, but how do we really get to them when the damage is done?

  
  I'm glad you agree on "You are about to download and run an executable file from foobar.com. Do you want to continue?" - that would be really great to have.

  Posted by: bentzn on May 04, 2005 at 01:14 PM

• Following this discussion over the last few days, my opinion has been shifted a bit to the more conservative side.

  I don't think we'd be having this discussion if:

  the JNLP API was better
  the JNLP APIs was more comprehensive (i.e. more services)
  the JNLP API was included in J2SE
  the security of Java was being given the hard sell (by everyone, led by Sun)

  
  Explanation:

  the JNLP API was better: the APIs aren't very straightforward and are much different to how a task would normally be done. For example, the the FileOpenService returns a FileContents object. It would be much more intuitive (to program against) if it just returned a File and changed the underlying security manager to allow reading of that file. It's just crazy to add a whole new API for doing tasks that people have been doing in a standard way for 10 years.
  the JNLP APIs was more comprehensive (i.e. more services): there are so many things you can't do with JNLP because the number of Services is ridiculously small. Full-screen mode, accessing Preferences, accessing a web resource other than on the codebase server, having a dedicated directory on disk that can contain anything (different to PersistenceService's "cached files" paradigm). Much of the reason so many people have to deploy signed applications is because the things they want to do just aren't possible through JNLP.
  the JNLP API was included in J2SE: currently, if you want your app to run in WebStart and from a normal jar, you have to write two different versions of it. If the JNLP API was available in J2SE and just worked (without asking the user questions), it would significantly lower the barrier to actually using the JNLP API.
  the security of Java was being given the hard sell (by everyone, led by Sun)

  
  That last one is the crucial point which I have picked up in the last few days: the security capabilities of Java are AWESOME.
  Microsoft is really flogging security at the moment, as are a lot of companies, but most of them are crap at it. If you download spyware and try to run it in Windows, it will say "Do you want to run it?" and you say "Yes". This isn't security - this is a disclaimer: "You clicked Yes. Don't blame us." Java could do this too, but that would make it crap.
  There is a chance with the above dialog to raise user awareness of security beyond the level of "Do you want to take your life into your own hands?" I think it would be great if the dialog could be made to be simple, but still inform people about security. By 'inform' I mean explain security simply and succintly, but to the point where they realise that *unsigned* WebStart applications are safe and EXEs are not and start to prefer WebStart applications and shun EXEs.

  I have come to agree that WebStart applications should not need to be signed to be functional. People should be developing full-featured applications in the sandbox and letting WebStart handle the security rather than using the sledgehammer code-signing method. However, and unfortunately, this isn't currently possible because of the misgivings of JNLP. If it can be improved, I think we can move toward a software platform that is better for the user and the developer, and without having a dialog that translates "Would you like this application to delete all the files on your computer?" into "Would you like to run this application?"

  Graham.

  Posted by: grlea on May 04, 2005 at 06:04 PM

• "I'm glad you agree on "You are about to download and run an executable file from foobar.com. Do you want to continue?" - that would be really great to have."
  -
  That would be for unsiged apps and 1.5.
  Reducing phishing is what certs should do, if they don't reduce deployment of swing aps. It should be just as easy as flash runtime!!!!! If Thware or versign authethicate a .ru site, then they are libale under uniform comercial act. If it's authehticated, stop there! Why do we need to make windows more secure for microsoft? For authehticated/sigend app, just one splash screen that I write to be async w/ message that I have been autenthiced and by whom. If Versign autehitcates and then I damge your comany... we as progrmaeers did due diligence. So if the trade of is deploy vs prevent deployment, then we make treade ofs.
  We all agree that unsigned or temo, or self signed should be a warrning! But commercail developers should be able to have a different path. Ex: https://bloged.dev.java.net/beta/BlogEd.jnlp
  did you ever certify and authethicate? it takes beeing notorized, proof of address, prooof of id, etc. So as long as we know whom wrote the "virus", end of story. It should be just like MM did w/ Flash runtime for flex.
  Compare http://coenraets.com/index.jsp under live samples vs the JNLP above. Better yet, have and end user comapre.

  .V

  Posted by: netsql on May 04, 2005 at 06:26 PM

• netsql, your idea of automatically trusting signed-by-trusted-CA applications is absurd. Let's say I pay thawte and they verify my identity and address and everything, and I get a certificate. Now I write a program that sends e-mail to everyone in your address book saying some embarrassing or insulting thing I made up. Now, you think users shouldn't be prompted to run my application? It should just run automatically?

  Posted by: keithkml on May 04, 2005 at 09:25 PM

• Only one suggestion based on the current behavior of JavaWebStart : If I do not want to TRUST a foreign application (either because it is not correctly signed or just because I don't), it does not mean that I don't want to RUN the application (in the sandbox, of course).

  I really think that it's a pain I have to give all rights or none to a Java app when we all know how the Java security system is nice. Anf if you want to allow only restricted access, you have no choice other than "manually" editing some .java.security file...

  So my suggestion : add a button like "Run but don't trust" and execute the code in a sandbox and, why not, dynamically ask the user, when the application wants to perform some priviledged action, if the user wants to allow or reject the action and, why not, if he/she wants it permanently (then update .java.policy or alike) or just once.

  Posted by: pgrange on May 04, 2005 at 11:20 PM

• Some folks have argued, "Let's not tell the end user we are asking for all permissions - or let's not use scarry words.". Heh, your competitor (who is running his app in the sandbox) is going to be sending out weekly press releases about how your software has the capability to be spyware, install viruses, and potentially do anything it wants to your machine while his app is in the sandbox and can't do any of those things.

  Who wants to bet the future of their company by building their app outside the sandbox and giving their sandboxed competitors an incredible marketing advantage? The pointed jabs you could make are endless and consumers would totally get it. F.E.

  On one hand you have the potential for the total destruction of your machine and the theft of all of your intellectual property. On the other hand you have our product - which is completely safe.

  Given equivalent features, how long is the non-sandboxed application going to be profitable?

  Some work is being done on JWS. The SocketService is available in newer Mustang builds. Let's encourage Sun to do better so we can run with the sandboxed advantage. What would really help me today:

  A "jwsCache/" directory in the user's home directory that I can (metered) read and write to. The current hidden directory structure is impossible to direct users to. If I want to run a file sharing program in the sandbox where am I going to put the files? We need a better place.
  If I ask to read a file, don't tell the user I'm asking for read _and write_ access. That's scarry, and uneccessary.
  Document that XmlDecoder and XmlEncoder are broken and should never be used - work with XStream and other solutions

  Cheers.
  

  Posted by: markswanson on May 05, 2005 at 06:37 AM

• pgrange, I really don't think the "Run this signed app in the sandbox" option will work. Firstly, I reckon the number of calls to the security subystem is probably a lot more than we realise, and users may find they are spending more time clicking "Yes, the application can read a system property" than they do actually using the application itself. Secondly, what happens when the user clicks No? Obviously, a SecurityException (a RuntimeException) will be thrown, but how should the application respond? To prevent my WebStart appliction from crashing, I'll now have to put a try/catch around every call that could potentially result in a SecurityException and then do something sensible in that situation, which would be hard if the exception occurs in the middle of an important action.

  It's a good idea, but I just think it's impractical.
  An idea in a similar vein, but probably more useful in practice, would be if we could make more fine-grained security requests, so instead of having:

  <all-permissions>

  we could have

  <read-files/>
  <read-system-properties/>

  But, as I wrote yesterday, I've decided that signing applications and trying to get permissions is the wrong way to go and the sandbox is a great idea that needs to be completed.

  
  Graham.

  Posted by: grlea on May 05, 2005 at 05:50 PM

• markswanson: I'm looking forward to seeing that happen with Windows/Linux. If you're right, I don't understand why the endusers haven't changed to Linux yet.

  Posted by: bentzn on May 05, 2005 at 11:32 PM

• I agree with comments on including the JNLP API into the JRE, and I'd rather develop an application in a sandboxed environment than a signed/all-permissions one.

  To overcome the limitations of JNLP services, I can suggest one thing :

  why not create a single JNLP extension (hosted as a project on java.net and signed by Sun itself with a trusted certificate). This extension would contain other JNLP like services (local disk cache, full screen mode, socket service...) and would be used by every JWS application requiring such services.

  As an extension can be shared by multiple applications, once the user has trusted the extension, it will not be security-prompted with that again for the next run or the next application, and the application will not have to request the evil <all-permissions> (only the extension will be trusted)

  We could work on this project for i18n of warning dialogs ("This application requires a display in full screen, do you agree ?") but the core security part would be let to a sun (or other trusted) security expert (with public review of the source code for approval of the community).

  I think this is the fastest way to overcome the limitations on current JNLP services (with the important side effect of working also on java 1.4).

  What do you think ?

  Lilian Chamontin (vlsolutions).

  Posted by: lilianc on May 06, 2005 at 01:26 AM

• I think this discussion is getting entangled in a lot of "Let's make something fancy about permissions, special sandboxes, special resources for JWS, more technical stuff, letting the user edit a policy-file" and so on.

  
  Please remember that my (and most other's) alternative is to put an executable jar-file out for manual download - and that is what is going to happen if it is too difficult or too bothersome to use JWS. -For example if I have to make two completely different apps, one for ordinary download and one for JWS.

  The result would be apps running with all permissions and no convenience of auto-deployment, and that is not the overall goal I believe.

  
  I myself have very few users and very few apps compared to many others - it can't be a threat to anyone that I have this attitude, but I don't think I'm the only one.

  
  Just a wild thought: Why not make _all_ java-apps run in a sandbox as default?

  
  "Put the roads where people wants to go! At least don't expect them to go anywhere else."

  
  Thomas Bentsen
  
  CEO / owner
  
  bentzn.com
  

  Posted by: bentzn on May 06, 2005 at 02:25 AM

• Yesterday there was 42 comments. I wonder which ones Sun deleted?
  .V

  Posted by: netsql on May 06, 2005 at 10:51 AM

• Again, 32 messages are deleted! And my message saying that they were deleted. There was some other suspicios posts here IMO.
  .V

  Posted by: netsql on May 07, 2005 at 05:05 PM

• netsql, I see 55 comments, including comment #54 which was you saying that there were 42 comments.

  Posted by: keithkml on May 07, 2005 at 07:16 PM

• I haven't noticed any deleted posts either...

  Posted by: bentzn on May 08, 2005 at 02:33 AM

• There appears to be an anomaly such that this document has two URLs, which is why it may appear comments have been deleted.

  The original URL only contains 10 comments:
  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good.html

  Whereas this URL contains 58 comments:
  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html

  Posted by: grlea on May 09, 2005 at 07:35 PM

• There appears to be an anomaly such that this document has two URLs, which is why it may appear comments have been deleted.

  The original URL only contains 10 comments:
  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good.html

  Whereas this URL contains 58 comments:
  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html

  Posted by: grlea on May 09, 2005 at 07:36 PM

• I'm offended that most of the comments here were deleted. This is a community website. The thoughts and ideas of the Java community should not be silently censored. If you are going to backhand the community for caring about Java enough to voice their opinions then what's the point of belonging to this community?

  The full comment page seems to be on the following link. It may be safe to assume the contents of this page have been silently edited as well:

  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html
  

  Posted by: markswanson on May 10, 2005 at 12:02 PM

• OK, I posted that comment to the page that had all of the comments deleted and it wound up here.
  

  Posted by: markswanson on May 10, 2005 at 12:16 PM

• The confusion here was probably caused by an update of the blog that I made. When the original blog (deployment_good.html) had around 10 comments, I updated the blog with new graphics and apparently the tool generated a new page (deployment_good_1.html) instead of simply replacing the old one. Thus, if you happened to have bookmarked the old blog, you will continue to see only 10 comments there. However, all the new comments posted are added to the new blog, so if you go to the updated blog, you will find all the comments there.

  - Stanley

  Posted by: stanleyh on May 10, 2005 at 12:29 PM

• No comment has been deleted. Rather, the original page (deployment_good.html) has became staled, and all new comments are added to the updated page ( deployment_good_1.html) instead.

  - Stanley

  Posted by: stanleyh on May 10, 2005 at 12:32 PM

• Heh. That makes perfect sense. I appreciate the clarification. It would be great if the process also included adding a link to the other page(s).
  

  Posted by: markswanson on May 10, 2005 at 01:52 PM

• sign a jar steps pdf

  Some of you said it's easy to authenticate and certify a jar. It's not. Read the pdf steps and the proof you have to do just to get a valid cert. Some of you that say it's easy have never gotten a valid cert, and signed the jar, else show me your url
  So in light of that, valid signed certs should not have any splash additional splash screen, just a small message on regular splash saying that it was authetnicated and certified
  If it's invalid or temp cert, then a big warning. Else, just avoid it. What exactley is the down side?
  Lets say I do write mal-ware and sign a jar. (it has to come from my domain, else it's invalid cert. That part works already). It's well known who damaged the computer! That is worst case.
  Best case: A developer gets to deploy a java appplication widley. We no longer have to include a jre. Java deployment is as easy as flash (do you want link to sample flex apps? - that is what users expects).

  lets not punish the inocent

  I could get in a car and hit a pedestrian. But I am still allowed to get in the car and drive if I have car called "Flex". If I have Java, I have to only drive on a highway at 15 miles per hour after completing a check list. Who would want to drive?

  .V

  
  

  Posted by: netsql on May 10, 2005 at 04:21 PM

• more current bugs while we talk about new features
  I get pesimistic when I look at dates:
  faq

  .V
  

  Posted by: netsql on May 10, 2005 at 04:27 PM

• netsql:
  You are synonymising authentication with trust. Authentication is what a certificate proves to a user: this person says they are Joe Blogs and some company has gone to reasonable lengths to make certain that they actually are. Trust is giving someone permission to do something which you wouldn't let just anyone do.

  Now, just because someone is authenticated doesn't mean I trust them. Just because some company has confirmed that they are who they say they are doesn't mean I am going to let them do things that I won't let just anyone do. Why? Because they're still a stranger!

  To draw an analogy: If somebody I don't know turns up at my house, asks to come in and shows me his passport, am I going to let him in? No way! Even though I can confirm that he is who he says he is, I still don't trust him, and I certainly won't trust him just because he can prove who he is. Your recommendation seems to be that I should let him in and I shouldn't worry, because if he steals anything I know who he is. But I'd rather just not have anything stolen to begin with.

  I don't think people want to be given enough information to track down the distributor of some mal-ware that stole their credit card details and then deleted their hard drive so they can bring a class action against them. I think they'd prefer to be able say "No, I don't want to trust Joe Blogs."

  I hope we'll come to the point where developers who can't be bothered to write their application inside the sandbox suffer the consequence of having no users because no one trusts their application. This is the way it should be. I don't mean this in a malicious way, but this is what would be best for users (IMO). The lack of features available from within the sandbox is what's preventing us from being there now.

  Graham.

  Posted by: grlea on May 10, 2005 at 06:06 PM

• Grahm said: " I don't know turns up at my house, asks to come in and shows me his passport, am I going to let him in? "

  If the applciation shows up at your computer, it should block, of course.

  But what if you invited him to come? My applications don't show up at your computer. You have to go to my web site, I have to sell you to click, download and install. If it says I am autheniticated, it should be no wraning, it should say "This application is safe and authenticated". So you already cliecked to download and run. (You invited me to your house!). At your house you check my passport you say "I know where you live". So if I sell the user to use my app, and after I am authehicated, encourage.
  Now that I answered your question, some of the people that talk up "security" side of the coin, do you have applications you can show me that have users?

  .V

  Posted by: netsql on May 10, 2005 at 07:22 PM

• How did the anonymous person that posted about 4 below this post not leave a "Posted by:" ?

  The link you gave about "sign a jar steps pdf" is irrelevant and the reason why was posted in an earlier message. Essentially companies like Verisign are signing certs for companies named, "Click yes to continue". I kid you not. Here is a link to the article: http://www.benedelman.org/news/020305-1.html

  I maintain blindly trusting a corporation is a ridiculous notion. The behavioural characteristics of a corporation fit the definition of a psychopathic personality:

  Callous unconcern for the feelings of others.
  An incapacity to maintain enduring relationships.
  A reckless disregard for the safety of others.
  A pattern of deceitfulness.
  An incapacity to experience guilt.
  Failure to conform to social norms with respect to lawful behaviour.

  
  How did society even get to a place where we are expected to blindly trust corporations? As logical and smart software professionals how did we ever buy into this? I won't even ask how Corporations were granted the rights and status of 'person' in certain parts of the world.

  
  I remember a time not so long ago when the Java sandbox just became available and a lot of folks (including reporters) understood the benefits. I also remember Microsoft came out shortly after with the concept of digitally signing Active/X components. "blindly trusting corporations should be good enough for anybody". After the Microsoft PR machine cranked up the reality distortion field the benefits of the sandbox faded away into the anals of time and everyone was repeating the mantra, "trust is good".

  It is my hope that folks reading this become more active in pushing Sun to fix Java Web Start. I believe JWS is broken because the feedback mechanism is broken. Look at the _fantastic_ feedback given to the JDNC, JavaSound, and other projects that have the main developers available on a mailing list - and not hiding anonymously and actively participating in the discussions.

  Sun, I think you're doing much better recently. Really. You are obviously trying to come down from your white tower and walk among us common folk to create a community around the JDK. This is wonderful. Please include the unsigned JWS environment as a part of this process.

  Cheers.

  Posted by: markswanson on May 10, 2005 at 07:32 PM

• netsql asked: some of the people that talk up "security" side of the coin, do you have applications you can show me that have users?
  http://www.ScheduleWorld.com/

  Note the unsigned client can sync with devices like Palm, Blackberry, PPC, cell phones (J2ME and SyncML capable) as well as software products that have been SyncML enabled - like Outlook. The contacts system integrates with an LDAP service which also integrates with Mozilla Thunderbird/Mail, Outlook, KMail, Evolution, and any other LDAP compatible program.

  I have a huge userbase who have come to love and rely on it. In my completely biased opinion it's a shining example of what's possible to do in the sandbox. I take the concept of trust one step further: I can't read the encrypted events you store on my server (because I don't have your private key) yet you can still use the full compressed diff add/merge/remove and sharing features of the system. This is a completely different experience than using protocols like LDAP or SyncML.

  Give it a try, it's free.
  

  Posted by: markswanson on May 10, 2005 at 07:51 PM

• How did the anonymous person that posted about 4 below this post not leave a "Posted by:" ?
  I don't think they did.
  I think they just put a <li> tag in the middle of their post.

  Like this.

  Posted by: grlea on May 10, 2005 at 10:52 PM

• netsql wrote:

  You have to go to my web site, I have to [tell] you to click, download and install.

  Philosophically:
  Again, clicking on a link on someone's website does not equate to trusting them. Trust is not something that a computer can decide for people (unless they've told it to run any old thing). Only the person can decide if they trust an entity, and so they have to be asked.

  Practically:
  Someone with malicious intent could easily convince you to click a link on their website. If someone can convince a certificate authority to give them a certificate for "Click here to continue", I doubt they'll have any trouble getting web surfers to click a link that starts an application.
  Most users won't know they can look at the bottom of the window to see where the link goes and then most of those who do know wouldn't know what a JNLP file was.
  Furthermore, even for me, who does know what JNLP is, there's no way of telling from the URL whether your application will be signed or not. So I won't know whether your application is getting full access to my machine without asking me. I won't have an option to say that I don't want it to, because WebStart won't even tell me that your app is running signed. That's not security.

  Graham.

  Posted by: grlea on May 10, 2005 at 11:32 PM

• Hi all,

  Thanks for all the good comments here, and I have forwarded them to our user experience team for further evaluation.

  I won't be able to followup each comment, but there are a few points I want to highlight:
  1. While there are many alternatives to present the information in the Java security dialog, the native security dialog is actually a very good reference point. If end users are going to download and run native executables based on the information presented by the native security dialog, as someone pointed out, there is no reason why the Java security dialog should be more scarier than the native security dialog.
  2. The discussion around using JNLP APIs to access outside the sandbox v.s. using signing to have full access was interesting. There are valid reasons why some applications need to have full access to the environment, and there are also valid reasons why some applications want to run in the sandbox. However, if the application uses the JNLP APIs to access local files, it really means that the application requires permission that is not allowed in the regular sandbox, and what JNLP APIs provide is just a way to access these local resources without requiring the application to be signed. In the JNLP API case, a security dialog will popup whenever the JNLP API is used to access local resource. In the signed application case, a security dialog will popup when the application is loaded. Would you be better off to simply sign the application to have full access to the environment? One may argue that signing an application requires purchase of certificate and it is not desirable. However, this is not true - you may sign an application simply using a self-signed certificate, and no purchase of certificate is required. One may still prefer applications to run in sandbox than those running with full access. In this case, will suppoting fine-grained signing (signing with required-permissions declaration and only the declared permissions are granted) satisfy your need?

  Tell me what you think.
  -Stanley

  Posted by: stanleyh on May 11, 2005 at 07:14 AM

• Almost everybody seems to be completely sold to the idea of having a "sandbox" that is safe to use for running unknown apps. -And that this "sandbox" should be the default safety-mechanism - the catch-all safety-thing. -And that we should all put emphasis on the higher security that this sandbox is giving us - and therefore making our software "safer" and better than the other's.

  The concept is good I think, but running the risk of being lynched: Isn't it a bit naive to put all your trust (!) in this? If I was supposed to trust this sandbox, I would like Sun to guarantee, that it will never ever be compromised, that it is completely and 100% safe and that I will be compensated for all problems that could arise from using this technology.

  Is it even possible to create this "sandbox" on operatingsystems that are known to be - at best - unsafe? Of course we would not be to blame if it was the OS that actually made the mess - but I have a strange feeling that my customers don't really care about that. I would be able to explain my fellow coders that it wasn't my fault - but that does not pay the rent!

  To me it's not a question of "being bothered" with writing "the right" kind of software. To me it's about putting the energy and bother into areas where it really makes a difference - and honestly I don't put much trust in the sandbox and its abilities of keeping us out of harms way. Maybe it's ok for now - but who knows what happens tomorrow?

  -The only thing that is guaranteed in this world is that we are going to die someday - maybe.

  Posted by: bentzn on May 11, 2005 at 04:46 PM

• Stanley, here's my response to some of your questions/statements...

  
  There is no reason why the Java security dialog should be more scarier than the native security dialog.

  I think there are reasons, some of which have been discussed below. The main one would be if Java applications were to be marketed as being more secure than native Windows applications. It seems lately that Sun has decided it's best to make Java as much like Windows as possible, rather than trying to convince pople that it's better. I don't agree with this but I concede it's probably a good business/marketing decision.

  
  There are valid reasons why some applications need to have full access to the environment,

  There are currently. I believe if the sandbox were more complete there wouldn't be valid reasons.
  I wish WebStart worked like ZoneAlarm and every time the application asked to do something that required security permissions, the user would get a little pop-up box saying something like:

  The 'Java Office Clone' application is trying to read the file "My Documents\Weekend plans.xls"
  What do you want to do?
  
  (  ) Allow 'Java Office Clone' to read this file now.
  (o) Don't allow 'Java Office Clone' to read this file.
  

  More Options >> (expandable thing)
  
  (  ) Always allow 'Java Office Clone' to read this file.
  (  ) Always allow 'Java Office Clone' to read any file.
  (  ) Never allow 'Java Office Clone' to read this file.
  (  ) Never allow 'Java Office Clone' to read any file.
  
  

  There would be no need for certificates or signing or special JNLP APIs. We'd just code against J2SE and WebStart would do all the work for us. IMO, this would make WebStart an absolutely awesome platform to develop applications on.

  
  Would you be better off to simply sign the application to have full access to the environment?

  This is possibly the wrong question. Maybe we be asking whether the user is better off having applications that regularly request full access to their machine? I think no, because it draws them into a habit where they mindlessly grant full permissions to every application that asks.

  
  you may sign an application simply using a self-signed certificate, and no purchase of certificate is required.

  Yes, you can do this. It probably shouldn't be allowed. I could create a self-signed certificate saying that I am Microsoft or Sun Microsystems and then distribute a signed WebStart application. In response, WebStart will display a pretty box saying "This application is published by Microsoft. The publisher cannot be verified. Do you want to run it?" This is pretty useless, because most people won't even read "The publisher cannot be verified", many others won't know what it means, and everyone will just think it's a Microsoft program and go ahead and click "Run".

  
  One may still prefer applications to run in sandbox than those running with full access. In this case, will suppoting fine-grained signing (signing with required-permissions declaration and only the declared permissions are granted) satisfy your need?

  I think my ZoneAlarm idea is what would satisfy our needs the most.
  Failing that, I think what will satisfy is a more functional sandbox, rather than a sandbox that provides more ways to escape from it.

  If the security warning dialog is going to be as "pretty" as it is above, there's no point in having fine-grained permissions because you're no longer asking the user if they want to grant you permissions anyway, you're only asking then if they want to run the application.

  Graham.

  Posted by: grlea on May 11, 2005 at 06:54 PM

• Hi Graham,
  >> The main one would be if Java applications were to be marketed as being more secure than native Windows applications. It seems lately that Sun has decided it's best to make Java as much like Windows as possible, rather than trying to convince pople that it's better. I don't agree with this but I concede it's probably a good business/marketing decision.
  Most consumers don't understand security, and they will not think the software is better simply because it uses more security lingo in the UI. On the contrary, the users are likely to be scared away from using the software because they are uncertain with what their actions will cause after they accept the security dialog. Our goal is to make Java applications as easy to use and as seemlessly integrated as your other native applications as possible, and a more secure Java application should not be put at disadvantages in deployment.

  >> Maybe we be asking whether the user is better off having applications that regularly request full access to their machine? I think no, because it draws them into a habit where they mindlessly grant full permissions to every application that asks.

  In some sense, popup every time the application asked to do something that required security permissions will also not make the system more secure. If the users are going to mindlessly click OK on every security dialog that the application triggers, the approach is no more secure than simply granting the application full access. And this is why fine-grained signing could be more useful - you will not only show the users a single security dialog (instead of a popup everytime the application triggers some actions), but you will also effectively lock down the exact set of permissions the application will have in the sandbox, even if the users mindlessly click OK on everything.

  - Stanley

  Posted by: stanleyh on May 11, 2005 at 08:11 PM

• 
  Most consumers don't understand security...
  Our goal is to make Java applications as easy to use and as seemlessly integrated as your other native applications ...

  Like I said already, I don't agree with this but I concede it's probably a good business/marketing decision.
  Personally, I think it would be better to take the opportunity to educate users about security. Creating a system where people can easily run mal-ware does not do them any favours.

  
  In some sense, popup every time the application asked to do something that required security permissions will also not make the system more secure. If the users are going to mindlessly click OK on every security dialog that the application triggers, the approach is no more secure than simply granting the application full access.

  I disagree. The difference is that, with the ZoneAlarm paradigm, the user gets to decide whether to trust the program based on what it is trying to do at the time. With your screen that you've pasted here, the user is only asked "Do you wish to continue?" Users will mindlessly click 'Continue' on your dialog because it doesn't tell them anything at all - it just says "do you want to run it"? On the contrary, people do read their ZoneAlarm popups, because it tells them enough to make an informed decision.

  
  And this is why fine-grained signing could be more useful - you will not only show the users a single security dialog (instead of a popup everytime the application triggers some actions), ...

  As I said, if the single security dialog you are showing is the one you've posted already, fine-grained security would add nothing because you're not telling the user what permissions the application is asking for, you're just asking if they want to continue.

  ... but you will also effectively lock down the exact set of permissions the application will have in the sandbox, even if the users mindlessly click OK on everything.

  This is a bit of a moot point, because you've only "locked down" the application to having the permissions that it asked for. Applications that want to delete the hard drive will ask for "Delete the hard drive permission". The dialog will ask "Do you wish to coninue?" and users will click 'Continue'.

  I really don't want to be in a position where I say at parties, "I write programs in Java," and the response is "Oh, I hate Java. I got this virus through its stupid WebStart thing that stole my credit card numbers and then corrupted my hard drive. No way would I ever run a Java program again."
  I think the current desire to dumb down the security is making that situation much more likely.
  I don't think Java doesn't has to become more like Windows, because I think it can be better.

  
  Graham.

  Posted by: grlea on May 11, 2005 at 09:39 PM

• Stanley, I agree with your proposition but it needs more precisions
  
  In this case, will suppoting fine-grained signing (signing with required-permissions declaration and only the declared permissions are granted) satisfy your need?

  
  I think it's a good idea. But I suggest the following behavior :

  An application, signed OR NOT SIGNED, comes with the list of permissions it requires (I think there is work to do to collect all this permissions for a given application but...)
  An application may be signed
  Before launching the application, the user is informed about the identity of the application (signed or not, valid certificate or not)
  Before launching the application, the user is informed about the permissions required by the given application
  Then the user has to choose if he wants to trust the application or not.

  If yes, then the application will run (as Stanley said) with the permissions it required and no more
  if no, then the application WILL RUN but in the sandbox

  
  I think that it is important to execute an application even if the user does not trust the application. The idea is: you clicked on some button to launch this app so we are going to launch this app!! But are you trusting this app? I think it's better because it will not force the user to trust the app to see "something". It may give more confidence to a user who knows that he can run any app without any risk. I know that most of the applications that will not have the permissions they require will fail. However it may convince developpers to better deal with permissions exceptions since the more a user will see of an application without trusting it the more he may be interested by this application (just because he can try it).

  
  Moreover, I think it's important to let the user feel that he drives his computer. When the list of permissions required by a given application is shown, it may be usefull for the user to be able to remove some permissions or give some precisions about others. For instance, if an application asks for a FilePermission for the user's home directory, it may be interesting for the user to restrict the permission to just a subdirectory...and in this case, a well written application may work in a lot of cases.

  
  Clearly, I think it's a good idea that an application can specify the permissions it requires and to force, whatever may happen, the application to respect this permissions. I also think that it has no sense if the user can't be informed about what this permissions are. If the user does not care, he will allow the excecution. But if he cares, he has the information.

  Posted by: pgrange on May 12, 2005 at 05:43 AM

• I'm sorry that the development of this seems to be not market-driven. The people who disagree with the idea of having the marketing-department control the development ought to think just a little about who actually pays the rent.

  
  If I say at parties that I develop with Java, people look at me and say "Java, that's actually some kind of coffee, right?". My experience is that nobody really cares.

  The only feature I have ever been able to sell to an _enduser_ is the remote possibility that he can run the application on Linux too - if he ever gets that urge...

  
  Maybe this is the reason why Java is one of the best languages around but still not the most widely used... I guess we'll just have to live with it.

  Posted by: bentzn on May 12, 2005 at 11:41 PM

• >> grlea: I did not mean the posted security dialog screenshot will be exactly the same for the fine-grained signing case. If the application is signed and declares fine-grained permissions, the security dialog should reveal this information to the users, so the users will know exactly what permissions they will grant if they accept the security dialog.

  >> pgrange: I like the idea of informing the user about the permissions required by the given application. On the other hand, if the application is unsigned (i.e. sandbox mode), it may not make sense to inform the users because each dialog in the launching process is an obstacle to your deployment. Also, running a signed application in sandbox mode as a fallback could be very problematic. The reason why you sign the application in the first place is to break out of the sandbox, and many applications that expect full access to the environment through signing may not work properly in sandbox mode at all; in this case, it may be better not to run the signed application than running the signed application in sandbox mode with hundreds of exceptions.

  - Stanley
  

  Posted by: stanleyh on May 13, 2005 at 02:51 AM

• is grahm and grlea sun employes?
  .V

  Posted by: netsql on May 14, 2005 at 10:42 AM

• Negative. I don't work for Sun.
  Why did you think that?
  If I was a Sun employee, I don't think I'd make criticisms like this so publicly.

  Graham.

  Posted by: grlea on May 17, 2005 at 07:06 PM

• I am glad that my earlier posts advocating better use of the Java sandbox have develop such strong advocates.

  I think the important thing to remember that as engineers we may not have all the answers when it comes to human interaction factors and we should let others who know these things worry about these matters. Alan Cooper's The Inmates Are Running the Asylum explains why.

  With this in mind I don't think we should worry about 'too many security exceptions' in a sandbox-constrained JWS application. I think there should be a nice answer but I don't think as developers we should worry about this. Get Alan Cooper and let him come up with the solution. Just because we can't come up with the perfect solution doesn't mean some English lit major can't. And certainly doesn't mean that the permissions a JWS application is asking for shouldn't be checked and modifiable by the user.
  Yes my mom needs to be able to manage it. But that is what human factors people should make possible.
  Finally, here is a daring thought for you all: Every Java application should live in a sandbox that is visible and editable by the user.
  In this day and age of spyware, keystroke loggers, viruses, trojan horses, worms, etc. lets make 'Java' mean security and safety. Think about it in your heart of hearts wouldn't you like to see Java warn when an app wants to use JNI:
  This application is trying to access the underlying insecure, bug-ridden, and sloppily coded Microsoft libraries and operating system. This is usually a sign of a virus or some other malicious program. Do you want to permit this operation?
  Yes, I am on the boss' computer and I don't careNo, I have a brain and have been paying attention these last two years
  

  Posted by: patmoore on May 19, 2005 at 02:31 AM

This work is licensed under a Creative Commons License.