Hi everyone,
We've got some fairly technical questions about Edge Uniques, so I wanted to follow up with what we've done in the last couple of weeks.
* As announced here, among other places, we had a call where we got some very good questions and comments. Thanks to those of you who turned up – we really appreciated it. To try to give better answers to some questions we've been asked then and elsewhere, we've put an FAQ here: https://meta.wikimedia.org/wiki/Edge_Uniques/FAQ * We've had some conversations about trust and how we can remain transparent about what this cookie does. To help ensure we can be scrutinized (now and in the future), we've worked on a guide to how you'd see any changes to Edge Uniques and how the data is collected. We call this a canary page: https://wikitech.wikimedia.org/wiki/Edge_uniques/Canary (see https://en.wikipedia.org/wiki/Sentinel_species#Canaries for an explanation of the name – "canary in a coal mine" is an English idiom for something which warns people about something happening). * We've added a timeline for when the cookie might start appearing in browsers, from the week of 19 May. This doesn't mean that everything will be up and running by then, but explains when the cookie might be first encountered by someone at all.
Best,
*Johan Jönsson*Manager, Movement Communications Wikimedia Foundation https://wikimediafoundation.org/
On Thu, Apr 24, 2025 at 11:12 PM Brandon Black bblack@wikimedia.org wrote:
Hi everyone,
If you follow any technical Wikimedia news, you might have read about this in Tech News or on Diff already, but in case you missed it: The Wikimedia Foundation is working on a system called Edge Uniques which will enable A/B testing, help mitigate DDoS attacks, and eventually give better visitor metrics.
We’re doing this by adding a first-party cookie named "WMF-Uniq" which is handled *only* on our CDN edge servers directly. This cookie contains a randomly-generated unique identifier and a few bits of minimal metadata about site visit history. We've explicitly designed this system such that we do *not* need to or intend to store these cookies or their identifiers in any databases or logs anywhere on our servers, or forward them to any other complex parts of our internal server-side infrastructure where the risks of accidental leakage or storage might be higher.
It's a fairly unique system, and one that we've tried to design for maximal privacy preservation and data minimization for Wikimedians while also meeting our needs around both A/B testing of reader-oriented features and helping to control the server load from botnets of various kinds with resource-abusive patterns.
The A/B testing portion of this design can record relevant, specific, pre-defined metrics into our analytics databases for those agents selected for testing (e.g. "an agent in Test123/GroupA clicked the new blue button"), but these metrics records use a temporary, per-experiment derivative identifier created by a one-way hash, making them non-reversible back to the original cookie identifiers.
You can read more details on Meta: https://meta.wikimedia.org/wiki/Edge_Uniques
If you want to talk to us about this, we’re happy to discuss it on the project talk page: https://meta.wikimedia.org/wiki/Talk:Edge_Uniques
We’re also hosting an office hours/community call to answer questions or discuss the topic further on April 29, 14:00 UTC. See more info here: https://meta.wikimedia.org/wiki/Edge_Uniques#Next_steps
-- Brandon Black Principal Site Reliability Engineer, SRE Traffic Team Wikimedia Foundation _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/