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

Re: Permissions store

From: Raymes Khoury <raymes@google.com>
Date: Tue, 16 Aug 2016 03:18:03 +0000
Message-ID: <CAEYdGOX8YZNfmxiSpz8Sdvn=N7MvsUx3xi5oLH1_ONXSLFGn=A@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@google.com>, WebAppSec WG <public-webappsec@w3.org>
Cc: Martin Thomson <mt@mozilla.com>, Marcos Caceres <marcos@marcosc.com>, Mounir Lamouri <mlamouri@google.com>, Ben Wells <benwells@google.com>, Anne van Kesteren <annevk@annevk.nl>
Hi Anne,

Jeffrey made several attempts at trying to write down a model that allows
UA flexibility while enforcing the constraints that we want to be in the
spec. The end result turned out to be complex and confusing and didn't
provide any real guarantees.

> But I think we want all permissions to be at least keyed by origin

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.

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.


On Wed, 10 Aug 2016 at 02:01 Jeffrey Yasskin <jyasskin@google.com> wrote:

> Thanks Anne.
> For context, the minutes for the previous meeting on this are at
> https://www.w3.org/2016/06/08-webappsec-minutes.html.
> As one of the Permissions editors, I'd like to request that, if this
> discussion decides to change the model, y'all should produce a
> document that describes it in a more contained form than an email
> thread, and then I'll edit that into the spec. Or a PR would be fine
> if you're ambitious. You could base a model on my previous attempts at
> https://github.com/w3c/permissions/pull/95 and
> https://github.com/w3c/permissions/pull/96, or build your own.
> Thanks,
> Jeffrey
> On Tue, Aug 9, 2016 at 2:26 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > Apparently the latest agreement for the Permissions specification is
> > that each permission has a "get" and "request" API and the details of
> > those operations are up to the user agent.
> >
> > That does not seem great.
> >
> > I understand that we might want to vary on the key and even leave some
> > things user-agent defined. But I think we want all permissions to be
> > at least keyed by origin. And some permissions, such as storage,
> > should only be keyed by origin and not some additional bits that are
> > up to the user agent.
> >
> > (Of course, if user agents provide ways to have multiple user agents
> > in a user agent, as with Firefox Container Tabs, that would be an
> > additional part to the key. As would private browsing mode, but
> > nothing else that is keyed by origin is concerned with those modes, so
> > we shouldn't be concerned with it here either, until we expose
> > features that make those modes visible to the web.)
> >
> > So I'd like to revisit that agreement and actually get us to clearly
> > specify the store, including the bits that are user-agent defined,
> > which is likely something that is decided upon on a per-API basis. The
> > scope for persistent storage is not necessarily applicable to sharing
> > the camera, but leaving both openended is not a good solution either.
> >
> > (It also seems rather bogus architecturally to leave such an important
> > subsystem entirely up to the user agent and not describe its details.
> > That will surely bite us later on.)
> >
> >
> > --
> > https://annevankesteren.nl/
Received on Tuesday, 16 August 2016 03:18:43 UTC

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