W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

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

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 21 Oct 2009 09:36:24 -0400
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Device APIs and Policy Working Group WG <public-device-apis@w3.org>
Message-Id: <6F155DF7-6B40-4166-B4A6-D02E5B8620EC@nokia.com>
To: ext Paddy Byers <paddy.byers@gmail.com>
> 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 on

is this related to the question of whether the user responds to a  
security decision or whether they indicate what they wish to achieve,  
that takes into account various security decisions? In other words,  
what is the appropriate question to the user - e.g. do you wish to tag  
photo with location (and do what is needed) could be the type of  
question as opposed to explicit security questions.

However the application level questions may be  hard to determine at  
the API level of work so this may require more thought.

regards, Frederick

Frederick Hirsch
Nokia



On Oct 20, 2009, at 7:07 PM, ext Paddy Byers wrote:

> 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
>
Received on Wednesday, 21 October 2009 13:37:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC