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

Re: [Referrer] Adding a referrer attribute delivery mechanism

From: Scott Beardsley <sbeards@yahoo-inc.com>
Date: Mon, 23 Mar 2015 17:37:28 +0000 (UTC)
To: Sid Stamm <sid@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <902822081.1007032.1427132248980.JavaMail.yahoo@mail.yahoo.com>
Thanks for reviving, Sid. I, in my Yahoo Search engineer capacity, am interested in this proposal as well. I think the existing tools that web devs have are not sufficient to protect against problems like healthcare.gov. We need transitions between sites to be private/secure by default while still allowing ways of efficiently opting in to sharing referrer details in a standard way. Our transition to support HTTPS, like others, was delayed by the referrer headache when we found advertiser and publisher log scrapers suddenly breaking because it was missing. I welcome a solution which removes this obstacle to quickly adopting HTTPS everywhere.
Regarding the proposed defaults outlined here[1] I am leaning toward instead defaulting to "origin but none when downgrade" (same-origin, cross-origin, subresources and navigations). This tends to resolve the privacy concerns while appeasing most log miners. Those that are mining logs like to have some signal about who is sending them traffic. The baby step of sending only the origin by default moves us towards solving 99% of the privacy problem. Sending nothing will upset large swaths of the community. The SEO community likes this header for obvious reasons (I would guess they want the unsafe-url in all cases) and the key question is can they deal with completely walking away from this as a data source? The "origin but none when downgrade" option is the middle ground.
Unfortunately it won't be enough to only do that for the referrer. There will be cases, mostly backwards compatibility reasons but some are legitimate, where there is a need to override the defaults. For the privacy paranoids, like me personally, there will be a desire to direct browsers to send no signal about what the previous page was. For the data hoarders, like advertisers, there will be a desire to send more than "origin but none when downgrade". Any new default should attempt to meet these folks halfway by providing a standard way to override.
There are cases where some signal about what the previous page is required even when downgrading. There are also cases where the full unsafe-url is required to be sent for certain sub-resources and/or navigations. So far the Referrer Policy[2] gets pretty close to offering ways of overriding these per-document defaults. I wonder if we could incorporate the proposed new per-document defaults into that document?
Regarding just using sendBeacon and/or postMessage, I'm not too keen on the idea since it would not be a standard way of sending referrer data, that is exactly what the Referer header is for.
Scott--[1] https://briansmith.org/referrer-01.html[2] http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-referrer-attribute

     On Friday, March 20, 2015 1:38 PM, Sid Stamm <sid@mozilla.com> wrote:

 Reviving a thread from a bit more than one month ago:

On Fri, 13 Feb 2015, Brian Smith <brian@briansmith.org> wrote:
>How about this?:

I like your direction here, Brian!

>1. We set the defaults to be strict.
>2. We allow the referrer attribute to make the policy less strict on a
>per-link/subresource basis.

I fully support these first two.  What does this group think of making
the default referrer "origin, but none when downgrade" for
implementing user agents?  Given my choice, I'd love the default to be
no-referrer, but I realize that's a huge change and it seems to me
that "origin" takes care of many privacy concerns here.

>3. The CSP directives are used to specify the maximum amount of
>disclosure of referrer information that everything will be capped at.

I think the referrer directive should define "document default" (much
like what meta referrer does) but I can imagine another directive or
special token in the referrer directive that could make the
CSP-defined policy a cap.  Maybe something like:

  referrer max-policy origin-when-crossorigin

>Then we probably don't even need <meta referrer> at all.

I'm not sure that's the case.  I think many site developers would
still prefer to use a meta referrer to set a blanket default for a
page.  Depending on a server/CDN setup, devs may not be able to
control the CSP per-request or per-document, but still be able to
write meta tags.  I much prefer CSP delivery of a referrer policy, but
there are also use cases for meta tags.


Received on Monday, 23 March 2015 17:38:15 UTC

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