Set an explicit "Origin When Cross-Origin" referer policy via the meta referrer tag
Closed, ResolvedPublic

Description

Adopt an "Origin When Cross-Origin" policy via the Meta Referrer tag, per https://meta.wikimedia.org/wiki/Research:Wikimedia_referrer_policy

See public discussion on Meta:
https://meta.wikimedia.org/wiki/Research_talk:Wikimedia_referrer_policy

I am creating this task to keep track of any patch, should we end up implementing this or a similar proposal.

Recommendation from privacy/security review: use an Origin When Cross-Origin policy.

There are a very large number of changes, so older changes are hidden. Show Older Changes

@csteipp: have you been able to look into this?

Dario: follow up by email with @csteipp

Elitre added a subscriber: Elitre.Oct 21 2015, 7:45 AM
csteipp added a comment.EditedOct 23 2015, 4:36 PM

Digging into how browsers implement this, it looks like they are pretty consistent. Currently, all browsers (that I could find) pass the full url to any https site, and no referrer to http sites. With the meta header, browsers that implement the feature pass our domain name in the referrer to both http and https urls.

Against a passive, pervasive-surveillance threat, this gives some new information to the attacker-- they would know the specific site/project the user came from, instead of merely knowing that they came from a WMF site.

[edit] - With most browsers implementing SNI, an attacker probably already knows the domain name that that user was talking to vai https on our site, so in practice this isn't likely to leak any new information to the attacker.

However, the privacy of users is greatly increased by only sending the domain to https websites, instead of the full url.

Unfortunately, there's no, origin-for-safe-but-none-with-downgrade as far as I can tell, so origin (or more likely we want origin-when-crossorigin) is probably the least bad option, since I don't think internally we can set 'none'.

@csteipp, thanks. Thanks for the review, I too support Origin When Cross-Origin.

@Rdicerb this is now in your camp, let me know how I can help.

DarTar updated the task description. (Show Details)Oct 23 2015, 5:32 PM
Sadads added a subscriber: Sadads.

This is of interest to the Wikipedia library: some of our business case for donations from Publishers is the traffic case, and in the long run, this will be an important element of arguments that support more Open Access sourcing. I am imagining GLAM-Wiki would also be interested in accuracy for this kind of referral data.

@Sadads very much agreed. The original use case did come from scholarly publishers (see T99174), CrossRef's most recent estimates put Wikimedia at the 3rd-4th rank as a global source of DOI lookups (well ahead of any other individual publisher). I hadn't thought of the GLAM use case but it definitely makes sense.

@Rdicerb

(typing for @DarTar) would like to know if this is on your radar and what needs to happen on your end before we can proceed.

This already passed security review per @csteipp

Thanks!

Assigned to @Rdicerb as discussed ;)

Rachel: I'd be happy to help write an update at https://meta.wikimedia.org/wiki/Research:Wikimedia_referrer_policy as you see fit.

Tgr added a subscriber: Tgr.Nov 17 2015, 12:29 AM

@Rdicerb whats the status/progress on this? We have been talking to a number of our partners about this issue, and it would be nice to have a window/timeline/prospect for if/when the origin data can be communicated.

It seems like the functionality was merged quite a while back, and we just need to do a mediawiki-config commit to set $wgReferrerPolicy to Origin When Cross-Origin

Mdann52 claimed this task.Nov 25 2015, 4:56 PM

As I'm doing a load of these at the moment, I'll take this one too!

Change 255408 had a related patch set uploaded (by BBlack):
Set explicit referrer policy for WMF sites

https://gerrit.wikimedia.org/r/255408

Fantastic, thank you all. I'll notify our external collaborators (CrossRef and BBC) we're about to go live.

I'll talk to Comms to discuss the appropriate channels to announce the change, @BBlack what's the current ETA for the change to be live in production?

BBlack added a subscriber: greg.Nov 25 2015, 6:00 PM

@DarTar - I'm not sure. Normally I think we'd just put this in the next SWAT, but SWAT is currently frozen for holidays - see https://wikitech.wikimedia.org/wiki/Deployments#End_of_year.2Fbeginning_of_new_year_.27code_freezes.27 . We'd need to wait for the week of Dec 7 or get approval from @greg, as this isn't a critical security or data-loss fix.

@BBlack @greg I'd be happy to postpone the actual deployment to early January so we can monitor the effects on referred traffic on the target domains in collaboration with our partners.

