When you viewing the commits of a repository on GitHub such as this one https://github.com/icefox/git-hooks/commits/master you will see a Gravatar image next to each commit. In Chrome if you open up the inspector and view the Network headers for the image's you will see along with other things that it is sending the header:
The past decade urls have for the better gained more meaning, but this can result in insider information leaking through the referer tag to a 3rd party. What if you were working for Apple and running a copy of GitHub internally, it might not be so good to be sending https://git.apple.com/icefox/iwatch/browse out to Gravatar. Even private repositories on GitHub.com are leaking information. If your repository is private, but you have ever browsed the files in your repository on GitHub you have leaked the directory structure to Gravatar.
While it seems common knowledge that you don't use 3rd party tools like Google's analytics on an internal corporate website, Gravatar images seem to slip by. Besides outright blocking one simple solution (of many no doubt) I have found is to make a simple proxy that strips the referer header and than point Gravatar traffic to this machine. For Apache that would look like the following
RequestHeader unset referer
RequestHeader unset User-Agent
ProxyPass /avatar http://www.gravatar.com/avatar
Edit: This post has spawned a number of emails as so I want to clarify my setup:
Using Chrome version 33 I browsed to a server running apache setup with ssl (the url would looks like: https//example.com/) and on that page it had a single image tag like so:
When fetching the image Chrome will send the referer header of https://example.com/ to gravatar.com.
While Chrome's inspector says it sends the header just to be sure it wasn't stripped right before the fetch I setup a fake gravatar server with ssl that dumped the headers received and pointed the page to it and found as expected the referer header were indeed being sent.
For all of those that told me to go look at the spec I would recommend that you too read it rfc2616#section-15.1.3 where it only talks about secure to in-secure connections which is not the case we have here.
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.