Reduce dialog frequency when app is run multiple times

see requirements at: http://oracleplan.oracle.com/goto?ra_=entity&entityType=FEATURE&entityId=1145074

Requirement Description [Edit ]

Visibility: Internal
Availability: Public

Background:
As part of our efforts to enforce code signing we changed the functionality of the plugin so that when launching unsigned, sandboxed, code rather than just running the user has to accept a prompt. With 7u51 we further restricted unsigned code so that the user has to include sites with unsigned code in the site exception list before presented with a prompt.

In other cases, for actions that we considered unsafe, like self-signed code, we removed the option of remembering a decision to run the applet and require accepting a prompt for each launch.

Although the additional warning is not a big problem for most use-cases there are certain situations where a user might launch the exact same applet several times each day, sometimes several times an hour. In extreme cases applications have been designed so that as part of the “normal” flow of using an application an applet is launched to do some sub-task. In these cases the applications are now showing many security prompts while “running” the application and there is no way to decrease the frequency of the security prompt other than Deployment Rule Set which requires a non-trivial amount of technical expertise.

We must minimize the number of security dialogs showed for launching the same application as much as possible without compromising the security of the end-users systems.

This reduction in the number of dialogs should only be in effect if the user is running a JRE above the security baseline. We don’t want to create a false sense of security for users running on old JREs. If a user has to stay on an older JRE the Deployment Rule Set should be used and that will disable most if not all security warnings.

Requirement:
For users of a JRE that is unexpired and above the security baseline the JRE must minimize the number of security prompts showed when launching an application that was recently launched and for which permission was recently granted.

When launching applications hosted on http servers the user must see a security prompt the first time that the application is launched each day. Subsequent launches during the same day of the exact same application, as identified by a checksum of the main JAR file in the application, must not trigger a security dialog if the user already granted the application permissions to run that day.

Note that declining to run an application must not be remembered. If a user denies permission to an application and tries to launch it again during the same day the JRE, unlike the case when the user granted permission to run, should not remember the recent decision to decline permission to run and must prompt the user as if this where the first time the application is encountered.

For applications hosted on https sites, in consideration to the extra level of security afforded by the use of encryption, the JRE must remember the previous decision to run for seven days instead of just one.

 If the user choose to “clear remembered decisions” from the control panel or during the installation of a JRE all “implied” decisions described in this requirement must also be cleared and the user will be once again presented with dialogs when launching applications even if they launched them only a few minutes before clearing the decisions. Note that for this “implied” decisions, the restriction of clearing decisions that are only 30 days of older doesn’t apply. They will be removed even thought they are –by design- never older than 7 days.

If a JRE falls below the security baseline or expires these “implied” decisions would be ignored and each launch must now trigger a dialog. If the user updates to a secure JRE the “implied” decisions will once again be available. It would be preferable if the existing implied decisions survived the JRE falling below the security baseline and being updated but it is not critical. E.g. If a user grants permission to run to some applet on an https site, 2 days later the JRE expires. The user then gets prompted again. If the user updates to the latest JRE and tries to run the applet again before 7 days from the original launch it should run without a dialog.