Re: JavaScript Permissions interface in WebApps

Thinking of how this came to be (refactored out of the notifications
permission spec), the point of the current proposal is to provide a
consistent permissions interface for some well known feature APIs that need
permissions, not a completely generic system.

The list might expand in the future, but for now the set of valid parameters
can be explicitly enumerated through the spec process and there would still
be a lot of value as an initial offering.

 -John

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

> How will you avoid collisions if we also allow private APIs to also use
> such a mechanism? Will there be a registry of names? Wouldn't URIs enable a
> distributed decentralized identification mechanism?
>
> Thinking further ahead, could such URIs have information related to them,
> perhaps via retrieval, perhaps with semantic web type technologies (not to
> rathole here, but to suggest treating them as URIs opens other
> possibilities)
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Jun 30, 2010, at 12:21 PM, ext Doug Turner wrote:
>
> > Not really.  why would that be better in practice?
> >
> >
> > On Jun 30, 2010, at 9:19 AM, <Frederick.Hirsch@nokia.com> <
> Frederick.Hirsch@nokia.com> wrote:
> >
> >> Yes, this is what I looked at before. Have you considered URI's instead
> of strings, e.g. instead of 'geolocation' using a URI?
> >>
> >> regards, Frederick
> >>
> >> Frederick Hirsch
> >> Nokia
> >>
> >>
> >>
> >> On Jun 30, 2010, at 12:06 PM, ext Ian Fette (イアンフェッティ) wrote:
> >>
> >>> The thread where this is being discussed is
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1150.html -
> i would look there for more info
> >>>
> >>> On Wed, Jun 30, 2010 at 9:03 AM, <Frederick.Hirsch@nokia.com> wrote:
> >>> Ian
> >>>
> >>> Thanks for the very clear and helpful explanation.
> >>>
> >>> I think some of this is similar in intent to some of the other
> proposals in DAP.
> >>>
> >>> Where and how do you plan to define items that have permissions
> associated with them? For example, is there a URI for "obtaining user
> location" and where is this defined? (I guess I'm asking if you have a more
> detailed spec).
> >>>
> >>> If I missed this in a thread or elsewhere, a link would be helpful.
> >>>
> >>> regards, Frederick
> >>>
> >>> Frederick Hirsch
> >>> Nokia
> >>>
> >>>
> >>>
> >>> On Jun 30, 2010, at 11:52 AM, ext Ian Fette (イアンフェッティ) wrote:
> >>>
> >>>> On Wed, Jun 30, 2010 at 8:31 AM, <Frederick.Hirsch@nokia.com> wrote:
> >>>> Ian
> >>>>
> >>>> Good point, I agree.
> >>>>
> >>>> Policy decision is a separable aspect that determines how a decision
> is reached, either by user query, rules, whatever.
> >>>>
> >>>> Then you have a running app. Now it seems that ultimately an app tries
> to call a method, which then the OS/browser/etc enforces a decision of
> whether the invocation is allowed.
> >>>>
> >>>> What isn't clear to me is that I think you might be suggesting another
> approach which is for the app to ask if permissions are granted, and then
> only invoke the method if they are.
> >>>>
> >>>> This has the advantage of enabling bundling various permission
> requests, reducing user interaction in the case of many requests. However it
> does  no enforcement, so if the app ignores the decision (a bad app) then
> the OS/browser/etc still needs to know the result of the policy decision and
> enforce it before allowing the method to proceed.
> >>>>
> >>>>
> >>>> This is correct, it does allow bundling of various permissions
> requests, but does not do any "enforcement". Rather, it simply tells
> developers what is _going_ to happen, and if they are unhappy with that
> (e.g. they get back an "unknown" instead of an "allowed") they can
> potentially try to request a permission (or set of permissions) and see if
> the state of the world changes, e.g. unknowns become allows. This allows an
> application developer to ensure that they have whatever baseline set of
> capabilities they require, rather than finding that out half-way in (and
> after generating N different prompts to the user.)
> >>>>
> >>>> Are you thinking in terms of an app asking permission, or of receiving
> capability tokens, or simply enforcement at the methods?
> >>>>
> >>>>
> >>>> I am not proposing changing any of the enforcement mechanisms, e.g.
> adding some token. Rather, the browser continues to apply its decision
> making process / policy as normal, but the app can get the result ahead of
> actually using the API, and if the app requests a permission and this has
> some effect (e.g. a prompt to the user which the user interacts with,
> implementation dependent, but imagine the user saying "yes, I will allow
> this site to access my location" and the browser remembering that decision),
> then the result is changed, even though the mechanism is not.
> >>>>
> >>>> It would help me to understand the model you have in mind, in terms of
> the flow. Perhaps it is in an email I missed, if so I apologize.
> >>>>
> >>>> Two examples:
> >>>>
> >>>> The original proposal was with respect to geolocation. Imagine I'm
> google maps. I have a "show my location button". I want to know if it makes
> sense to even show this button. Right now, the only thing I can do is call
> the geolocation API and attempt to get the location. In most cases, this
> will generate some user prompt - but I don't actually want the user's
> location or to annoy the user with a prompt, rather I just want to know *if
> I can get it* so that I know whether to show the button or not. If I can
> call checkPermission() then I can hide the button if the response is "deny",
> or show the button if the response is "unknown". If the response is "allow",
> I might instead just go ahead and get the permission, and have a "turn off
> location" button instead.
> >>>>
> >>>> Now, imagine being able to get more permissions. E.g. I'm a mail app,
> and the user says they want to turn on offline mail access. I know I need
> more quota, but I want to request it upfront. I might also need other
> permissions, e.g. filesystem API persistent storage, and something else. I
> can use requestPermission() to get all of these permissions up front, rather
> than having to try storing whatever data I  can until I hit some unknown
> quota and then "seeing what happens". Granted, the original proposal doesn't
> quite go this far in terms of what permissions were being considered, but I
> think it may allow for such things eventually.
> >>>>
> >>>>
> >>>> This seems to be related to  checkPermission/requestPermission
> >>>>
> >>>> I'd like to better understand what you have in mind to see how it fits
> with what the DAP WG has been discussing.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> regards, Frederick
> >>>>
> >>>> Frederick Hirsch
> >>>> Nokia
> >>>>
> >>>>
> >>>>
> >>>> On Jun 30, 2010, at 10:20 AM, ext Ian Fette (イアンフェッティ) wrote:
> >>>>
> >>>>> 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/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>