Per https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy Firefox considers the default to be strict-origin-when-cross-origin.

Firefox enforces strict-origin-when-cross-origin since Firefox 93 (released in October 2021) when Tracking Protection is enabled. The user can disable it per-site (click on the shield in the address bar) and in this case these logs disappear in the console.

Seeing the issues where some browsers misinterpreted some values and even the fallback mechanism (T180921), any change should be properly evaluated to stay compatible with main browsers, even if Firefox is complaining.

Moving from Traffic to Wikimedia-Site-requests because this is configured in MediaWiki, not Varnish.

Perhaps it makes sense to just switch to strict-origin-when-cross-origin

The rationale for the previous policy was to allow partner organizations to gather broad stats on clickthrough rates to justify future funding of partnerships as far as i understand. Pretty much any legit partner will be using https, so it seems like switching to strict-origin-when-cross-origin, would have no downside.

doesnt this depend on the links that WE have/use to get to them? In that case, we can analyze our https to http external link ratio, sample the http bucket to discover percentage of just dead links and wed have an idea of how many links this would practically even impact.
Id be surprised if its more than .5% for enwp and more than 1% for commons

For a lot of HTTP links in the database, the website is not dead. These fall in two categories:

• the website supports and enforces HTTPS with a redirect. These should probably be updated in the wikitext with an edit to point to HTTPS directly, so that it complies with a strict Referrer-Policy, and thus we won't lose provenance data for our partners and other external websites.
• the website supports HTTPS via HSTS preload. These don't need an edit because we already link directly to HTTPS in the HTML rendering of these articles, thanks to the SecureLinkFixer extension.

Note that browsers preserve the Referer header over redirects (including HTTP-to-HTTPS redirects, but also any other kind of HTTP 301 or 302 redirect, as well as cross-domain redirects). This means Referer data works today. Today, when folowing a link to http://creativecommons.org/compatiblelicenses from a Wikipedia article, the browser sends Referer: https://en.wikipedia.org/. The HTTP link redirects to HTTPS (possibly browser-side, based on HSTS or based on prior observed redirects), and then once more to https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/. Each of those carries the same Referer: https://en.wikipedia.org/ header throughout.

When I set strict-origin-when-cross-origin locally, the first request does not get the Referer header in Firefox, and later redirects, even on HTTPS, do not regain it.

From a quick search at https://en.wikipedia.org/wiki/Special:LinkSearch?target=http%3A%2F%2Fcreativecommons.org, the majority of these are in talk pages, discussion archives, and user pages. We may or may not want to update those.

For example, bbc.co.uk is on the HTST preload list known to SecureLinkFixer. This means the links at https://en.wikipedia.org/wiki/Special:LinkSearch?target=http%3A%2F%2Fbbc.co.uk don't actually refer to HTTP but to HTTPS. Example: https://en.wikipedia.org/wiki/User:Nerd42/biography refers to http://www.bbc.co.uk/worldservice/programmes/science_in_action.shtml in the wikitext, but the rendered HTML directly links to https://www.bbc.co.uk/worldservice/programmes/science_in_action.shtml. I filed T417323: Apply SecureLinkFixer earlier to include externalinks database and Special:LinkSearch about that.