- From: Robin Berjon <robin@robineko.com>
- Date: Mon, 9 Nov 2009 17:21:24 +0100
- To: ifette@google.com
- Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
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:22:03 UTC