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

For geolocation, there are a number of approaches we could have taken. We
could have had some sort of button that users had to click to provide the
location to the webapp (click a specific button, get a dialog that comes up
asking you what specificity of location you wish to provide and whether to
remember that decision), we could have let the website say "I'm a location
aware site" and put something in the URL bar that the user could interact
with if they wanted to grant location (but not a full infobar / dialog),
etc. We could even have buried it in a menu (page -> provide your location
to this page). There are a number of ways that we could have done it that
would have put the user more in charge, and we might still change our UI to
come more in line with this model but it may break the expectation of
certain apps. We'll have to see.

As for contacts, I think I laid out a relatively concrete strawman of how
this would work.

2009/11/10 Doug Turner <dougt@dougt.org>

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