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

Re: JavaScript Permissions interface in WebApps

From: Doug Turner <dougt@dougt.org>
Date: Mon, 28 Jun 2010 13:58:50 -0700
Cc: <dom@w3.org>, <public-device-apis@w3.org>
Message-Id: <99420E33-4B32-4778-B9D1-55DF4D22C719@dougt.org>
To: <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com>

On Jun 28, 2010, at 1:38 PM, <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com> wrote:

> Thanks Dom.
> Is the first argument is what we've been calling a "capability"?

Maybe?  The two examples are "geolocation" and "desktop-notification".  Thinking as a firefox developer, these are two features that require user permission prior to use.  It would be useful if a website would know if firefox would bring up a UI before invoking either of these features.

The point of this interface would be to test and acquire that permission without invoking the actual feature.

> It looks like "checkPermission" then is requesting a Policy Decision, so behind this call could be a variety of choices of policy decision evaluators, one of which could be along the lines of the XACML-like policy rules and evaluation engine.
> Thus it seems we still need to define capabilities and ability to express policy rules.

I did not understand any of the above text.

> What is proposed however, is a means to "mix in" an interface to request such decisions to any API, is that right?

Not exactly.  The basic use case is that a web application might want to know if invoking a given API will change the UI of the UA.

> What happens if an application does not ask permission, but just calls an API with this approach in place?

No change to what happens today.

I hope this helps!

Received on Monday, 28 June 2010 20:59:25 UTC

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