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: <richard.tibbett@orange-ftgroup.com>
Date: Fri, 9 Oct 2009 12:03:25 +0200
Message-ID: <355A518BC0575547B2A3D6773AAF8EEF4DEF9B@ftrdmel1>
To: <ian@hixie.ch>
Cc: <pp.koch@gmail.com>, <brian.leroux@westcoastlogic.com>, <public-device-apis@w3.org>
Hi Ian,

Thanks for the input.

On Thu, 9 Oct 2009 at 02:38 Ian Hickson <ian@hixie.ch> wrote:
> 
> On Thu, 8 Oct 2009 richard.tibbett@orange-ftgroup.com wrote:
> > 
> > I agree with this. Modal dialogs are unavoidable because users MUST 
> > opt-in to API usage at least once (e.g. for checking device status) 
> > but perhaps on an ongoing basis (e.g. for sending SMS).
> 
> There are plenty of ways of designing APIs without modal 
> security prompts. 
> for example, you can have an API that uses a callback, and 
> just show a non-modal overlay offering to enable a feature, 
> e.g. an infobar with a label saying "Would you like to give 
> this site access to your current geographic position?" and 
> some buttons, e.g. "Deny geolocation access", "Permit access 
> but snap to the center of the nearest city", or "Permit 
> access for one hour". (This is the model used by the 
> Geolocation API, if I am not mistaken.)
> 
> Or you can have an API that uses events, and where if the 
> user, e.g., wants to use the camera with the site, then he 
> has to explicitly drag a camera icon onto the page. (This is 
> the model used for the drag-and-drop file upload mechanism.)
> 
> Or you can have an element that shows an unstylable widget 
> which, when activated *by the user*, shows modal UI for 
> implied permission selection, in the form of an activity the 
> user understands. (This is the model used by the <input 
> type=file> file upload mechanism.)
> 

I agree that prompts may not have to be modal. Perhaps that was a step
too far.

s/Modal dialogs/dialogs/

The main focus was that the user must opt-in and applications should get
the choice when (i.e. at app init or on-demand during app execution) and
how (e.g. all features authorised in a single dialog or individual
dialogs per permission) that opt-in is gained from the user. These
requirements are not fundamentally clear in current security proposals
to DAP. A couple of current security proposals dictate when and how
prompting is done (i.e. the policy defines the type of prompting to make
and when to make it). There is more value in saying that opt-in is
required across the board and really it's up to the application to
decide when and how they request permissions from the user.

It's worth clarifying that applications are the request point for
prompting but the actual prompting should be brokered by e.g. the web
browser itself.

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.

The actual model I was considering is the one currently used by alert().
The application can trigger an alert at any point in execution. An
application can also trigger multiple alert() functions. This triggers
the web browser to display the message of the alert() as an actionable
dialog (in this case just an 'OK' button). 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.

> Security designs that reliy on out-of-band preferences being 
> configured by the user, that rely on modal prompts that 
> interrupt the user's workflow, or that rely on users making 
> educated security choices, are all non-starters, in my 
> opinion. They irritate the user, and they are completely 
> ineffective (users click through prompts without reading them).
> 
> Any security prompt might as well just say to the user "Do 
> you want to continue getting your work done? (Yes) (No)". 
> That's all that the user will get from them anyway.
> 

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." - 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. The onus lies with the developer to communicate clearly what
they intend to do with the requested features and convince the user to
opt-in.

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
(again, with the exception of drag-and-drop). 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.


Best Regards,

Richard


[1]
http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0123.html
Received on Friday, 9 October 2009 10:04:12 UTC

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