Introduced in T138027; T262882 might be a dup?

This happens because our traffic layer shares the caches for /static across all domains. However, it seems the way we do that confuses the code creating the stat cookie.

It's not just /static, JavaScript and CSS files loaded with ?debug=1 like https://commons.wikimedia.org/w/extensions/Echo/modules/api/mw.echo.api.NetworkHandler.js?6dc51 and https://commons.wikimedia.org/w/skins/Vector/skinStyles/jquery.ui/jquery.ui.accordion.css?464c7 also cause the same warning (though I expect it's the same cause).
https://commons.wikimedia.org/wiki/Main_Page?debug=1&safemode=1 causes 72 of these warnings, and that's after Firefox removed all the duplicates (almost every request). This combined with T293109 make trying to debug actual JavaScript problems more difficult.

The URLs that use w/extensions, w/skins, and w/resources are also used outside debug mode, such as for background images referenced in minified stylesheets. These are served by WMF's static.php entrypoint, and cached in Varnish using the same hostname agnostic rules as for /static.

They can be fixed the same way indeed and are all part of the same logic that is largely characterised as "static" (/static, and misc things that map to /w/static.php).

Rather than excluding /static, perhaps it would make more sense to invert this logic and explicitly limit the cookie logic to text/html responses and/or /wiki requests. It seems like that should suffice in order to make sure this cookie is initiatlised during a session, and updated at least once on any subsequent day where a client device is active on a wiki. It doesn't need to be re-evaluated on every subresource request, and it most certainly doesn't need to be set on cross-origin requests from Wikipedia to upload.wikimedia.org, or meta.wikimedia, or login.wikimedia etc since browser reject those anyway. And even if they weren't rejected, it seems like that would only serve to skew the data wrongly to suggest a device was visiting that wiki when in actuality it wasn't. Anyway, I imagine Meta-Wiki isn't the most analysed wiki for these stats, and either way this bug was implicitly fixed once browsers rejected cross-origin cookies.

@Milimetric Who should we talk to to check whether this (minor) change would cause issues with the instrumentation?

This is still a problem today, and it makes for a distraction when debugging other cookie problems.

I second @Krinkle's idea from 2021 that the best solution for this might be to only set the cookie on HTML responses or if the path starts with /wiki.

Yeah, the wider issue here is that setting the cookie on cross-site subresource requests is probably harmful. Browsers apply all kinds of restrictions to cookies on such requests (e.g. can write but cannot read, or can read and write but the expiration will be different from what you set, or you see different cookie values for each parent domain you are making the cross-site request from) which will probably mess up the stats.

See also T375256: Cookie % has been rejected because it is foreign and does not have the "Partitioned" attribute for the Chrome equivalent.