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


> -----Original Message-----
> From: 
> [] On Behalf Of 
> Peter-Paul Koch
> Sent: 07 October 2009 23:29
> To: Brian LeRoux
> Cc: Device APIs and Policy Working Group WG
> Subject: Re: ISSUE-28: [Policy] Requirement for NO security 
> prompting [Security Policy Framework - General]
> > Rather than runtime dialogues, which do create a *terrible* user 
> > experience, can we consider a one time startup dialogue (similar to 
> > what is seen in android applications) that warns the user 
> about what 
> > apis the application wants access to.
> I'm afraid some kind of runtime check and dialogue is inevitable.

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).

As and when that opt-in is required/requested could however be
outsourced as a design decision. Imagine that the developer can decide
what kind of prompting works best for their application and we don't
dictate when, or how many prompts are required - only that opt-in must
be gained to access Device APIs through all the necessary permissions
and features. 

This is fundamentally different to a dictated policy that requires
particular prompting at particular times when particular API features
are requested. Instead we allow developers to trigger modal dialogs in
any configuration they like for as many permissions as they need or want
to request, when they want or need to request them.

Some example design approaches developers may then adopt include:

- Request all permissions up front at application startup (multiple
permissions confirmed in a single modal dialog).
- Request individual permissions on demand at runtime (single or
multiple permissions confirmed in multiple modal dialogs)
- Request a core set of permissions up front and then request edge-case
permissions as and when required at runtime.

The key here being that rather than force developers to do one
particular thing, we could leave it open but ensure that we have the
necessary framework to allow developers to request a modal dialog in any
configuration they please.

> But yes, runtime dialogues are horrible. It's just that I 
> haven't heard any better ideas so far, so it seems we're 
> stuck with them - for the moment.
> Unless we say that (nearly) all device API calls have to 
> function asynchronously, as the Mozilla paper suggests. But 
> this would significantly change the flow of an application, 
> and maybe require a different kind of programming than just 
> normal web-JavaScript.

The alternative is to make the opt-in to features and permissions
asynchronous and keep the rest of the APIs, that will hang off
permission callbacks, open to either synchronous or asynchronous

I want to highlight the Facebook Javascript Client Library [1] approach
to requesting features and permissions [2].

In terms of Facebook terminology:

- a 'feature' is a state-machine like way to monitor the progress of
facebook connect setup [3]. Generally features relate to an accompanying
JS in Facebook Connect, requiring a feature is essentially
'ensure that everything has loaded correctly, that I have a path to the
Facebook API, that I have a cross-domain communications channel setup,
that the application is authorised to access the Facebook API and that
we are connected to the Facebook API service end-point'.

- a 'permission' is equivalent to the concept of 'feature' in BONDI: a
generic name that is used to govern access to a defined range of API
methods. A permission is requested via modal dialog [4]. Multiple
permissions [5] can be sent to a single modal dialog using
comma-seperated values. Requesting a modal dialog is an asynchronous
process and a callback is specified when the user has completed the
dialog process, allowing any code hanging off or waiting for the
authorisation to execute either synchronously or asynchronously

So some implementing permission requests in the Facebook Jaascript
Client Library can look like this:

FB.ensureInit(function() { 
				      // ask the user for email
FB.Connect.showPermissionDialog("email", callbackFunc); 

Or this:

FB.ensureInit(function() { 
				      // ask the user for email and sms
FB.Connect.showPermissionDialog("email,sms", callbackFunc); 

Or this:

FB.ensureInit(function() { 
				      // ask the user for email
FB.Connect.showPermissionDialog("email", callbackFunc); 
				      // then ask the user for sms
FB.Connect.showPermissionDialog("sms", callbackFunc); 

Such a model allows for the developer to a.) request permissions as and
when it makes sense for their application, and b.) request permissions
one time or multiple times throughout the execution of their

One additional point is that the Facebook Javascript Client Library does
not have any concept of one-shot or permananent permission
authorisation. It only allows for session-based permission acceptance.
All permissions granted are available for the duration of the users
session with that application.

Another key distinction made in the Facebook Javascript Client Library
is the concept that initially the application must authenticate and then
the user must authenticate. This, I'm sure, provides Facebook with a
very good way to monitor any malicious activity and pin it to either a
specific application or a specific user.

Overall, the Facebook Javascript Client Library is particularly
interesting in a number of areas related to this discussion. I just
wanted to share that info and perhaps it sheds light on our discussion
and gives it new perspective. Perhaps it may be worth looking in to this
particular implementation further and potentially adopting some of its
general concepts.

Best Regards,






Received on Thursday, 8 October 2009 11:07:43 UTC