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

Re: [referrer] Providing safer policy states

From: Jochen Eisinger <eisinger@google.com>
Date: Fri, 08 Apr 2016 04:02:14 +0000
Message-ID: <CALjhuifJGDwNg73Oz1V_K_DG5M2ri_mb=R9AyrnvqybnG32KQA@mail.gmail.com>
To: "Emily Stark (Dunn)" <estark@google.com>, Anne van Kesteren <annevk@annevk.nl>
Cc: Mike West <mkwst@google.com>, Francois Marier <francois@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I'm not sure that we'd necessarily have to change the referrerpolicy
attribute, just because we allow for setting more fancy referrer policies
via the header.

On Thu, Apr 7, 2016 at 8:36 PM Emily Stark (Dunn) <estark@google.com> wrote:

> On Thu, Apr 7, 2016 at 7:25 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> On Fri, Apr 8, 2016 at 12:06 AM, Emily Stark (Dunn) <estark@google.com>
>> wrote:
>> > 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.
>> That doesn't sound great to me. The new syntax is more complicated and
>> this is a feature we just introduced. If we start deprecating it now
>> developers would likely get upset and lose some trust in the platform.
> Just because they have to change referrerpolicy="origin" to
> referrerpolicy="'origin'"? That doesn't seem so burdensome to me. (And in
> Chrome we would follow the normal Blink deprecation process, including
> measuring usage and only removing support when it's low enough.)
> We already removed the CSP referrer directive in
> https://github.com/w3c/webappsec-referrer-policy/pull/14. What's
> different here? Because it's a newer feature?
>> --
>> https://annevankesteren.nl/
Received on Friday, 8 April 2016 04:02:58 UTC

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