Absence of Malice in JavaFX

Because JavaFX Script programs compile to Java CLASS files and run within the Java Runtime Environment (JRE), they are subject to the Java security model.  When a user clicks a Java Web Start link or navigates to a page that contains an applet, the Java code must play exclusively in "the sandbox" unless the user gives it permission to jump out.  There are a couple of ways to enable the user to give this permission to the application:

1. Option #1: Don't sign the JAR files that contain your JavaFX application.  By not signing the JAR files, you are ensuring that the user will be asked to authorize any out-of-sandbox-experiences.  For example, the Earthrise at Christmas post contains a Java Web Start link to a JavaFX application that isn't signed.  Because the application displays an image that is loaded from another website (in this case nasa.gov) the following Security Warning dialog is presented to the user:
   
   
   
   This option makes the user respond to Security Warnings, but if the code isn't signed, then the user shouldn't be expected to trust the application without receiving these kinds of warnings.
2. Option #2: Sign the JAR files that contain your JavaFX application.  By signing the JAR files, you are ensuring that the application will not execute unless the user indicates that he/she trusts the signer of the code.  In addition, the user won't be asked for permission for the application to play outside of the sandbox when, for example, the image from Nasa above is accessed, or a file is written.  To demonstrate this, if you click the following Java Web Start link to the Earthrise at Christmas application in which the JAR file is signed, you'll be presented with the Security dialog shown below it:
   
   
   
   
   
   
   Notice that the the dialog says that the signature has been verified/validated (because a code-signing certificate was used).  This is an important feature because if the signature can't be verified, then the user can't be sure who really signed it.  This opens the door for spoofed and malicious applications.  The only way that I would run an application whose signature hasn't been verified, is if I knew by some other means who published the application (e.g. the application was written by a colleague and it is located on a corporate intranet).

What about the Self-Signed Jar option in NetBeans (using the JavaFX Plug-in)?

If you select the Self Signed Jar option in NetBeans as shown below, then a dialog similar to the one above will appear when the user runs the application, but it will say that the signature can't be verified.

For reasons described above, posting or executing Java and JavaFX applications with self-signed JARs on the Internet is not a good practice.  It's better to go with option #1 above and let the user approve any out-of-the-sandbox behavior, or option #2 with a code-signing certificate (e.g. from VeriSign or Thawte).

Creating and Signing Pack200 (Compressed) Files

The JAR files that contain Java/JavaFX applications can be further compressed into the Pack200 format and deployed with JNLP.  To create and sign a Pack200 file, use the following commands available with the JDK, shown here in the context of the Earthrise at Christmas application:

pack200 --repack HelloEarthRise.jar

jarsigner -keystore [keystore url] -verbose -keypass [key password] 
  -storepass [keystore password] HelloEarthRise.jar [keystore alias]

pack200 HelloEarthRise.jar.pack.gz HelloEarthRise.jar

As always, please leave a comment if you have any questions.

Regards,
Jim Weaver
JavaFXpert.com

Comments

[Jim Weaver]

"On OS X, if you don't sign, undecorated = true does not work. If you need fullscreen without titlebar, you'll have to sign."

Wilson,

That's good to know!

Thanks,
Jim Weaver

[wilson ikeda]

On OS X, if you don't sign, undecorated = true does not work. If you need fullscreen without titlebar, you'll have to sign.

OS X 10.5
Javafx 1.2

[Tobias Schweers]

Thanks for getting the details! Looking forward for the update :)

Tobias

------------
From Josh Marinacci:
"There were some issues which prevented crossdomain.xml from working properly in all cases (such as pre-6u10 vms, but other cases too). The update release coming soon will fix this."
Thanks,
Jim Weaver
------------

[Mark Nankman]

This is very useful! Thanks for sharing this with us. I was struggling with this just now, and (again) your blog provided the answer.

By the way, thanks for cheering me on to further develop that JavaFX Twitter client. I have now migrated it to the 1.0 SDK. That was a lot of work! I just posted an item about it on my blog: http://blokmark.blogspot.com/2009/01/tweetbox-migrated-to-javafx-10.html. There's a link to the application binaries too. I am curious what you think of my little app.

[Jim Weaver]

From Josh Marinacci:
"There were some issues which prevented crossdomain.xml from working properly in all cases (such as pre-6u10 vms, but other cases too). The update release coming soon will fix this."

Thanks,
Jim Weaver

[Tom Hawtin]

Like Flash, Java 6u10+ supports a limited form of crossdomain.xml. That does of course require the (non-origin) server to have the file present...

[Jim Weaver]

"Hi Jim, in Amazon site the cover of your new upcoming JavaFX book does not contain Weigi Gao and Stephen Chin. Has some thing changed?"

Shakir,
Nothing has changed. Weiqi, Stephen and I are working very hard to write the book as we speak. Apress apparently hasn't sent Amazon an updated cover graphic.

Thanks,
Jim Weaver

[Shakir Gusaroff]

Hi Jim, in Amazon site the cover of your new upcoming JavaFX book does not contain Wegi Gao and Stephen Chin. Has some thing changed?

[Jim Weaver]

"so unlike Flash, JavaFX is not able to connect some server without a warning? I guess some of us can imagine that warnings will either alienate visitors OR keep them from running JavaFX alltogether? Are policy files or the crossdomain.xml supported without warning?"

Tobias,
The server from which that applet was deployed may be contacted without a security warning. I'm checking with Sun for an authoritative answer to your crossdomain.xml question.

Thanks,
Jim Weaver

[Tobias Schweers]

Hi Jim,
so unlike Flash, JavaFX is not able to connect some server without a warning? I guess some of us can imagine that warnings will either alienate visitors OR keep them from running JavaFX alltogether?
Are policy files or the crossdomain.xml supported without warning?

Regards,
Tobias

[GeekyCoder]

Hi, Jim
that is a a very useful explanation.

Developers will bound to compare the unintrusive Flash widget experience with JavaFX.
So in other words, to make it behave like normal Flash widget embedded in a webpage that display without security dialog,
1) Do not sign the JAR file
2) Do not make the applet perform outside-sandbox operation such as
accessing the disk (filesystem) and network.
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html#302

[Josh Marinacci]

If you don't sign your app then you won't get any security dialog.

[Jim Weaver]

"So how do we get JavaFX to work without a security dialog. For example, say my app doesn't access any local bits. A security dialog shouldn't be necessary, right?"

Gregg,

That's correct. If the app doesn't need to play outside of the sandbox, there is no need to sign the app, and no security dialogs will appear. For example, invoking the Pie Chart demo in the following post shouldn't produce any security dialogs:
http://javafxpert.com/weblog/2009/01/javafx-pie-chart-in-jfxtras-project-thanks-ben-jones.html

Regards,
Jim Weaver

[Gregg Bolinger]

So how do we get JavaFX to work without a security dialog. For example, say my app doesn't access any local bits. A security dialog shouldn't be necessary, right?