TrophyCustomer's Canvas is honored with a 2020 InterTech Technology Award! Learn more 

Some Java security rules insights

When Oracle released Java 7 Update 45 several months ago, I noticed a strange behavior - if the user decides not to update Java, the uploader starts working incorrectly (although it was working great a day ago).

The typical symptom is - it starts sending empty requests. The explanation for this symptom is simple - Java blocks a LiveConnect module which is necessary to make calls from applet to JavaScript and vice versa. Therefore, the uploader settings cannot be initialized, so it does not know whether to send original files or thumbnails, etc. So it does not send anything.

It was strange, but as there was a simple solution - just to update Java to the latest version. Oracle is suggesting installing the update quite aggressively, so I decided that this is not a big problem and disregarded it.

About a week ago, Java 7 Update 51 was released and the situation came back. If the user has Java 7u45, LiveConnect fails and starts working again if the user updates Java. As Java 7u51 is more distruptive than 7u45, people try to avoid updating it and that's why this problem became to arise more frequently. That's why I thought that it would be great to understand why it happens and whether we can do anything about it.

I have read a number of articles on Oracle site and here what I have found.

Security Baseline

There is a so-called Security Baseline for Java defined. Simply speaking, security baseline is a minimum Java version that Oracle currently considers as safe. If the version is up-to-date, it is considered to be above the security baseline and Oracle does not create any additional problems to the user. However if it is below the security baseline, Oracle considers it to be potentially unsafe.

How do they define whether the version is above or below the security baseline? There are two factors:

  1. Each Java update contains a built-in timebomb. It is considered to be above the security baseline within several months after release (Oracle declares the specific Expiration Date for each update in Release Notes).
  2. Additionally, it checks Oracle servers and verifies whether the security baseline is updated. This way, Oracle can make any release outdated every minute.

Today, the security baseline is Java 7 Update 51 (for the 1.7 generation of Java). It explains why 7u45 users have problems.

Security Baseline and LiveConnect

What specifically happens when the applet is below the security baseline? Unfortunately, I did not find a complete list, but it is obvious that Oracle considers that the user should not use Java applets in such scenarios. So no wonder that it begins to work incorrectly.

However I wanted to find a concrete proof that Oracle blocks LiveConnect for outdated Java installations. After reading various release notes, I have found that they enabled this behavior in the Java 7 Update 25:

LiveConnect calls from JavaScript to Java API are blocked when the Java Control Panel security slider is set to Very High level, or when the slider is at the default High level and the JRE has either expired or is below the security baseline.


So this mystery is unveiled: Oracle may just press a "magic button" and the Java uploader on old Java runtimes will fail. Intranet users who don't have access to Oracle servers has a little benefit - they cannot put their Java under the security baseline suddenly, but it is still happen eventually, because of a built-in Expiration Date.

The only way to get Java uploader working smoothly is to encourage users to update their Java. Fortunately, it is more difficult to stay with old version than to update it. Those rare users who don't want to update Java for whatever reasons have a single option - change the security level (AKA Security Slider) to Medium.