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

If we exclusively consider the geolocation case, what sort of ways would you consider work for you while allowing the user to remain in control of sharing their position with web applications?  It seems like the strawman you put together doesn't have any real solution, or I must be completely missing something.

Sorry if this was discussed at the TPAC.

Doug Turner

On Nov 10, 2009, at 9:29 PM, Ian Fette (イアンフェッティ) wrote:

> In general, we have little desire to implement APIs where a webpage can do something that then throws up an infobar / dialog / question of any sort to the user. It gets annoying. Even the current geolocation API is annoying (every time i go to google.com on my mobile phone it asks if i want to enable geolocation. I do not. Now I have geolocation disabled entirely so I don't get that question.)
> 
> Something like <input type=contact>, which had a button and some associated display, would mean that a website couldn't do something to annoy me or cause popup dialogs to happen.
> 
> This is why I think it's insane to try to talk about policy and API design separately. We have no interest in APIs that are wholly programmatic and require some policy layer.
> 
> 2009/11/9 Robin Berjon <robin@robineko.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 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/
> 
> 
> 
> 
> 

Doug Turner
dougt@dougt.org

Received on Wednesday, 11 November 2009 21:15:51 UTC