- From: Harald Alvestrand <hta@google.com>
- Date: Thu, 2 Jun 2016 08:11:30 +0200
- To: Xiaoqian Wu <xiaoqian@w3.org>
- Cc: Jeffrey Yasskin <jyasskin@google.com>, "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>
- Message-ID: <CAOqqYVEy+-HqDgehz+5zoKROVn3hbPC-qBa-WHnO9JVOoGB4OQ@mail.gmail.com>
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 06:12:20 UTC