I was under the impression that we'd wait until January, as well. Gives the team all of December to ensure users are aware who have been following the issue. (it seems supported, but much of the conversation took place several months ago)

If there is a good window of time that we know that this will be implmented, The-Wikipedia-Library has a few key partners that we could ask about specific traffic effects, to understand rates and ratios, etc. @Samwalton9 does most of our metrics discussion with our partners, so will be the contact alongside me for @DarTar for Comms and/or tracking with publishers.

@Rdicerb: we are putting together our next Newsletter for the Wikipedia Library: happy to include more discussion https://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Library/Newsletter/October-November2015 . It gets shared through a number of community channels, and we regularly talk about referencing etc.

Also thanks @BBlack!

@Rdicerb yes that's what we discussed but I guess the timeline was never communicated on this thread (I should have posted an update). January is definitely the best option.

@Sadads @Samwalton9 quick coordination call next week to discuss partners and do a little bit of planning?

(@Rdicerb it would be great to have you too)

@DarTar Sending a scheduling email now -> please let me know if it works.

DarTar renamed this task from Set an explicit "Origin" referer policy via the meta referrer tag to Set an explicit "Origin When Cross-Origin" referer policy via the meta referrer tag.Jan 19 2016, 8:51 PM

Started a preliminary discussion with Ops on the timeline of a possible rollout.

Nemo_bis reassigned this task from Mdann52 to DarTar.Jan 31 2016, 9:24 PM

This is just about ready, so sending it over to Tech/News.

Johan added a subscriber: Johan.Feb 4 2016, 10:53 AM

I'll mention it in Tech News. This will go into production on February 15, correct?

Sadads added a comment.Feb 4 2016, 7:44 PM

@Johan Thats the goal. It might be afterwards

Johan added a comment.Feb 4 2016, 8:40 PM

OK, thanks!

Sadads added a comment.Feb 5 2016, 8:54 PM

@Johan Your team also metioned that it might be a good idea to place a notice at https://meta.wikimedia.org/wiki/Template:Main_Page/WM_News notifying of the change, and pointed to the research page? That would be super helpful as well.

I'll mention it in Tech News. This will go into production on February 15, correct?

As today's the 16th - are there still blockers before we roll this, or is it just waiting for someone to put it on the Deployments calendar now?

He7d3r added a subscriber: He7d3r.Feb 18 2016, 2:02 PM

@BBlack per email, we have a solid list of partner orgs confirmed (T87276) and no more blockers for a deployment.

Added to Deployment calender for Morning SWAT on Monday (Feb 22) - https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20160222T1600

Change 255408 merged by jenkins-bot:
Set explicit referrer policy for WMF sites

https://gerrit.wikimedia.org/r/255408

Jdforrester-WMF closed this task as Resolved.Feb 22 2016, 4:12 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Hurrah.

Krinkle reopened this task as Open.Feb 22 2016, 6:43 PM
Krinkle added a subscriber: Krinkle.

This was wrongly configured and doesn't work.

Failed to set referrer policy: The value 'Origin When Cross-Origin' is not one of 'always', 'default', 'never', 'no-referrer', 'no-referrer-when-downgrade', 'origin', 'origin-when-crossorigin', or 'unsafe-url'. This document's referrer policy has been left unchanged.

This error is currently being reported in the dev console for all users on all projects.

DarTar raised the priority of this task from Low to High.Feb 22 2016, 6:45 PM

Change 272517 had a related patch set uploaded (by BBlack):
Bugfix: wrong value format for wgReferrerPolicy

https://gerrit.wikimedia.org/r/272517

Indeed, the correct value to use in the meta tag should be origin-when-cross-origin, lowercase and hyphenated (reference).

Note that the error message misses the hyphen: origin-when-crossorigin.

Header should have been 'origin-when-crossorigin'

Per discussion with @BBlack, @csteipp and @Krinkle on Gerrit, and after checking that major browser vendors originally implemented the erroneous version without the hyphen (origin-when-crossorigin) but later released patches to support both values, the decision is to move forward and use origin-when-cross-origin, consistently with the specs.

Change 272517 merged by jenkins-bot:
Bugfix: wrong value format for wgReferrerPolicy

https://gerrit.wikimedia.org/r/272517

