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?

@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.

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

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

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

@Johan Thats the goal. It might be afterwards

OK, thanks!

@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.

In T87276#1997286, @Johan wrote:

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?

@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

excellent! cc @Rdicerb @Sadads @Johan

Awesome!

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

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

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

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.

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.

@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.

In T87276#2055795, @BBlack wrote:

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.

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?

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.

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/

In T87276#3560795, @DarTar wrote:

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?

@TheDJ: The upstream bugs were resolved a year ago, but the error still happens in the latest Safari (including in Safari Technology Preview Release 56 (Safari 11.2, WebKit 13606.1.17.2.2)). Did it regress since last year or am I missing something?

It's just complaining about the old misspelled value that we have in our chain currently I think. See T180921#4219272

This is still spewing errors in the console for every page load in Safari due to the hyphenless keyword. But cf. T180921 and T178356, are there any still-supported UAs that need (and do something sensible with) the old version of the keyword? That actually support current SSL/TLS versions and options (i.e. can actually connect)? Can we get rid of it? (finally, after eight years)

In T87276#8784283, @Xover wrote:

This is still spewing errors in the console for every page load in Safari due to the hyphenless keyword. But cf. T180921 and T178356, are there any still-supported UAs that need (and do something sensible with) the old version of the keyword? That actually support current SSL/TLS versions and options (i.e. can actually connect)? Can we get rid of it? (finally, after eight years)

According to @TheDJ in WebKit bug #175069, Safari 11.1 added support for origin-when-cross-origin. Based on the testing by @Krinkle in T178356#8740573, Grade A support for Safari <11 was dropped by T178356.

Devices that can run iOS 10 but not iOS 11 are the iPhone 5, iPhone 5c, and iPad (4th generation). On desktop all devices that can run Safari 10 can also run Safari 11.

IOW, there is a small gap of Grade C devices on mobile that do not support the new keyword and will get fallback behaviour.

I think it's time to drop origin-when-crossorigin.

Removal is already in progress via T338183