W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: [Referrer] Adding a referrer attribute delivery mechanism

From: Brian Smith <brian@briansmith.org>
Date: Fri, 13 Feb 2015 11:33:35 -0800
Message-ID: <CAFewVt7zp99j5uOUH=ibQcjyEhiriGf_V2wx6zXyp2NhoAah-Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Francois Marier <francois@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Martin Thomson <martin.thomson@gmail.com> wrote:
> On 12 February 2015 at 17:35, Brian Smith <brian@briansmith.org> wrote:
>> So, it doesn't matter
>> whether rel=noreferrer takes precedence or we take the lower of both
>> values, because both result in "none".
> I actually think that given referrer=foo is newer and written with
> full knowledge of the rel=noreferrer option we could interpret <a
> rel=noreferrer referrer=origin> as an intent to share the origin, but
> no more than that.  A UA that doesn't support the new argument would
> fail closed, but that would be intentional.

I disagree. When we have two security-sensitive directives that
conflict with each other, it's better to take the more conservative
choice in case the conflicting directives are due to user error, e.g.
due to conflicting modules in a web framework. The page can install a
click event handler to remove the rel=noreferrer if the referrer
attribute is present, if they want the semantics you describe.

> It seems like the right thing to do would be to remove rel=noreferrer
> eventually, so being able to ignore it is easier than describing a
> combination rule, or any rule where it takes precedence.  Both make it
> harder to have it disappear.

I don't see removing rel=noreferrer to be a high priority or something
that will get doable any time soon. It's even in W3C HTML5.

Received on Friday, 13 February 2015 19:34:02 UTC

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