Re: VC meeting to discuss Permissions spec

I've added some more Europe-friendly times, including some 11pm PDT
slots that work for both Australia and Europe. Several Chrome folks
will be in Munich June 13, so I've also added an option that day.

On Fri, May 27, 2016 at 12:33 AM, Harald Alvestrand <hta@google.com> wrote:
> .... and if you can expand the doodle with some more Europe-friendly time,
> I'd be very happy ....
>
>
> On Fri, May 27, 2016 at 9:33 AM, Harald Alvestrand <hta@google.com> wrote:
>>
>> Thanks for writing all these up!
>>
>> From the descritption in your mail:
>>
>> - the critical point on 95 is probably not so much when stores are
>> created, but when they are destroyed.

Nothing says a store is destroyed in #95, but a realm store would stop
being used when its global object is gc'ed. Whether permissions
granted to the realm persist depends on whether they were also written
to an origin store in
https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/jyasskin/permissions/multiple-stores/index.bs#create-a-permission-storage-entry.

>> - 97 seems like "do what I mean". If adopted, it means that each UA must
>> design its storage model on its own, and consistency goes out the window.
>> Not happy with that.

For 95 and 96 too, we have to allow UAs to remove permissions at any
time (for user revocation), grant them from enterprise policy at any
time, apply them to less than a whole origin (for temporary
permissions), and even do some cross-origin grants (for permission
delegation). The models wind up allowing basically the same freedom as
97, but they disguise it instead of being up front about it.

One important thing to try to discover in this meeting is whether
there are particular behaviors that we want to say are out of bounds,
even if a browser thinks that's what its users wanted. If a model
makes those things hard to express, that's a point against that model.

>> - I don't get what you mean by calling the camera permission a "feature".
>> Care to explain further?
>> (In my mind, the "feature" is all of the aspects of camera management;
>> permission is only one small part of it, and the only one I want to have the
>> permissions spec say anything about.)

The permissions spec covers whether script has permission to access a
feature. "camera" doesn't really name that permission -- it names the
feature. That said, terminology here is hard and still up in the air,
and we can pick the model to apply before we've totally nailed down
what words to use for it.

Thanks,
Jeffrey

>> On Fri, May 27, 2016 at 3:11 AM, Jeffrey Yasskin <jyasskin@google.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> I've been updating the Permissions spec to improve its support for
>>> complex permissions like Bluetooth, for temporary grants as seen in
>>> Safari and Firefox, and for UA innovation.
>>>
>>> https://docs.google.com/document/d/1_YTpXijrkKNlmSlpA0fEwc5WMmZvRvdTRwF81g_gndk/edit
>>> surveys the existing practice with permissions and describes some
>>> tricky aspects of various future plans. I've proposed 3 fairly
>>> different models, and I think it's surpassed everyone's ability to
>>> investigate them enough to develop a preference.
>>>
>>> So I'd like to schedule a meeting with interested folks some time in
>>> the next 2 weeks so that we can all focus enough to pick one of the
>>> models.
>>>
>>> What times work for people? Please fill out
>>> http://doodle.com/poll/e2r74364qzkmxga9 to express a preference. We
>>> can meet via
>>> https://talkgadget.google.com/hangouts/_/google.com/permissionsspec.
>>>
>>> The models I've written up are:
>>>
>>> * https://github.com/w3c/permissions/pull/95: Each feature defines a
>>> storage type, and permission stores store it. The UA doesn't need any
>>> permission stores, but if it has them, it needs one per global object,
>>> probably plus one per origin, and can save grants to multiple stores
>>> and initialize new stores pretty freely. This version also needs
>>> https://github.com/w3c/permissions/pull/91 to let other specs modify
>>> their storage types appropriately.
>>>
>>> * https://github.com/w3c/permissions/pull/96: Defines a permission
>>> store for each global object, but leaves it up to the UA how those are
>>> created. Stores hold a collection of entries for each feature, rather
>>> than a unified "storage" type, which helps with granting access to
>>> discrete devices. This spec spends some words requiring that
>>> permission changes only happen on event loop turn boundaries, but
>>> that's not very useful to developers since every algorithm using
>>> permissions runs 'in parallel'.
>>>
>>> * https://github.com/w3c/permissions/pull/97: Feature specs use
>>> "descriptor's permission state" and "descriptor's extra permission
>>> data" to read the UA's notion of the user's intent, but there's no
>>> model of the UA's storage. Individual permissions can add constraints:
>>> for example, "camera" and "microphone" require that iframes without
>>> the allowusermedia attribute return "denied". This option treats
>>> permission the most like UI, which we traditionally don't specify.
>>>
>>> #97 was written last, so it also includes some other improvements,
>>> like calling things like "camera" features instead of permissions, and
>>> defining algorithms for other specs to use to show permission prompts.
>>> I'll port those to whichever version we pick if you like them.
>>>
>>> Please let me know when you're free to talk, and give the options some
>>> thought ahead of the meeting, and hopefully we can settle on something
>>> lots of specs can use.
>>>
>>> Thanks,
>>> Jeffrey
>>
>>
>

Received on Friday, 27 May 2016 20:53:45 UTC