Shortened HTTP Referer header project

[Brian Smith]

>From https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header

> 4. Requirements
>
> [a] Test plan must be created and implemented
> [b] Use cases must be clearly outlined and it must
> be clear how the feature addresses each.
> [c] Initially, Phase 1 (user-set) should not change
> default behavior until user initiates change.
> [d] Default referer behavior for sites should not
> change until sites activate attenuation features.

Should these requirements be updated?

I think we should try to jump straight to making origin-only Referer headers the default by removing requirements [c] and [d], in the interests of expediency.

As I noted in the <meta referrer> bug [1], the lack of <meta referer=origin> support looks like a major performance issue, especially on very popular sites like google.com and facebook.com that currently use a redirect to limit the Referer to the origin in Firefox, but which link directly to the target in Chrome.

The spec for <meta referer> seems to be this wiki page:
http://wiki.whatwg.org/wiki/Meta_referrer

I disagree with some aspects of the spec. In particular, I think the spec. should explicitly mention that the Referer header should be limited by whatever user preferences are in effect. For example, if the user has chosen to set the default to "never" then all values must be interpreted as "never". As another example, if a browser vendor chooses to set the default to "origin" then "default" and "always" should not cause the browser to send path/query/hash in the Referer header.

With that out of the way, I propose that Firefox use the following interpretation of the values of the <meta referrer> header:

"never" - As specified in the wiki; do not send the Referer header. (This is the current behavior of Firefox for HTTPS -> HTTP nagivations.)

"origin" - As specified in the wiki. (This would change Firefox's HTTPS -> HTTP behavior to disclose the scheme, host, and port where it currently does not do so, and it would change Firefox's behavior to disclose less in all other cases.)

"default" - For HTTPS -> HTTP navigations, do not send any Referer header; otherwise, treat like "origin". (This discloses less information in the Referer header than what is specified in the wiki.)

"always" - Same as "origin". (This discloses less information in the Referer header than what the wiki recommends.)

any other value (or missing): Same as "default", which is what the wiki specifies.

IMPORTANT NOTE: In case it isn't clear, my proposal is suggesting that we shorten our default Referer header by default to sends only the origin (e.g. http://example.org:123/ instead of http://example.org:123/path?query#fragment), and that we allow sites to opt in to sending the origin for HTTPS -> HTTP navigations.

I can foresee the argument that we shouldn't interpret "always" or "default" differently than what the wiki specifies, because a site could always use the query parameters and redirects trick to disclose the information we are trying to prevent disclosure of. That is true, but in order to use that redirect trick, they would have to suffer a performance penalty. I think that is OK, as long as we are able to allow sites that do something reasonably privacy-preserving (stripping the path, query, and fragment) to avoid that penalty. Also note that Google's and Facebook's use of the redirect shows that prohibiting the sending of the Referer header for HTTPS -> HTTP cases for values "origin" and "always" is not really a way to enforce privacy-preserving behavior. The only way to really enforce "completely" privacy-preseving behavior would be to set the default to "never", which is likely to break too much stuff. (And, regardless, strengthening the default value to "never" can be done later, after we've experimented with limiting Referer to just the origin.)

Obviously, we'd have to do a lot of measurements to see what, if anything would break with this new default policy. But, I think spending effort on that testing would be much better than spending effort on UI for new values of the Referer prefs.

Thoughts?

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=704320

[Brian Smith]

Brian Smith wrote:
> Also note that Google's and Facebook's use of
> the redirect shows that prohibiting the sending of the Referer
> header for HTTPS -> HTTP cases for values "origin" and "always" is
> not really a way to enforce privacy-preserving behavior.

Also, note that Google and Facebook must redirect to a *non-HTTPS* location for this hack to work. So, implementing my proposal should make it easier for them to switch on HSTS (Strict Transport Security) on more of their domains, and it should eliminate unnecessary HTTPS -> HTTP -> HTTPS transitions (e.g. https://facebook.com/ -> http://facebook.com?redirectTo=https://example.org -> https://example.org) in many cases. (Currently on facebook.com and google.com, a passive MitM cannot learn the target URL and an active MitM can alter the target of your link click.)

So, I think this proposal is +1 security, +1 performance, and +1 privacy, though with unknown compatibility risk.

Cheers,
Brian

[Anne van Kesteren]

On Wednesday, February 27, 2013 2:51:18 AM UTC, Brian Smith wrote:
> origin (e.g. http://example.org:123/

Just to be clear, origins do not include a trailing /, but I guess we might want that for compatibility?

What about same-origin navigation, would that still include a Referer header that includes the actual path?