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

Le lundi 20 septembre 2010 à 17:13 -0500, Suresh Chitturi a écrit :
> I wonder if there should be identifiers at the API level e.g. 'file'
> would indicate access to the entire File API i.e. read and write,
> 'contacts' would indicate access to the entire Contacts API and so on,
> in addition to the granular per operation access identifiers similar
> to 'geolocation' where it provides access to both getCurrentPosition()
> and watchPosition() methods.

My current approach is to have one identifier matching one permission
request in the browser — that's why geolocation covers both
getCurrentPosition() and watchPosition().

We could easily build groups of permissions as you allude to, but until
there is a clear use case for it, I would rather abstain from adding
arbitrary groups.

>  This to me would make sense if one wanted to provide blanket-type of
> access to the entire API without worrying too much about the detail
> operations inside a particular API.

I think the number of current names is low enough that naming individual
permissions shouldn't be too much of a worry :)

> Since the <feature> element is linked into this document, would it
> make sense to also bring in the WARP <access> element to address the
> domain aspect? I think so.

One of the big differences of network-based permissions with the other
currently defined permissions is that this one would require
parametrization (e.g. the allowed domain names). Also, that permission
in the browser world is granted by the third-party domain (using CORS),
not by the user.

I'm not quite sure how this would be integrated as a result; would you
mind making a draft proposal that we could look into adding to the
document?

Dom

Received on Tuesday, 21 September 2010 07:54:12 UTC