Properly configured LiveConnect Applets must work even on JREs below the baseline by default

Requirement:

For applets using LiveConnect that:
    - Are properly signed
    - Utilize the permissions attribute
    - Specify caller-allowable-codebase (wildcard or explicit url)

Treat all inbound LiveConnect calls from the allowable codebase(s) as "trusted" even if the current JRE is below the security baseline.

Background

As part of our efforts to secure systems that rely on the Java Plugin we added increased restrictions to the JRE that kick in whenever the JRE falls below the security baseline or expires. One such restriction is that self-signed and unsigned code can no longer run by default.

LiveConnect calls are always considered “unsigned” so even though the applet that handles LiveConnect calls might be properly signed we still treat the application as “unsigned”.

With the release of 7u45, which drove 7u25 and 7u40 to below the security baseline, calls to LiveConnect –even to applets that are being properly maintained, signed and with all the new required attributes present (e.g. caller-allowable-codebase is included in the manifest)- are being blocked by default on systems that are not updated to the latest JRE (7u45). Companies that rely on services provided by LiveConnect applets consumed by users outside of their control are having to ask their end users to update to 7u45 or to lower the security slider for 7u40/7u25 to medium to continue being able to use their services.

This has already resulted in high-level escalations to which the only answer we can give is you must “encourage” your users to update to 7u45, and you will have to do this again with every JRE update that moves the security baseline.

Since we already provide developers with mechanisms for restricting the use of LiveConnect to sites that they trust we can lower the constraints against the use of LiveConnect such that if a developer updates the applet itself with all the required attributes –for the time being the caller-allowable-attribute, in the future that might include new deployment descriptor- and signs it the applet will be considered “signed” even though the JavaScript itself can’t be signed.

http://oracleplan.oracle.com/goto?ra_=entity&entityType=FEATURE&entityId=1140123