United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8029649 Reduce dialog frequency when app is run multiple times
JDK-8029649 : Reduce dialog frequency when app is run multiple times

Details
Type:
Enhancement
Submit Date:
2013-12-05
Status:
Resolved
Updated Date:
2014-07-18
Project Name:
JDK
Resolved Date:
2014-01-09
Component:
deploy
OS:
Sub-Component:
plugin
CPU:
Priority:
P2
Resolution:
Fixed
Affected Versions:
7u55,8
Fixed Versions:
7u55 (b04)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
Summary
-------
Reduce Frequency of Security Dialogs when application or applet is run multiple times.

Engineering wiki: http://wiki.se.oracle.com/display/JPGC/Dialog+Frequency


Success Metrics
---------------
- feature is completed when:
    Reduction in Dialog frequency is achieved as expressed in the requirement on: 
http://wiki.se.oracle.com/display/JPGC/Decrease+frequency+of+security+prompts+when+re-launching+the+same+application
- Pass rate for nightly, promotion testing:
NA - this metric should not be part of a bug description
- Performance implications:
none - This feature should not have any measurable performance impact.
- Internal EA sign-off
NA - signoff from SQE and Dev should not be part of a bug description


Motivation
----------
 PRD: http://oracleplan.oracle.com/goto?ra_=entity&entityType=FEATURE&entityId=1145074

Description
-----------
PRD: http://oracleplan.oracle.com/goto?ra_=entity&entityType=FEATURE&entityId=1145074
see implementation wiki at: http://wiki.se.oracle.com/display/JPGC/Dialog+Frequency

Alternatives
------------
N/A

Testing
-------
TBD (by SQE) unless specific testing requirements are anticipated developer, testing requirements should not be part of a bug description

Risks and Assumptions
---------------------
no known extraordinary risks or assumptions

Dependencies
------------
None

Impact
------
  - Compatibility: N/A
  - Security: (security team rep should review changes)
  - Performance/scalability: N/A
  - User experience: N/A
  - I18n/L10n: N/A
  - Portability: N/A
  - Packaging/installation: N/A
  - Documentation: need change in Release Note / deployment docs
  - TCK: N/A
  - Internationalization: REPEAT FIELD
  - Localization: REPEAT FIELD
  - Legal: N/A 
                                     
2013-12-19
latest webrev at: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.7.0_55/8029649/deploy/webrev/
includes fix for html applet lap problem caused by the fix for https://bugs.openjdk.java.net/browse/JDK-8021391 (in 7u55) or 
https://bugs.openjdk.java.net/browse/JDK-8028517 (in 8u5)

That fix breaks lap files for html applets.
In conjunction with other changes in LaunchDesc.getCanonicalHome() (made by various other security fixes) it may also break lap files for jnlp applets that have no href in the jnlp file.

The reason is, the basis of Cache.getNewLapFileName() requires that a the (url, version) passed in identifies a cached object (or at least refers to an existing resource on the net that can be downloaded).
        CacheEntry ce = getCacheEntry(url, version, dir, ResourceProvider.DOWNLOAD_NORMAL);
        if (ce == null)
            return null;
causes null to be returned whenever dummy url is used to identify the lap file location.
Applet2Manager.getAppInfo() has:
        ai.setLapURL(new URL(getCodeBase().toString() + "/" + ai.getTitle()));
which is a dummy URL used not to refer to any real resource, but only for referring to the lap file.
(this causes the problem for html applets)

It can also cause the same problem for jnlp applets, since applet jnlp file is cached (in plugin) based on it's real location on the web, but LaunchDesc.java uses getCanonicalHome() which returns (for jnlp file w/o href) the url to the main jar + "jnlp", also a dummy.
In webstart, this is what the jnlp file is actually cached as, but in plugin (where we always know the real location) the jnlp file is cached based on it's real location.

This is not a problem yet in jdk8, but should be seen in 8u5 since the above change is resolved in 8u5.

It is required that persistent lap file data exists in all cases, so I propose the following as part of my fix to 8029649:

1.) change to LaunchDesc.getCanonicalHome(), such that if getLocation() is null, but getSourceURL() is not null, the return getSourceURL() instead of constructing the canonical URL.

2.) temporarily change Cache.getNewCacheFileName(), instead of returning null when there is no corresponding cache entry, to return getCacheFileName().

3.) file a follow-on bug to fix the fix to JDK-8021391 , (filed bug #JDK-8031130 ) so that the new complex file name for the LAP can be computed without requiring an index file for the cached object ever actually exists.

                                     
2014-01-02
full test spec at: http://wiki.se.oracle.com/display/JPG/JDK-8029649+Test+Spec

I used various javaws app tests from: http://oklahoma.us.oracle.com/www/tests/sandbox/
various jnlp applets from : http://oklahoma.us.oracle.com/www/tests/sandbox/applets
and non-jnlp applets from: http://oklahoma.us.oracle.com/www/tests/sandbox/oldapplets

many of these are pointed to by: http://oklahoma.us.oracle.com/www/tests/sandbox/test.html
                                     
2014-01-03
Request from Release Team to push this enhancement to 7u60 for EA access.
                                     
2014-03-12
note above requirements make no mention of ESL, or of which security prompts will be affected - note that at default security level, unsigned, self-signed, and expired cert signed apps may be blocked, so it may be necessary to put app on ESL, or reduce security level to medium , to take advantage of this.

We propose this effect:
1.) unsigned dialogs (including normal, and local apps), but not unsigned and below base (expired dialog).
2.) self-signed or signed with expired cert dialog for sandbox-permissions
3.) self-signed or signed with expired cert dialog for all-permissions
4.?) is there any reason to also handle CA-signed not-expired dialog ? (already has always remember checkbox)

Mechanism will be to record the remember till date in the LAP
                                     
2013-12-06
SQE OK to take this
                                     
2014-03-12



Hardware and Software, Engineered to Work Together