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: Tue, 29 Jun 2010 13:42:13 -0700
Cc: "Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, Dominique Hazael-Massieux <dom@w3.org>, W3C Device APIs and Policy WG <public-device-apis@w3.org>, John Gregg <johnnyg@google.com>
Message-Id: <22122AE8-C6E8-4529-8B5D-CE87E2ABB2EB@dougt.org>
To: Robin Berjon <robin@robineko.com>
Hey Robin,

I would love to build a draft doc, but really... we should ask John Gregg.  He is the editor of the Desktop Notification and he is to "blame" for the bulk of this API.  John, would you like to factor this out and propose it as a separate spec?


Also, I am not really interested in options for this specification.  If we have to spec out additional things, we can do that in the future.


Lastly, it will be very hard to implement anything that does the following:

{ retain: "briefly", distribute: false }

This is basically the same idea the the CDT/GeoPriv folks wanted in the Geolocation WG.  This wont work from the UAs point of view for many reasons.  Before you consider rehashing the debate on this thread, I urge you to you can check out the Geolocation WG meeting notes from the Dec. Face-to-Face for the details.

Regards,
Doug Turner



On Jun 29, 2010, at 2:46 AM, Robin Berjon wrote:

> Hey Doug,
> 
> On Jun 28, 2010, at 23:31 , Doug Turner wrote:
>> The unknown case would most likely bring up a UI in Firefox.  The other states talk about if an application is allowed to use a particular feature.  checkPermission could return 'false' stating that the application is not allowed to preform some action... maybe because the user has previously disabled this feature (like opt'd out of gelocation).  Maybe these we previously set by the user, maybe they are just defaults in the UA.... but how they got set is really an implementation detail.
> 
> As I've said before, I think that this could be an interesting avenue of work. Out of curiosity: would you be interested in scaring up a draft?
> 
> I also wonder if there could be value in adding an options argument to allow one to provide more information about the check. For instance, as you probably recall, there was a discussion not so long ago about quotas for permanent and temporary storage. I wonder if this could not be done through this interface as well with something like checkPermission("permanent-storage", { size: "all-your-teras" }).
> 
> With options, it might be possible to provide some privacy terms (perhaps based on our rulesets, or Aza's "essential things, or whatever comes out of next month's workshop). Something like checkPermission("contacts", { retain: "briefly", distribute: false }).
> 
> Another thing: if it's just checking for permission, the method can I guess be synchronous. But we could add a third argument being a callback that would make it actually request the permission (or it could be a separate method, as proposed before). In that case, the callback could get an object implementing the interface that it's looking for. This would avoid namespace pollution on navigator (or wherever else most of these APIs end up being stuck) as well as a fair amount of bikeshedding.
> 
> I'm not saying all or in fact any of this is a good idea  just sticking it out there :)
> 
> --
> Robin Berjon
>  robineko  hired gun, higher standards
>  http://robineko.com/
> 
> 
> 
> 
Received on Tuesday, 29 June 2010 20:42:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT