Re: JavaScript Permissions interface in WebApps

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/
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>
>>
>
>