This article is about website owners. The best thing you can do as a user is enabling the 'Referer' for same-origin requests only. That way, you keep almost all the advantages of the 'Referer' but at the same time fix almost all the privacy issues.
In Firefox, you can do this by setting `network.http.referer.XOriginPolicy` to `1` in `about:config`. Or use a `user.js` file with other helpful privacy settings, e.g. https://github.com/delight-im/Secure-Firefox
Note to be sure to set to 1 (base domains match) and not to 2 (domains match). Otherwise you'll be blocked from many CDNs used by large domains (for example... example.com serves its images and static js from cdn.example.com). Many CDNs are configured to check the referrer to prevent hot-linking of images, javascript, etc.
Also note that setting it to 1 will still block you from loading CDN-served images and javascript for smaller sites that are not using their own custom subdomain for their 3rd party CDN service. So, a site using MaxCDN to serve their images and javascript from the default CDN-issued domain of zonename.companyname.netdna-cdn.com with "HTTP Referrer Whitelist" enabled for their example.com domain that you are visiting will block you from downloading images and static javascript hosted on the CDN.
Also, if you use uMatrix, you can choose to spoof the referrer string of third-party requests. And you can optionally choose to allow referrers for certain domains:
referrer-spoof: * true
referrer-spoof: wsj.com false
This, for example, "allows" viewing of articles on wsj for google-referred links.
You can also do this in Chrome although I'm not sure if the behavior is identical.
On chomre://flags search for reduced-referrer-granularity and enable it to get a similar effect. I believe it may only affect web sites that do not explicitly provide a referrer policy.
This gives you the ability to whitelist websites, and also a lot of control over what kind of requests are blocked and what aren't. I have it set to block everything by default, and only a few websites cause problems.
Well I also use uMatrix which covers the cases where the built-in option does not. It can also be controlled on a per-site basis. I assume the functionality is pretty much the same.
The URL refresh thing can be done without JavaScript by having a little server side entrypoint that redirects to a destination URL with the same header.
If I understand you correctly you would still have a Referer header that said you came from fastmail.com, however it could be stripped of other sensitive information. So the URL would be something like "https://fastmail.com/redirect?u=https://example.com"
Facebook uses a method called LinkShim with a bit of JavaScript (to avoid garabling copy&pasted links) and a hash of the URL generated serverside to avoid open redirects.
I'm thinking on working on my own implementation for a project
I'm building a end to end encrypted chat platform in JS (I'm aware of the risks here it's a toy project) and I might have to use an open redirect to prevent urls from leaking out of messages before they are clicked. I was thinking of doing something like external-link.domain.io/redirect?url=https://www.google.com to make it obvious.
Does that entry point need to be protected in any way from people using it ... maliciously ... somehow? I recall people being upset about open redirects in the past, but I can't actually formulate a coherent security objection to it.
It should be locked otherwise you can trick people into clicking on a link thinking it belongs to that company. Google, for instance, does protect against that, so you can't use http://www.google.com/url?http://www.example.com/
By controlling the referer header you can do all sorts of cool things like tamper with authenticated Google search histories in a way which makes it look like the person actually searched for a particular term:
"The misspelling of referrer originated in the original proposal by computer scientist Phillip Hallam-Baker to incorporate the field into the HTTP specification.[3] The misspelling was set in stone by the time of its incorporation into the Request for Comments standards document RFC 1945; document co-author Roy Fielding has remarked that neither "referrer" nor the misspelling "referer" were recognized by the standard Unix spell checker of the period.[4] "Referer" has since become a widely used spelling in the industry when discussing HTTP referrers; usage of the misspelling is not universal, though, as the correct spelling "referrer" is used in some web specifications such as the Document Object Model."
Before loading the page I thought this might be about hiding the client's ip (that connected to an SMTP server) in the mail headers. Is that possible at all?
It actually doesn't totally avoid the issue, because you're still leaking information unless you use a different ID for every request. Someone looking at referer logs can see that you accessed two different things from the same folder.
There's also the u= parameter which tells which user you are. That _is_ obfuscated, but it has the same correlation issue, it's the same for forever for a single user, so you could tell that it's the same user looking at different URLs.
(we use the u= parameter both for supporting multiple concurrent logged in users on the same machine, and as an extra layer of CSRF protection)
In Firefox, you can do this by setting `network.http.referer.XOriginPolicy` to `1` in `about:config`. Or use a `user.js` file with other helpful privacy settings, e.g. https://github.com/delight-im/Secure-Firefox