No, it's related to the parent task (T345245: Mitigate phase-out of third-party cookies in Wikimedia production). Although technically it's not even MediaWiki, these specific cookies are handled by Varnish I think.

This only affects cookies on cross-domain requests. Not sure if that's a problem. The logspam can be prevented by setting the Partitioned cookie attribute, as the message suggests. Currently the cookies are blocked (ie. the browser does not send them on cross-domain requests); if they are partitioned, the browser will create a separate cookie jar (corresponding to the (document domain, cookie domain) tuple) and use that for cross-domain requests from the given document domain. (Which might be even worse for analytics?)

cc @Milimetric should we follow upon this?

@mforns to confirm whether this is indeed impacting unique devices reporting.

Seems like all of these Varnish-level cookies mentioned at the top should at least gain appropriate, explicit SameSite= attributes, in addition to perhaps Partitioned as appropriate (only NetworkProbeLimit currently carries a SameSite attribute at all).

Do we have a specific example of a URL and which cookies triggered the rejections? In my own quick repro attempt, I only saw them failing on actually cross-domain traffic (in my case, an enwiki page was loading Math SVG content from https://wikimedia.org/api/..., and it was the cookies coming with that response that were rejected).

In T375256#10259757, @BBlack wrote:

I only saw them failing on actually cross-domain traffic

That's expected. I haven't tested but pretty sure browsers don't block or partition same-domain cookies.
(Probably not even same-site cookies, ie. the registrable domain has to be different.)

Not sure if this affects anything. Without the SameSite=None and Partitioned attributes, the browser will refuse to send the cookie on an AJAX request, Varnish will see there is no cookie, and will try to set one... not sure but I think that would also fail? If it succeeds that could mess up analytics.

(With Partitioned, there will be different cookies for every registrable domain the AJAX request is made from, which messes up analytics even more. Probably the best thing to do is to not set or read cookies on cross-origin requests.)

I don't think it's necessarily always up to us to be able to know it's cross-origin, though, right? It would depend on the $random_other_site's CORS whether they tell us about a referrer at all?

I think all the browsers that do third-party cookie blocking also set Sec-Fetch-Site: cross-site on cross-site requests.

Ah interesting! We should confirm that and perhaps avoid the set-cookie entirely on cookies that are (or at least are intended to be) ~ SameSite=Lax|Strict then, I guess?

@mforns to confirm whether this is indeed impacting unique devices reporting.

@mforns can you verify this?

Will do.