W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 20 Sep 2010 17:43:40 +0200
To: public-device-apis <public-device-apis@w3.org>
Message-ID: <1284997420.2387.5253.camel@localhost>

Following the discussions on the list [1], on the call last week [2] and
per my ACTION-263, I've taken a stab at what used to be called "Device
API Features and Capabilities" and is now available under the title
"Permissions for Device API access":

It defines identifiers for permissions of 5 APIs: geolocation, contacts,
media capture, file, and sysinfo. I've tried to define those based on
current implementations of the APIs (when available) or based on the
security models described in the said APIs.

I've left out on purpose APIs for which our permissions model is not
clearly defined yet (messaging, calendaring, contacts writer to name a

For each of these APIs, I've defined one or more strings (that can be
trivially turned into a URI) that match (in general) permissions to
access a set of methods. I've also described quickly how that permission
is currently implemented (or meant to be implemented) in Web browsers.
These descriptions might benefit from being a bit more formalized, esp.
in the context of describing how these permissions map to widget

I've moved the mapping to BONDI and Android in an appendix, and limited
the mapping to features/permissions that indeed seem to match roughly
what we are proposing.

Things that I have not included but would be logical additions:
* permissions for off-line storage through the manifest attribute in
* permissions for IndexedDB

There are probably more APIs that should be added; Web notifications
should also be part of that list at some point.

I had originally thought that I would also add to the description of
these permissions their meaning in the widgets context (e.g.
"geolocation" means the widget can access getCurrentPosition() without
user prompting). But it looks like the meaning of the <feature> element
in the widgets P&C is not strongly bound to the notion of permissions
("allowed to access") has much as to the notion of capability ("device
provides said API"):
        a feature that is needed by the widget at runtime"

The impact of requesting a given feature on the permissions is
apparently left user-agent dependent. So it probably doesn't make much
sense to add much more on widgets in this document at this sage?

[In Android, there is a distinction made between using a feature
(declared with <uses-feature>) and requesting permission for some of
these features (declared with <uses-permission>):

Anyway, I think the document is now much closer to be in a state for a
FPWD; comments, corrections and suggestions are welcome.


Received on Monday, 20 September 2010 15:43:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:46 UTC