I don't understand how the same referrer can be too sensitive to be sent as plaintext, but harmless enough to be passed to a not-necessarily-trusted third party.
The assumption is that secure pages are secure for a reason, and that the author of a secure page is linking to other secure pages and has some basis of trust by which the link is provided.
Example.com is the third party. (Example.org and a human user being the first two parties.)
Let me rephrase my question: why the default assumption that example.com is trusted not to misuse referrer information merely because example.org provides a link and the human user follows that link?
Example.com is the third party. (Example.org and a human user being the first two parties.)
I disagree. When you click a link on a page that you retrieved from example.org, one that leads to example.com, there is no communication between you and example.org, nor between example.com and example.org. The communication that takes place is between you (party 1, the initiator of the conversation) and example.com (party 2, the target). The HTTP request mentions example.org, but being a third party, it does not participate in it directly.
The only conversation in which example.org was a party was the one in which you requested the page that contained a link to example.com, which has already finished.
In that light, it seems strange to me that under HTML5 (assuming I understand the article correctly), example.org is given a mechanism to dictate how much information you give to example.com. Should that not be your choice, as the sender of said information?
2) Page from Site A suggests what should be sent in the referrer via the meta referrer
3) User clicks on link from Site A to Site B
4) User's browser requests page from Site B (referrer is set by either user's overriding option or the meta referrer from Site A)
So indeed, at no point does Site A speak to Site B directly. The meta referrer simply asks the user to either send or not send the referrer. If the meta referrer is not present or not supported, it falls back to default HTTP Referrer behaviour.
As the user, you can override this behaviour and force the referrer to do whatever you'd like. This includes refusing to send it, always sending it, or spoofing it. Firefox for example allows you to set network.http.sendRefererHeader and there are various browser extensions for any popular browser that will allow for finer grained referrer control.
Because the source site linked to it directly. That is the basis for trust.
If the destination is untrusted, then the source can just anonymise the redirect by sending it through a point that won't reveal the precise source. This is how services like http://anonym.to/en.html work.
This is the default behaviour, thought it indeed likely means sensitive referrers are being leaked from website X to third party website Y. In most cases I'd wager people aren't aware this is the default behaviour.
An example where the default behaviour may be appropriate is Facebook interacting with third party apps.
Facebook may be happy to pass referrer information across to these third party apps as long as they handle it securely. If the referrer goes across HTTP, it goes across the Internet in plaintext (unsecure). By ensuring it travels over HTTPS, you're at least ensuring a minimal level of security.
If your browser is communicating on the second HTTPS connection, that pretty much implies that you are happy with its security levels, right? After all, if you weren't (e.g. bad certificates, etc), your browser wouldn't have established & confirmed the secure connection, HTTP referrer headers or not.
We have two security domains, associated with the first and second server. The first server has sensitive URLs, the second receives these in the referrer header.
In making the first connection, the client and first server get to make some security policy decisions: the crypto used in securing the connection, the availability of countermeasures against known TLS protocol vulnerabilities, client and server authentication methods, etc. These parameters are complex, and you end up with a connection with some security level given some attacker model. If you think about it really hard, you can come up with a quantitive estimate of what security you might get from the connection in terms of attacker work -- anywhere from zero (trivially broken) to 256-bit security (very good).
Assume our first connection has a 128-bit security level and has countermeasures for TLS vulnerabilities. This is good going. Now we serve over this connection a https link, which the user clicks.
Unfortunately the client and/or second server is poorly configured and we only manage (for the sake of argument) a 40-bit security level and no TLS vulnerability countermeasures. Now we've reduced portions of the first connection to the security level offerred by the second connection. This is really very surprising.
If you are unhappy about using 40 bits, you can configure your browser to reject sending requests to such sites. When the connection with the second site is negotiated, it will ultimately get rejected, long before HTTP or any referrer headers are sent to it.
I see what you mean about dropping the security level, but generally SSL is seen as a binary 'good enough/not good enough' choice. I don't know of any browser that gives a graduated measure of a site's security. Either it flags up a warning or it doesn't.
That is a fair argument, but could equally be used for the non-HTTPS versions as well. The answer is the same in both cases: If you are not happy sharing such information, configure your browser not to use the referrer header.
I consider it incredibly rude to default to a lack of privacy, especially for visits to HTTPS sites, and especially because most users don't realize what's going on behind the scenes.
That may be, but it really shouldn't be. You cannot have sufficient trust in all parties involved to be certain that no sensitive data is going to a third party (the website you're going to) that is malicious.
1. Follow link from https://example.org to http://example.com --- referrer is not sent
2. Follow link from https://example.org to https://example.com --- referrer is sent
I don't understand how the same referrer can be too sensitive to be sent as plaintext, but harmless enough to be passed to a not-necessarily-trusted third party.