Re: Referrer Policy: Same-origin URIs

Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
> Analytics often run as scripts in the origin of the
> page. Google Analytics is one famous example. Yes, this is bad; this
> is why we should have sub-origins and SRI :)

I believe Google Analytics can be contained in an iframe sandbox
already, if one "just" writes a wrapper around it that uses the GA API
(designed for mobile, but usable everywhere, IIUC) instead of <script
src='...'>. So, I'm not convinced that we need (big) new things for
analytics. Also, I don't expect SRI to work well for analytics because
the analytics services probably want the scripts to be quickly updated
when needed.

> To be clear, I am proposing that the "value of the referer" can be a
> URI that is same-origin. Where the referer then flows depends on the
> target URI of the request---it can be cross-origin or same-origin.

Your example use case was a help page that is linked to from a secret
URL, where you don't want the secret URL to be leaked to analytics or
ads via document.referrer, right? Isn't this use case already covered
decently by these two existing mechanisms:

1. Using today's browsers' current defaults: Your secret page "/help"
contains a direct link to the help page. When your web app processes
the request for the help page, if it detects that the referrer
contains a secret part. It then does an HTTP redirect to
"/help?referrer-category=capabilityurls/" to scrub the referrer. Many
websites do this today.

2. Using a policy like "origin": Install a onclick handler to all the
links to "/help", that appends "?referrer-category=capabilityurls/" to
the link before navigating to it.

Note that doing #2 is a performance optimization for #1 for browsers
that support setting a referrer policy of "origin" because it saves
you the scrubbing redirect. Also note that you'll need to do #1 for a
long time for browsers that don't support setting referrer policies
anyway.

While I think there could be a standard for a way to send more than
the origin but less than the full URL, I think that technique #2 is
more in line with the extensible web idea of letting web content take
control over what it does while adding fewer new things to browsers.

Cheers,
Brian

Received on Monday, 10 November 2014 03:19:57 UTC