At the moment, we do not send outbound links through a redirect, so outbound links may leak information in referrers. Current thinking is that this has very low severity:

• We aren't aware of any ways to leak important information, and believe none exist. Information like the existence of the install, the number of objects on the install, wiki page names, project names, user account names, and Diffusion file paths can leak, but information that an attacker can directly escalate with (like security tokens) can not.
• Links are either user-generated or go to relatively trustworthy domains (phabricator.com, php.net, google.com, facebook.com). Attackers don't have known mechanisms to publish links on pages they can't otherwise access. Common usage of Phabricator sees mostly trustworthy domains in user content.
• Security-consicious installs should be using SSL, which will prevent referral leaks to non-SSL sites.

The common mitigation is to send outbound links through a redirect. However, this is messy technically, has some impact on the user experience, and still leaks the existence of the install (which I think is at least roughly comparable in severity to the other information which can leak).

There are two other new mechanisms which don't have these drawbacks:

• meta="referrer" in page headers (see http://wiki.whatwg.org/wiki/Meta_referrer)
• rel="noreferrer" in link tags

These mechanisms currently have only limited support, but provide far cleaner solutions with none of the drawbacks of link redirection. They are relatively easy to implement. All considered, the current plan here is:

• Wait for Diviner to unbeta (T988), when we'll want to go swap out all the doc links anyway (these account for almost all non-Remarkup offsite links).
• Hopefully browser vendors will have reached clear consensus by then, although this is probably wishful thinking given that the timeline on T988 is probably not longer than a few months.
• Implement the winning mechanism at that time, or both if there is no consensus.

Links we need to deal with are:

• Remarkup links;
• documentation links;
• setup issues have at least one offsite link to "php.net";
• auth provider workflows could use a look, although some of the redirect-based ones are probably not completely protectable with either mechanism. This is fine, since the external service necessarily knows of the existence of the install.