Chrome 85 Breaks Referer

GitHub API Development and Support
#1

Before Chrome 85, when clicking external links on github the browser would send the Referer header with the full path. For example, on https://github.com/jamesward/hello-netcat clicking the button goes to a site that uses the Referer header to know which repo the user is coming from. Cloud Run Button, Heroku Button, and other tools use this header. As of Chrome 85, the browser sets Referrer-Policy
to strict-origin-when-cross-origin which means these links now only send a Referer of https://github.com which breaks anything that depends on knowing which repo the user was on when they clicked something. Details: https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default

It appears that github.com can override this default by sending their own Referrer-Policy header with a value of no-referrer-when-downgrade. Would it be possible to do this and unbreak a bunch of stuff?

5 Likes
#2

Hi there,
Chrome team involved with the change in question here (maudnals, cos_theta, rowan_m on Twitter). A few ideas to share, we hope this may help!

@jamesward 's suggestion would fix the problem, but full GitHub URLs would always be leaked in all outgoing cross-origin requests across all of GitHub, which hinders users privacy. Browsers are generally switching to strict-origin-when-cross-origin as a default for this reason. This also may not be future-proof, in case browsers become more strict and stop sharing full URLs in Referers in cross-origin requests.

A few ideas/solutions:

Solution 1
[EDIT: not working]
Button users now must include HTML to specify a referrer policy instead of simple markdown. <a referrerpolicy="no-referrer-when-downgrade" href="https://deploy.cloud.run"><img src="https://deploy.cloud.run/button.svg" alt="Run on Google Cloud"></a>.
=> Example here: https://github.com/maudnals/button-sample/blob/master/README.md

Pros:

  • GH users’ privacy is preserved
  • Doable “today/soon”? (would require Heroku/Cloud Run documentation change)

Cons:

  • May not be future-proof, in case browsers become more strict and stop sharing full URLs in Referer cross-origin.
  • May not be supported on Safari iOS.

(A variation of this would be update the markdown to support specifying the referrerpolicy attribute.)

Solution 2
Button users (= people that include a Heroku/Cloud Run button on their GH repo) now always need to specify the GH repo. Heroku/Cloud Run scripts never rely on the Referer anymore.

Pros:

  • GH users’ privacy is preserved.

Cons:

  • Heroku/Cloud Run/Other tools need to update their systems to not expect a Referer.
  • For GH users, forking repos that include a Heroku/Cloud Run button requires one more step: changing the repo URL in the Button configuration. This may lead to errors if they forget to do so. Mitigation: Heroku/Cloud Run may update their documentation to include a warning: "When including the button on a GH repo, add a line on your README that says: ‘Change this if you fork this repo!’ ".
  • Potentially more future-proof. Not dependent on browser behaviour.

Side note for GitHub: regardless of the solution, applying an explicit privacy-preserving policy of strict-origin-when-cross-origin globally to github.com would help it behave predictably. Because if github.com has no policy at all, it will fall back to the browser default policy i.e. strict-origin-when-cross-origin or other, depending on the browser - the behaviour won’t be consistent across browsers and will evolve as browser default changes.

maudnals, cos_theta, rowan_m on Twitter

1 Like
#3

(referrerpolicy on Safari iOS - Not tested though!)

#4

Thanks for the response and investigation! It doesn’t look like the sample is working. Shouldn’t the referrerpolicy="no-referrer-when-downgrade" be on the a tag? Or maybe github is filtering it out in their rendering?

#5

Looks to me like the referrerpolicy attribute in the example slipped into the img tag when it should be in the a.

#6

Apologies, it’s now in the <a> but it looks indeed like it’s removed, so it’s not working.

[EDIT: adding a comment by editing this answer, since I’m not allowed to post over 3 - this comment comes after @ahmetb 's comment below]:

Summing up a few ideas/solutions that GitHub would need to act on:

  • For all rendered markdown files, set the policy on all <a> elements automatically to no-referrer-when-downgrade (quoting @ahmetb 's answer from below)

  • Use heuristics to detect Cloud/Heroku buttons and set the policy only on these <a> elements to no-referrer-when-downgrade

  • GH would enable referrerpolicy to be set in <a>s in markdown files (not possible now), run a query on their end, and could potentially notify the repository owners to consider updating their code.

Note: any of these would be preferable privacy-wise to setting a global behavior site-wide with a header, as they would limit cross-origin leaks to a smaller surface of GH.

About the privacy bit:

  • A GitHub repo’s URL contains usernames, which looks like it’s considered personal data under the GDPR

  • The privacy problem here is primarily about leaking information cross-origins the user may not expect.

maudnals , cos_theta , rowan_m on Twitter

#7

At this point, just Google’s button already exists on some triple-digit repos. Those will be broken forever unless we go submit PRs for them manually. Not to mention Azure Websites, Heroku etc have been around longer, so we’re likely looking at thousands of broken repos here.

Feasible solution requested from GitHub here would look like:

  • restore old behavior site-wide with a header, OR
  • add referrerpolicy property to <a> elements, for either:
    • in all rendered markdown files, OR
    • whitelist certain button urls (just like how certain badge images are freshly loaded in .md files on github)

I’m inclined to think there aren’t privacy issues with this as far as GitHub users are concerned. The repos in question are public repos and don’t contain PII.

1 Like