Re: JavaScript Permissions interface in WebApps

Doug

Yes I think your message does help indeed.

I think we are talking about something completely different!

I *think* what you are saying is, an app would like to know whether a given feature requires a user dialog, it can use checkPermission to find out. If checkPermission returns TRUE then a user dialog is needed for the feature, otherwise not.

I'm looking at a different point of view, saying if an app wants to use geolocation for example,  it will either be allowed to or not (perhaps via permissions that do not require user interaction). Thus when attempting to call that method, it might be denied (thus the browser in  this case acts as a policy enforcement point, and how the decision is reached is a policy decision).

Thus I was thinking that checkPermission would return whether or not the application is allowed to perform the method. This is different than returning an indication of whether the UI will interact with the user for permission.

Do I have the distinction correct?

> It would be useful if a website would know if firefox would bring up a UI before invoking either of these features

If so, how is checkPermission useful to an application, since if it needs a feature, well, it needs it... How is it useful for a website to know?

(Rather than calling it checkPermission, requiresUserConsent might be clearer.)

regards, Frederick

Frederick Hirsch
Nokia



On Jun 28, 2010, at 4:58 PM, ext Doug Turner wrote:

> 
> 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!
> 
> Doug

Received on Monday, 28 June 2010 21:17:54 UTC