FULL PRODUCT VERSION :
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
I've tested this on Windows XP Professional 32-bit and Mac OS X 10.5.8.

A DESCRIPTION OF THE PROBLEM :
If a JNLP file contains a security section with the "all-permissions" tag like in the following example, the user never receives a prompt about whether or not he wants shortcuts installed. Instead the shortcuts are installed unconditionally.

  <security>
    <all-permissions/>
  </security>

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. In the Java Control Panel, under the Advanced tab, expand the "Shortcut Creation" setting and select one of the following: Prompt user, Prompt user if hinted.

2. Launch a JNLP app that contains the following nodes in its JNLP file:

<jnlp ...>
  <information>
    <shortcut online="false">
      <desktop/>
      <menu submenu="someText"/>
    </shortcut>
  </information>
  <security>
    <all-permissions/>
  </security>
</jnlp>


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Web start should display the dialog asking the user whether or not he wants shortcuts installed. This dialog would appear if the "all-permissions" tag were omitted.

A similar problem was described in bug ID 6570320. However, that bug was wrongly closed with the incorrect conclusion that the "shortcut" tag in the JNLP file is a command to install shortcuts. In actually, the "shortcut" tag means that the user should be given the choice of installing shortcuts. There is no use case for forcing the shortcuts on an end-user, but asking if the user wants shortcuts is a common and expected use case.

The anonymous user who posted in bug ID 6570320 on 01-NOV-2007 provides a correct illustration of why the user settings in the Java Control Panel should be respected even by applications running with elevated privileges.

Please revisit this issue.
ACTUAL -
The dialog does not appear and the shortcuts are installed.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
There is no workaround since this bug pertains to applications that need higher access to the local system.