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

Re: [referrer] Providing safer policy states

From: Emily Stark (Dunn) <estark@google.com>
Date: Thu, 7 Apr 2016 15:06:08 -0700
Message-ID: <CAPP_2SYyMECWyYu6ddEuBnw1g6J1PyQqj4qZB0L5Aj+btCx5eA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mike West <mkwst@google.com>, Francois Marier <francois@mozilla.com>, Jochen Eisinger <eisinger@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Apr 6, 2016 at 11:43 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Apr 6, 2016 at 10:26 PM, Emily Stark (Dunn) <estark@google.com>
> wrote:
> > On Tue, Apr 5, 2016 at 11:51 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> How would you transition the Fetch API and HTML referrerpolicy
> attribute?
> >
> > Are there specific aspects of this or concerns that you're thinking
> about?
>
> Backwards compatibility, mostly. Not entirely sure what JSON or enum
> would be either for the API.
>
>
> > One idea that had been thrown around is to always have referrer policies
> be
> > quoted strings, so that they always parse as JSON. I'm not sure if that's
> > what you're asking about though.
>
> You mean requiring referrerpolicy=" 'origin' "? What would happen to
> referrerpolicy=origin?
>

I was thinking maybe we could deprecate the latter (continue to support it
for a while, maybe with a console warning, and eventually drop support).
When parsing a referrer policy, we could first check if it matches one of
the enum values, and if not, then parse it as JSON. If it neither matches
an enum value nor parses as JSON, then we just ignore it.


>
>
> --
> https://annevankesteren.nl/
>
Received on Thursday, 7 April 2016 22:06:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:19 UTC