W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2016

Re: VC meeting to discuss Permissions spec

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Thu, 2 Jun 2016 10:23:41 -0700
Message-ID: <CANh-dXm710Q=-PhV6+JcBvTibWZwr0Y-2Y7AAfmy_vCvohwuww@mail.gmail.com>
To: Harald Alvestrand <hta@google.com>
Cc: Xiaoqian Wu <xiaoqian@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jan-Ivar Bruaroey <jib@mozilla.com>, Ilya Grigorik <igrigorik@google.com>, Raymes Khoury <raymes@google.com>, Mounir Lamouri <mlamouri@google.com>, Anne van Kesteren <annevk@annevk.nl>, Martin Thomson <mt@mozilla.com>, Marcos Caceres <marcos@marcosc.com>, Wendy Seltzer <wseltzer@w3.org>
Thanks Xiaoqian!

I'll have Hangouts dial into the WebEx, so it'll be audio-only between the
two, but you can use either. I'll be on the Hangout.

On Wed, Jun 1, 2016 at 11:11 PM, Harald Alvestrand <hta@google.com> wrote:

> The time works for me. Thanks!
>
> Are we doing webex, hangouts or both?
>
>
> On Thu, Jun 2, 2016 at 3:02 AM, Xiaoqian Wu <xiaoqian@w3.org> wrote:
>
>> 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 17:24:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:20 UTC