Re: Permissions store

Hmm, in my mind we sort of have a store implicitly defined in the spec. The
key is the entire context of the JS call (including permission, origin,
etc.). Setting a value corresponds to "new information about the user’s
intent". This gives the UA a lot of freedom. I think we can define more
constraints on this boundary if we have consensus (such as the origin one).
WDYT?

On Tue, 16 Aug 2016 at 18:03 Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Aug 16, 2016 at 5:18 AM, Raymes Khoury <raymes@google.com> wrote:
> > This constraint turns out to be very difficult to describe in a model.
> The
> > UA needs flexibility to resolve permissions in whatever way it sees best
> for
> > the user. In Chrome, for example, we have enterprise policy which can
> > specify a set of rules which impact how a permission is resolved. This
> can
> > be done more broadly than a per-origin basis. In the end the UA should
> have
> > flexibility to return whatever it wants to allow browsers to experiment
> with
> > permission systems that provide the best experience for the user.
>
> I think you're confusing UX at that point with the underlying model.
> The model is basically working out what the key is. If you have
> something layered on top that can set permissions for several origins
> and such, or wildcarding, that's fine, but that doesn't really affect
> the model.
>
> The model is something like Key + Permission -> State. Where Key
> consists of one or more variables that are obtained in some manner and
> which depend on the Permission. E.g., origin, maybe a session
> identifier, a user-agent-defined bit, etc. Again, for storage that'd
> just be origin.
>
>
> > With that said, I think there is general consensus that changes to the
> state
> > of a permission which are triggered by a website (e.g. through request(),
> > revoke(), getUserMedia(), etc.) should only impact the permission state
> for
> > the current origin and not more broadly. I think we can probably describe
> > this constraint in the spec without needing to formulate a detailed
> model.
>
> That is all the model needs to account for really since everything
> else is UX and largely outside the scope of standards. Web standards
> only deal in what is observable by the web.
>
>
> --
> https://annevankesteren.nl/
>