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

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

From: イアンフェッティ <ifette@google.com>
Date: Tue, 10 Nov 2009 21:29:01 -0800
Message-ID: <bbeaa26f0911102129i685e63b7ta46304899549f928@mail.gmail.com>
To: Robin Berjon <robin@robineko.com>
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
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.
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
Received on Wednesday, 11 November 2009 05:29:41 UTC

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