- From: Harald Alvestrand <hta@google.com>
- Date: Fri, 27 May 2016 09:33:11 +0200
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: "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>
- Message-ID: <CAOqqYVFDPGRUZu9XeyuAoHUFxzNM09xWuG02=K0tZidACZcr=g@mail.gmail.com>
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. - 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. - 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.) 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 07:34:00 UTC