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: Andrei Popescu <andreip@google.com>
Date: Wed, 11 Nov 2009 10:52:38 -0800
Message-ID: <708552fb0911111052g12574093y45317421d12d66eb@mail.gmail.com>
To: ifette@google.com
Cc: Doug Turner <dougt@dougt.org>, Robin Berjon <robin@robineko.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Hi Ian,

2009/11/11 Ian Fette (イアンフェッティ) <ifette@google.com>:
> Doug,
> I wasn't trying to imply that W3C should mandate user interface. But certain
> APIs lend themselves to certain experiences. <input type="file"> would be
> very different if it were instead a GetFile() call.

I fully agree with you here: you give a very good reason why the
security mechanisms should not be designed in isolation from the
actual APIs. I just wanted to make it clear that in the Geolocation
WG, we considered these aspects together and, as far as I can tell,
made the right choices:

Geolocation is a programatic API given its intended usage (i.e. the
use cases we have for it). We have a number of applications (e.g.
Google search) where it is not desirable to force the users to always
have to hit a button every time their location should be used for
something (e.g. annotate the search query). So something like <input
type="geolocation"> would not have been a good fit, unless we changed
the way the input tag works (which is not desirable, either IMHO).

Having made the choice of designing Geolocation as a programatic API,
we next made sure that any security mechanism built around it can lend
itself to a user experience that is as unobtrusive as possible. This
is one reason why we made the API fully async: to allow non-modal UI
(infobar / icon in URL bar / menu option / etc).

On the other hand, for something like a Contacts API, if most use
cases are around the user picking a subset of his contacts and
interacting with them somehow (editing / sending them a message / etc)
then I could see the API being built using the <input> tag, as you
suggested. However, there are issues with building a security
mechanism around the <input> tag, as well (e.g. will the element be
stylable, etc).

> My hope is that we have
> in mind at least one user experience that we would actually be comfortable
> shipping that matches the API, rather than just saying "eeh, don't worry
> about it, some policy layer will handle it, and if there's no policy we can
> fall back to a dialog box." That is not acceptable.

Yep, I feel the same way about this.

Received on Wednesday, 11 November 2009 18:53:19 UTC

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