DarTar closed this task as Resolved.Feb 23 2016, 1:24 AM
Krinkle merged a task: Restricted Task.Feb 23 2016, 3:44 PM
Krinkle added a subscriber: MaxSem.
TheDJ added a subscriber: TheDJ.EditedFeb 23 2016, 4:51 PM

I now get errors in Safari/Webkit console btw.

[Error] Failed to set referrer policy: The value 'origin-when-cross-origin' is not one of 'no-referrer', 'origin', 'no-referrer-when-downgrade', or 'unsafe-url'. Defaulting to 'no-referrer'. (index.php, line 22)

I have therefore opened a feature request ticket with upstream.

Fascinating :) Any idea if it also throws an error on the other spelling that the specs have been confusing on, which is origin-when-crossorigin? From the error message, it sounds like it would.

faidon added a subscriber: faidon.Feb 23 2016, 5:04 PM

Apologies if this has been discussed before, but why did we do this with a <meta> header instead of the HTTP Header? The latter besides feeling cleaner, would allow us to manipulate (e.g. unset or change) the header temporarily from VCL in case we need to change it for some emergency reason, without waiting for the HTMLs to expire.

I don't think that was ever really discussed that I recall. Part of what breaks this all up is that the feature was implemented in code terms way back in Jan 2015 here: https://gerrit.wikimedia.org/r/#/c/186104/ , and the *code* only outputs the meta tag, not the header. From that point, when it came closer to actually turning this on, the discussion was only about turning on the mediawiki-config to enable the feature that had already been in the code forever.

DarTar added a comment.EditedFeb 23 2016, 5:52 PM

@faidon: what @BBlack said, I don't think this option has ever been discussed. I understand the idea of a <meta> header instead of an HTTP header is to allow content publishers to retain fine-grained control at the document level, but I can't think of any use case where we would need that.

For reference, this is the relevant section from the specs.

TheDJ added a comment.Feb 24 2016, 1:45 AM

Fascinating :) Any idea if it also throws an error on the other spelling that the specs have been confusing on, which is origin-when-crossorigin? From the error message, it sounds like it would.

Tested, yes, that also reports an error.

Restricted Application added a project: Traffic. · View Herald TranscriptFeb 24 2016, 1:45 AM
Restricted Application added a project: Operations. · View Herald TranscriptMar 1 2016, 3:15 PM
jayvdb added a subscriber: jayvdb.Mar 2 2016, 5:42 AM
Akeron added a subscriber: Akeron.Mar 2 2016, 10:32 AM
DarTar added a comment.Mar 9 2016, 9:27 PM

John Vanderberg posted some comments on the possibility for target sites to reconstruct the full referral, which are accurate (to the best of my knowledge) and represent one of the undesirable consequences of this change. @csteipp @BBlack: can you take a look and respond on-wiki if you have any additional thoughts?

Tgr added a comment.Mar 9 2016, 9:42 PM

Note that before the change target sites which were linked over HTTPS received the full URL, not just the origin.

In any case, if the topic of your site is so specific that only a single Wikipedia page links to it, it's hard to imagine that it would yield any nontrivial information if you learned about a visitor of your site that they visited that wiki page. Probably the only real information leak that happens here is that you might learn about the language or nationality of the user from what language subdomain they come from.

Tgr added a comment.Aug 28 2017, 10:30 PM

Chrome seems to claim our referrer policy is no-referrer-when-downgrade. (Chrome 60.0.3112.101, Ubuntu 16.04, https://en.wikipedia.org/wiki/Main_Page, top of Network > Headers in dev console.) observatory.mozilla.org and securityheaders.io also claim we have no referrer policy. It might be that those tools just aren't intelligent enough to look at meta tags, or it might be that the meta tag is recognized by less devices. Are we sure that's not the case?

(See also @faidon's comment above.)

@Tgr I can't speak for these services, it sounds likely they only check headers and not document-level policies indeed. Regardless, our referrer policy (as specified via meta tags) has been in effect and confirmed by various partners Wikimedia works with, see for example this blog post Crossref wrote and I contributed to: https://www.crossref.org/blog/https-and-wikipedia/

Nemo_bis added a comment.EditedSep 7 2017, 4:39 PM

has been in effect and confirmed by various partners Wikimedia works with, see for example this blog post Crossref wrote and I contributed to: https://www.crossref.org/blog/https-and-wikipedia/

...where the graph stops just the day before the referrer policy was implemented?