Re: ISSUE-28: [Policy] Requirement for NO security prompting [Security Policy Framework — General]

Hi,

ISSUE-28: [Policy] Requirement for NO security prompting  [Security Policy
> Framework — General]
>
> http://www.w3.org/2009/dap/track/issues/28
>

In response to the action from the last call [0], this mail is my summary of
the discussion and agreement so far on this issue. Please comment/correct if
my interpretation is wrong.


*Scope*

This issue is a proposal that:

- User Agents MUST NOT present modal dialogs to prompt users for security
decisions;
- Users SHOULD have control over general configuration of security
decisions.

*Points of agreement*

Prompts should be eliminated whenever possible. Many prompts do not provide
any meaningful security because:
- they don't provide the user with the information needed to make an
informed security decision;
- the user is inclined simply to dismiss the prompt and permit the operation
just because that's what's needed for the application to continue.

If prompts are shown and dismissed as a matter of routine, then the user is
less inclined to take any security decision seriously, which further
undermines the effectiveness of a user-driven access control system.

There will unavoidably be situations, however, where the user is required to
make access control decisions when web applications wish to use sensitive
APIs. The key issue remains, therefore, and DAP needs to ensure a framework
is provided that allows it to happen, and maximises its effectiveness,
rather than seeking to eliminate it altogether.

Modal prompts (ie prompts that block all other user interaction until
dismissed) seriously compromise user experience and are avoidable.

Any prompt or dialog that requests a user security decision at runtime (eg
at the time a sensitive action is attempted) can be non-modal if the API
that initiates it is asynchronous. DAP APIs must be designed so that all
operations that could potentially trigger a prompt are asynchronous.

If a sensitive operation requires some user interaction to initiate it (such
as choosing a file to upload, or pressing the shutter on a camera), then
this interaction can be arranged so that it is an implicit user
authorisation. Whether or not this is possible depends on the operation or
API in question.

Given the wide range of possible valid means of eliciting user security
decisions, DAP should be minimally prescriptive about the user experience,
and should not assume that the same user experience is appropriate for every
API.

*Points of issue

*This is not a comprehensive list but these issues were raised and not
resolved in the discussion.

User authorisation vs other policy authority

This issue is who makes security decisions; in particular whether the user
is the sole authority for decisions (whether by configuration of settings,
or responses to prompts, or both) or there is another authority that
determines the rights given to an application.

Many existing ecosystems for mobile applications are based on a trust model
in which a particular distributor (such as a network operator) certifies an
application as trustworthy, eliminating run-time user prompts. This approach
avoids the disadvantages of prompts, but at the expense of taking legitimate
control away from the user. Other approaches, such as BONDI, do not
hard-code this type of trust model, but nonetheless provide for a policy
authority to determine an access control policy, and this policy can require
that certain decisions are made without reference to the user.

Although the role of any access control policy, and authority over it, are
beyond the scope of this particular issue, DAP's approach to prompting must
take these possibilities into account.

Granularity of user decisions

This issue is whether the user is presented with a single security decision
that covers multiple operations, or independent prompts for individual
operations. Blanket authorisation for an application to use multiple APIs,
as often as required, eliminates run-time prompts but also may leave the
user without the context required to make a meaningful security decision.
Also, a user may not be prepared to give blanket approval for a certain
operation but may instead wish to give permission in specific circumstances
only.

DAP should not presuppose that an approach involving blanket permissions
only (eg implicit granting of blanket permission by allowing installation to
occur, or an explicit blanket permission given when the application is first
run) is the right answer. Both approaches have advantages for different use
cases and we should try to define a system that supports all use cases
effectively.

Application control vs user agent control

This issue is whether the application, or the user agent, or both, have a
role in determining the extent to which prompts may appear, and at what
time.

Usually an application itself knows whether or not the user has implicitly
given permission for a particular operation. For example, after a user as
explicitly clicked the "send email now" button, he should not be faced with
a dialog saying "this application wishes to connect to the network ....".
The user agent, by itself, cannot tell if the application has earned the
right to perform an operation without further explicit user acknowledgement,
so there is an argument for the application being able to influence whether
or not the UA intervenes with a prompt. This, of course, requires greater
trust in the application than would be necessary if the UA intervened
unconditionally.

DAP should determine whether or not there is a role that the application
itself can play in how and when security decisions are elicited explicitly
from the user.

----
[0]: http://www.w3.org/2009/10/14-dap-minutes.html#action01