Re: Permissions store

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/

Received on Tuesday, 16 August 2016 08:03:40 UTC