W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2016

Re: Permissions store

From: Raymes Khoury <raymes@google.com>
Date: Wed, 17 Aug 2016 01:55:36 +0000
Message-ID: <CAEYdGOW_vSpWmNc3JM5-bNUB2PKqBy10P63+8G3TuTwFrLd5Mw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Jeffrey Yasskin <jyasskin@google.com>, WebAppSec WG <public-webappsec@w3.org>, Martin Thomson <mt@mozilla.com>, Marcos Caceres <marcos@marcosc.com>, Mounir Lamouri <mlamouri@google.com>, Ben Wells <benwells@google.com>
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).

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/
Received on Wednesday, 17 August 2016 01:56:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC