Just want it noted that if we can have cross-domain (not just cross-subdomain) session ID (e.g. track a session across Wikipedia languages, Wikimedia Commons, Wikidata, Wikivoyage languages, etc.) that would be AMAZING.

@jlinehan: In which codebase would such changes have to take place?

Based on grooming:

• not something we need to put in MVP until we have extra time
• not a blocker to MVP

☝️ We're using the per-project session ID for now. We settled on and have continued to iterate on a model, which is flexible enough that we could integrate a new cross-subdomain session ID in future.

IIRC @mpopov and I discussed this in Slack some time ago and arrived at a potential solution: Have Varnish derive one or more session cookies from Edge Unique cookie, e.g.

$crossDomainSessionCookie = hash( $edgeUnique, $secret );
$perDomainSessionCookie = hash( $domain, $crossDomainSessionCookie );

We could even extend this to per-interval session cookies:

// e.g. 2025-06-17 16
$hour = date( 'Y-m-d H' );

$perHourCrossDomainSessionCookie = hash( $hour, $crossDomainSessionCookie );
$perHourDomainSessionCookie = hash( $hour, $perDomainSessionCookie );

Like the Edge Unique cookie, the cookies would be shared across 2LDs – enwiki and dewiki would receive the same session cookies but not enwiki and commonswiki.

sounds like we'd need to re-vet Edge Uniques design if we derive more IDs from it.

In T267217#11393091, @Milimetric wrote:

sounds like we'd need to re-vet Edge Uniques design if we derive more IDs from it.

You're right. My comment wasn't well thought out. I was too focussed on solving a problem. I should have said something like:

Cross-domain-ness here will be achieved by using a cookie because localStorage and sessionStorage are tied to the origin. The Edge Unique cookie has a couple of desirable properties that we'd want to replicate for such a cookie:

1. It's managed by the server: Session identifiers are generated on the client, which have varying levels of support for and implementations of the Web Crypto API
2. It's verifiable: We trust session identifiers generated on those clients implicitly
3. It's 3LD where it counts: The Edge Unique cookie is broadly 2LD but an exception is made for .wikimedia.org subdomains as some of them are hosted by third parties
4. …

However, if we did want to create such a cookie, we'd design and implemented it to be totally distinct from the Edge Unique cookie.