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

On Fri, 9 Oct 2009 richard.tibbett@orange-ftgroup.com wrote:
> 
> With the exception of the drag-and-drop mechanism (which FWIW is quite 
> interesting) all other methods require the user to action a prompt or 
> select a preference to a prompt, whether that prompt is modal or not.

I think the permissions model exposed by <input type=file> is pretty neat 
in this respect because it is unambiguous while not appearing to be a 
security prompt at all. The user makes a very explicit permissions choice, 
but has no idea he was even prompted to do so -- in fact, he has to 
request the prompt, and the prompt feels like part of the workflow.


> Having said this, it may be better to say that our model for security 
> prompting should be non-modal. The jury is out on that.

I think the jury returned a verdict long ago. :-)


> Following up from [1] I think there is a considerable case that the 
> application should be able to provide a message along with the features 
> they require.
> 
> Such a note could say "Do you want to continue getting your work done?" 
> as you suggest or it could be more specific "This app wants to take a 
> photo."

I didn't mean that a prompt would literally say "Do you want to continue 
getting your work done?", I meant that the prompt would be interpreted as 
saying that, regardless of what it actually says.

Most users don't read prompts. At all. They see a dialog, they immediately 
hit a button (more or less at random), and continue on their way, 
blissfully unaware of what they just agreed to. Explicit yes/no permission 
requests simply aren't going to actually be secure.

The Geolocation model, while currently usually implemented as a binary 
yes/no, could also be implemented as a non-modal and non-binary user 
interface, in such a way that the user would not realise he'd been 
prompted for a security decision, but while still getting the right input, 
by showing a non-modal widget (e.g. a range control) that allows the user 
to specify the accuracy with which the page should get geolocation data, 
defaulting to no data at all.


> - basically anything the app developer wants to communicate along with 
> the features is fine. The requirement is then that this message is 
> displayed + the features being requested and the user can decide to 
> grant or deny access to individual features or all features as required.

Anything that relies on the user deciding to grant or deny access, and 
knowing that that is what they are doing, is IMHO fatally flawed.


> I agree with your summary of prompts becoming useless quickly. This
> often leads us down the path of attempting to authorise applications
> through other mechanisms but the elephant in the room is that user's
> still need to opt-in, making the need for prompts largely unavoidable

I disagree, there are multiple ways to do permission UI that doesn't 
involve any prompts. In fact, I'd say that not having prompts is a 
requirement.


> It will be an art unto itself to design user opt-in in such a way that 
> does not interrupt the user's workflow. This would be something I'd 
> prefer to delegate to the applications that require Device API access 
> rather than dictate from any kind of policy.

I think it is absolutely critical that we take the responsibility to 
design the APIs such that they enable a non-modal interaction model for 
granting permissions. We cannot leave it up to the Web apps, because they 
are hostile. The security model is an inherent part of any such API; it's 
not something we can just leave undefined or vague. It is the most 
important part of the API design, and everything we build depends on 
having had the right security model.

It's also something that will likely vary from API to API, so IMHO we 
can't make a single decision up front.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 9 October 2009 11:12:04 UTC