Re: [w3c/permissions] Describe the permission store using constraints instead of a full model. (#96)

>    <p>
> -    To <dfn>get a permission storage identifier</dfn> for a
> -    {{PermissionName}} <var>name</var> and an <a>environment settings
> -    object</a> <var>settings</var>, the UA MUST return a tuple consisting
> -    of:
> +    The UA may initialize <a>realm</a>'s <a>permission store</a> almost
> +    arbitrarily, subject to the constraints in <a
> +    href="#permission-store-constraints"></a>. The UA may also <a>queue a
> +    task</a> to update a <a>realm's</a> <a>permission store</a> almost

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?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/pull/96/files/6d6282b7405265cabec2c0ee30b69877d77d9dff#r63078638