Describe the permission store using constraints instead of a full model.

[jyasskin]

Here's a third attempt at modeling the permission store, as an alternative to #95, based on @raymeskhoury's suggestions.

This says that each realm has a permission store that's a set of entries for each capability, or a flag saying that capability is denied. The UA gets to ignore writes if it wants and can post tasks to update a realm's store when it "receives new information about the user’s intent", but each particular capability can add constraints on these updates.

Preview at https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/jyasskin/permissions/set-permission-store/index.bs#permission-stores

@alvestrand, this removes the "request a permission" entry point, because it's now straightforward to read and write the current permission store directly. We might want to add a "prompt the user to choose between several options" to match what you're using in getUserMedia() step 7. The old algorithm didn't return a MediaStream anyway as step 8 expects. I think that should be a separate change.

@martinthomson @annevk

Fixes #84 and fixes #86.

[alvestrand]

@jyasskin your PermissionStorageEntry stores permission names. This won't do - it has to store permission descriptions. Otherwise, it's impossible to store "you have permission to access microphone A, but not microphone B".

I didn't read any further than this.

[alvestrand]

A "realm" is a concept I can't remember seeing referenced normatively in a W3C DOM-related spec before. I suspect that you are thinking of something completely specific that links in some way to top level browsing context, but it would be better to say which one you're thinking of.

[jyasskin]

@alvestrand "Permission entries for a PermissionName are instances of that PermissionName's permission entry type, which will be PermissionStorageEntry [which is just a name] or one of its subtypes." It's up to the 'microphone' spec to define what data it needs in order to identify a microphone. You'll be able to look at the Bluetooth spec for how to do this, although it's not updated for this patch yet.

Realms are used in https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects, and increasingly across the whole HTML spec. They're 1-1 with global objects and settings objects, which are per-frame rather than per-top-level-browsing-context. Because not all browsers and permissions work by top-level-browsing-context, I can't tie the base spec to those, but one of the extra constraints the media specs add can be that an iframe's realm should only get permission entries that were added by other realms with the same origin & top-level-origin.

[jyasskin]

Making the UA queue tasks to update the realm's permission store gives a guarantee that it doesn't change within a single turn/microtask checkpoint. However, that's not so valuable since functions like query() and getCurrentLocation() operate in parallel and so could be affected by a task posted while they're executing.

@raymeskhoury has suggested that we fall back to having read and write return completely UA-determined results. I think that's plausible. It would make it harder to write things like "the permission store only changes if the UA receives new information about the user's intent" here, but I think (e.g. in the media capture spec) "the UA must not return cameras entries from 'read the permission store' unless the user has explicitly given permission for the origin to access them" still works.

What do folks think?

[annevk]

Instead of realm, I think it would be better to put this on either the settings object or the global object. Let's leave realms to JavaScript. We only use realms in HTML to define where the settings objects live and where the global object comes from.

[jyasskin]

OK, that's easy. Thanks for the direction @annevk. So you like the rest of the structure? Do you have any other constraints UAs should follow?

[annevk]

It should at least be constrained to origins. Cannot allow new kind of cookies. And ideally we do make it possible for certain permissions to require something more here. E.g., persistent storage isn't really useful without origin-wide permission.

[jyasskin]

After discussion in http://www.w3.org/2016/06/08-webappsec-minutes.html, we're going with #97.