Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MBS-8796: Set a referrer policy of “unsafe-url” #360

Merged
merged 1 commit into from Oct 1, 2016

Conversation

@chirlu
Copy link
Contributor

chirlu commented Sep 29, 2016

By default, when following a link from a web page delivered via HTTP, a browser will send the URL of the linking page (the referrer) to the new server. On the other hand, when coming from an HTTPS page, the referrer is by default only sent if the target page is delivered via HTTPS, too. This behaviour is a relic from a time when HTTPS was only used for, e.g., webmail or banking, and was intended to reduce the risk of session-key URLs leaking via the referrer. It may also be useful in some other cases, for privacy reasons; e.g., for a social media page that is only visible to a specific group of people and contains a link to an external site, it may be unwelcome that the external site could find out who referred to it.

For a site like MusicBrainz, however, that is almost completely(*) public, does not use session keys in its URLs, and is accessible both by HTTP and HTTPS (and in the future possibly HTTPS only), this default browser behaviour is not appropriate. It is actually desirable that target sites (musicians, labels, external databases, etc.) learn that visitors found them via MusicBrainz.

In order to let sites customize browsers’ referrer behaviour, the referrer policy standard (https://www.w3.org/TR/referrer-policy/) was developed. The most suitable policy for all-public sites is, despite its intentionally discouraging name, unsafe-url, which is the old default behaviour from before HTTPS: Always send a referrer, whatever the HTTP/HTTPS status of the origin or target sites is.

This commit accordingly sets a referrer policy header for all web pages (but not the web service, which isn’t normally consumed by web browsers directly) with a policy of unsafe-url.

(*) Private collection pages are an exception, but they don’t contain external links – they only link to the entity pages on MusicBrainz itself.

By default, when following a link from a web page delivered via HTTP,
a browser will send the URL of the linking page (the referrer) to the
new server. On the other hand, when coming from an HTTPS page, the
referrer is by default only sent if the target page is delivered via
HTTPS, too. This behaviour is a relic from a time when HTTPS was only
used for, e.g., webmail or banking, and was intended to reduce the
risk of session-key URLs leaking via the referrer. It may also be
useful in some other cases, for privacy reasons; e.g., for a social
media page that is only visible to a specific group of people and
contains a link to an external site, it may be unwelcome that the
external site could find out who referred to it.

For a site like MusicBrainz, however, that is almost completely(*)
public, does not use session keys in its URLs, and is accessible both
by HTTP and HTTPS (and in the future possibly HTTPS only), this
default browser behaviour is not appropriate. It is actually desirable
that target sites (musicians, labels, external databases, etc.) learn
that visitors found them via MusicBrainz.

In order to let sites customize browsers' referrer behaviour, the
referrer policy standard (https://www.w3.org/TR/referrer-policy/) was
developed. The most suitable policy for all-public sites is, despite
its intentionally discouraging name, "unsafe-url", which is the old
default behaviour from before HTTPS: Always send a referrer, whatever
the HTTP/HTTPS status of the origin or target sites is.

This commit accordingly sets a referrer policy header for all web
pages (but not the web service, which isn't normally consumed by web
browsers directly) with a policy of "unsafe-url".

(*) Private collection pages are an exception, but they don't contain
external links - they only link to the entity pages on MusicBrainz
itself.
@mwiencek

This comment has been minimized.

Copy link
Member

mwiencek commented Oct 1, 2016

Okay. 👍 As you said, I can't think of any situation where this would be "unsafe" for us.

@mwiencek mwiencek merged commit 4f2d541 into metabrainz:master Oct 1, 2016
1 check passed
1 check passed
Jenkins Build finished.
Details
@chirlu chirlu deleted the chirlu:mbs-8796 branch Oct 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.