Hey @Krinkle do you think we need to have the Security folks take a look at this change? As you note we went through a decent amount of work to make Diff and the Foundation WordPress installs more secure. If I'm understanding you there's little risk here, but I want to be cautious.

I'm writing an essay on the topic, but in a nut shell: The unintended use of no-referrer and other mechanisms like it has fueled industry dominance of Google and others, making the broader ecosystem of websites like ours incorrectly believe that they are dependent on Google for 90% of their traffic. What has happened is that tonnes and tonnes of websites have blindly followed security theatre around Referrer-Policy, without understanding what this does or what choices you have. The consequence is that all of these websites have erased their own footprints, thus making it seem that all traffic comes from Google. It is a true tragedy of the commons, because whenever one site does this, they still see others, but others no longer see them, and over time, nobody sees anybody, except we all still see the handful of sites in our analytics don't follow do this: big search engines and social media sites. There are other cases I'm researching where this is even worse.

For Referral-Policy it's a bit surprising to see that no-referrer took off because nobody actually recommended or argued for it. Not the free "security scanners", not MDN docs, not experts like Scott Helme. When you hire a consultant to secure your site, they are likely to start with the most paranoid settings possible. It's easier to turn things off than to have to take responsibility for leaving something on; even if turning it off kills the site in question, that's not the consultant's problem because they're primarily protecting themselves, not the site. The result is hundreds of thousands of websites who voluntarily blackholed their own traffic attribution without understanding what that means.

Unless someone understands the specific settings, the impact is not realized until a later time. That time is now. There is a cross-discipline gap between security, performance, and SEO. Sometimes these align, but often they don't. When they don't, it's important to understand how the overall thing works and make a decision that actually works.

In T422587#11802049, @CKoerner_WMF wrote:

Hey @Krinkle do you think we need to have the Security folks take a look at this change?

I think matching what our most sensitive sites use in production (en.wikipedia.org, uk.wikipedia.org, zh.wikipedia.org), what experts like Scott Helme recommend, and what privacy advocates like WebKit and Mozilla use as the strict default in their browser, should be good enough for our blogs.

In T422587#11803881, @Krinkle wrote:

I think matching what our most sensitive sites use in production (en.wikipedia.org, uk.wikipedia.org, zh.wikipedia.org), what experts like Scott Helme recommend, and what privacy advocates like WebKit and Mozilla use as the strict default in their browser, should be good enough for our blogs.

Ok, that makes sense. I'll work on getting the security plugin updated.

In T422587#11803881, @Krinkle wrote:

I'm writing an essay on the topic,

Maybe a blog post? On Diff? :)

In T422587#11803881, @Krinkle wrote:

I'm writing an essay on the topic, but in a nut shell: The unintended use of no-referrer and other mechanisms like it has fueled industry dominance of Google and others, making the broader ecosystem of websites like ours incorrectly believe that they are dependent on Google for 90% of their traffic. What has happened is that tonnes and tonnes of websites have blindly followed security theatre around Referrer-Policy, without understanding what this does or what choices you have. The consequence is that all of these websites have erased their own footprints, thus making it seem that all traffic comes from Google. It is a true tragedy of the commons, because whenever one site does this, they still see others, but others no longer see them, and over time, nobody sees anybody, except we all still see the handful of sites in our analytics don't follow do this: big search engines and social media sites. There are other cases I'm researching where this is even worse.

In T422587#11802049, @CKoerner_WMF wrote:

Hey @Krinkle do you think we need to have the Security folks take a look at this change?

I think matching what our most sensitive sites use in production (en.wikipedia.org, uk.wikipedia.org, zh.wikipedia.org), what experts like Scott Helme recommend, and what privacy advocates like WebKit and Mozilla use as the strict default in their browser, should be good enough for our blogs.

Hi @Krinkle - we are writing technical implementation guidelines to add to the Wikimedia Attribution framework site for external reusers of our content. A recommendation we plan to include is adding the wprov parameter for provenance. Curious if you would contribute to this guideline with recommendations about dropping no-referrer as well?

cc @Khantstop @Sarai-WMF

@Krinkle We implemented this change to Diff today. Coming soon to the other sites. Can you confirm that you're seeing the correct value now? I ran the same scanner you used in the task description. :)

This is now implemented on wikimediafoundation.org and wikimediaendowment.org (just last week techblog was redirected to Diff, and as a side-effect, resolved the issue there). @Krinkle can you please confirm and resolve if so?

https://diff.wikimedia.org/2026/05/28/volunteer-supporters-network-launch-newsletter/ > https://wikimania.wikimedia.org/wiki/2025:Meetups/VSN_meetup

Referer: https://diff.wikimedia.org/

Works as expected now.

https://wikimediafoundation.org/who-we-are/ > https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_20th_birthday_collage_for_blog.jpg

Still lacks a referrer. While the Referrer-Policy issue was fixed, there is also still rel="noopener noreferrer" attributes on every link causing the same issue still. These attributes became popular in 2016 as part of a long-fixed security issue where opening links in a new tab (via target=_blank) exposed a JavaScript vulnerability. This has since been fixed with noopener in all browsers. At the time, in 2016, people found that noreferrer happens to close that vulnerability as a side-effect, and so it became popular to set both on all links. As second side-effect however, it also erased much of the open web from traffic attribution.

WordPress removed this outdated security fix back in 2020 (https://core.trac.wordpress.org/changeset/49215). Although I noticed they do still have a second instance of this issue in their Gutenberg editor (https://github.com/WordPress/gutenberg/issues/26914). They're working on fixing that as we speak.

We remove this from any custom code we maintain as well. Specifically these two:

• wikimediafoundation.org: https://github.com/search?q=repo%3Awikimedia%2Fshiro-wordpress-theme%20noreferrer&type=code
• diff.wikimedia.org https://github.com/search?q=repo%3Awikimedia%2Fdiff-blog%20noreferrer&type=code

It's a bit hard to find to find internal links on wikimediafoundation.org that don't also have these attributes, but I found one eventually, and indeed this one now correctly gets a referral set, thanks to the Referrer-Policy fix. Nice!

https://wikimediafoundation.org/jobs/ > https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Terms_of_Use

Referer: https://wikimediafoundation.org/

@CKoerner_WMF Feel free to close this task as resolved. I'll leave it to you to decide if/where you want to separately track the equivalent issue for the WMF and Diff blog themes.