Re: Policy and browsers (was Re: Policy work items - request for proposals)

I think we roughly ended up in our F2F discussion with something like  
you suggest, two classes of APIs:

1. those with implicit  user consent, eg. api that opens camera  
interface but requires user to press button to take picture, or  
messaging interface that requires pressing "send" etc

2. those that are wholly programmatic, e.g. message sent without out  
user interaction, picture taken without user interaction.

The second class clearly requires policy controls, the first class  
might if decision apart from user's is required or further restriction  
is needed.

regards, Frederick

Frederick Hirsch
Nokia



On Nov 9, 2009, at 11:21 AM, ext Robin Berjon wrote:

> Hi Ian,
>
> On Nov 4, 2009, at 16:27 , Ian Fette (イアンフェッティ) wrote:
>> I'm not really interested or vested in the contacts API. I would be
>> willing to help with use cases for the filesystem API though.
>
> We'd be more than happy for you do so.
>
> In general I think that there may be some amount of people talking
> past one another here. I believe that based on the discussion we had
> at the face to face the intent is to develop:
>
>   - APIs that can be integrated securely in a web browser environment
> without the need for a policy framework; and
>   - a policy framework that could control the usage of the same APIs
> in ways that might lift (or further restrict) said APIs' security
> requirements.
>
> Taking the Contacts API as a simple example, it would be designed in
> such a way that within a web browser, something akin to the following
> would take place:
>
>   - code would call getContacts(successCB, failCB) which is async
>   - the UA would provide a non-modal UI allowing the user to drag
> contacts (or perhaps entire address books — the details don't matter
> here) to the page so as to make them available
>   - successCB would be called with the data provided thusly
>
> That makes for a (simplified) take on this API that can be implemented
> safely in a browser. But now let's look at a widget context, more
> specifically the case in which one wants to write a widget that *is*
> the address book manager for the device. In such a case you don't want
> to have the same security workflow, presumably if you install an app
> to manage your contacts, you want it to have access to them.
>
> In that case the same API would be used (people don't want to reinvent
> the wheel, and even less to have to learn how to spin a new one) but
> presumably some form of policy would allow the above successCB
> callback to be called directly without user intervention.
>
> So, to summarise, my proposal (based on the various things I heard) is
> to have APIs that *by default* are secure in a web browser context,
> but the behaviour of which can be modified by policy in other  
> contexts.
>
> WDYT?
>
> --
> Robin Berjon
>   robineko — hired gun, higher standards
>   http://robineko.com/
>
>
>
>
>

Received on Monday, 9 November 2009 16:28:45 UTC