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.
1. Follow link from https://example.org to http://example.com --- can be read by a third party if referrer were added
2. Follow link from https://example.org to https://example.com --- cannot be read by a third party so referrer can be added
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.
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?
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.
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.
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 this is the protocol we're building economies on these days, I feel computer security is going to get much worse before it gets better...)
Let me expand my argument a little.
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.
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.