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

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

From: Robin Berjon <robin@robineko.com>
Date: Mon, 9 Nov 2009 17:21:24 +0100
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Message-Id: <82DBB2DB-16EE-4EC8-8764-F1D44F15192D@robineko.com>
To: ifette@google.com
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  

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.


Robin Berjon
   robineko — hired gun, higher standards
Received on Monday, 9 November 2009 16:22:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC