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

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/
>
>
>
>
>