Re: JavaScript Permissions interface in WebApps

Maybe I'm missing something, but it seems that there's two distinct
interests here.

The first interest is in expressing policies. There has been a history of
talk in DAP about the ability to specify policies for access to various
devices/resources/APIs. From a web developer perspective, the policy threads
boil down to the question of "what is the result when a various site tries
to do something? Is it allowed, is it denied, or is it unknown [ e.g. ask
the user ]." How that decision is made seems orthogonal to the question of
"what will happen if I try to do XYZ" - whatever mechanism you are using
(hardcoded defaults, a policy you consult, etc) you should be able to answer
that question.

The second interest is the answer to the question "what is the effect of the
policy being used" - and here I use "policy" in a loose sense. A developer
shouldn't have to care what policy the user has set, rather the question is
"can I use this API, and if not, can I successfully get permission to use
it?"

It seems that we should be able to de-couple discussion of the second from
the first.

-Ian

On Wed, Jun 30, 2010 at 6:36 AM, <Frederick.Hirsch@nokia.com> wrote:

> Hi Doug
>
> > Lastly, it will be very hard to implement anything that does the
> following:
>
> The following paper might be relevant, have you looked at it yet? This
> seems to offer some additional information.
>
> http://escholarship.org/uc/item/0rp834wf
>
> I understand there are pragmatic concerns - yet can we do more to find a
> good balance? supporting rulesets may be a possibility  - we'll have to talk
> about it at the workshop
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Jun 29, 2010, at 4:42 PM, ext Doug Turner wrote:
>
> > 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/
> >>
> >>
> >>
> >>
> >
>
>
>