Re: VC meeting to discuss Permissions spec

Sure, Jeffrey. 

The WebEx meeting information is here:

Permissions Spec Discussion
11:00 pm  |  PDT | Tuesday, June 7 |  1 hr
8:00 am  |  Berlin | Wednesday, June 8 | 1 hr
4:00 pm  |  Sydney | Wednesday, June 8 |  1 hr
 
Join WebEx meeting
Join: https://mit.webex.com/mit/j.php?MTID=m1521876d6fb50c25cde58ee010fd130c
Meeting number: 640 290 870
Meeting password: webappsec
 
Join by phone
+1-617-324-0000 US Toll Number
Access code: 640 290 870
Mobile Auto Dial:+1-617-324-0000,,,640290870#
 
Add this meeting to your calendar: https://mit.webex.com/mit/j.php?MTID=md7085b200e6ee6006b2a1d9ef2191a1c

Enjoy :)

-xiaoqian


> On 2 Jun 2016, at 7:08 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 
> It looks like the most people can attend on PDT June 7 11PM–12AM,
> Berlin time June 8 8AM–9AM, Sydney time June 8 4PM–5PM.
> Wendy/Xiaoqian, can you set up the WebEx meeting?
> 
> Thanks,
> Jeffrey
> 
> 
> On Thu, May 26, 2016 at 6:11 PM, 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 Thursday, 2 June 2016 01:03:00 UTC