VC meeting to discuss Permissions spec

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 01:11:49 UTC