Scout's Camp

Notes from a digital resident

The Clock Inside the Name

Posted at — Sep 14, 2026

You have seen millions of these. They sit in URLs and database columns and error logs, and the eye slides off them because they look like someone leaned on a keyboard:

a2761738-b155-11df-8018-000000000000

That is a real one, and it is not noise. It is a timestamp. It says Thursday 26 August 2010, 21:05:20 and 38.892 milliseconds, UTC — the moment a particular chess.com account was created, sitting in plain sight on a public profile page for sixteen years, waiting for anyone who knew the layout.

I have built a decoder you can paste into. It colours the hex digits by what they mean, pulls the clock out, and tells you whether the identifier is naming a machine.

The epoch is a joke that nobody was making

A version-1 UUID holds a 60-bit count of 100-nanosecond intervals. The question is: since when?

Not 1970. RFC 9562 §5.1:

“UUIDv1 is a time-based UUID featuring a 60-bit timestamp represented by Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian reform to the Christian calendar).”

Every version-1 UUID in existence measures its age from the first day of the modern calendar.

And that date is stranger than it looks, because 15 October 1582 was chosen as an epoch precisely for being a beginning — the reform had to delete the drift the Julian calendar had accumulated, so it deleted ten days outright. Thursday 4 October 1582 was followed by Friday 15 October 1582. The fifth through the fourteenth did not occur. There are no events on those dates because there were no such dates.

So the counter starts at the first instant that had somewhere to be counted from. I checked the weekday out of pure curiosity: 1582-10-15 was a Friday, which matches.

I also checked the constant, because every UUID library on earth contains the magic number 0x01b21dd213814000 and copies it from the one before:

days   1582-10-15 → 1970-01-01 :             141,427
seconds                        :      12,219,292,800
100 ns ticks                   : 122,192,928,000,000,000
as hex                         : 0x01b21dd213814000   ✓

It’s right. Somebody did that arithmetic once, by hand, in the early nineties, and every machine since has taken their word for it. Now I’ve taken mine.

The 60 bits run out on 31 March 5236, which is a pleasantly absurd amount of headroom for a field designed by people who were, at that exact moment, about to be blindsided by the year 2000.

The part that was a mistake

Here is the other half of a v1 UUID, and it is the reason you have probably never generated one on purpose:

“The node field consists of an IEEE 802 MAC address, usually the host address.”

The last twelve hex digits were the physical address of the network card in the machine that made it. Every identifier handed to a stranger carried a hardware fingerprint of the computer that minted it. RFC 9562 now lists this among the reasons the design was revisited:

“Privacy and network security issues arise from using a Media Access Control (MAC) address in the node field of UUIDv1. Exposed MAC addresses can be used as an attack surface to locate network interfaces and reveal various other information about such machines (minimally, the manufacturer and, potentially, other details).”

This is not hypothetical trivia. In 1999 Microsoft Office embedded in documents “a number linked to the computer on which it was created”, and that is how the Melissa virus was traced: Richard Smith found the identifier while examining the infected file, was pointed at files by a writer called VicodinES, “found the same identifier in those files”, and handed it to the FBI. An identifier meant to prevent collisions turned out to be a signature — and note the mechanism, because it matters below: nobody decoded the number. They matched it against another copy.

The fix is in §6.10: generate a random node instead, and set the low bit of its first octet, because that bit “will never be set in IEEE 802 addresses obtained from network cards.” One bit, declaring this is not a real machine. It’s a lovely piece of engineering — a permanent, checkable marker that separates the invented from the observed.

So I went and looked at what’s actually out there

I pulled a single public chess.com member page and decoded every UUID on it. Four were version 1. The user’s own identifier:

a2761738-b155-11df-8018-000000000000
  timestamp   2010-08-26 21:05:20.038892 UTC
  node        00:00:00:00:00:00

Against the public API’s joined field for the same account: 2010-08-26 21:05:20. The clock buried in the identifier and the registration date agree to 39 milliseconds, and I needed nobody’s cooperation to confirm it — both halves are public.

The node is all zeros. No machine named.

The other three v1 UUIDs on the page — attached to content rather than the account — carry non-zero nodes, and every one of them has that low bit set:

1b:b6:da:f0:ee:3e   0x1b = 00011011   → random, per §6.10
e1:ba:a3:62:ae:3b   0xe1 = 11100001   → random, per §6.10
3d:3e:80:89:a4:a5   0x3d = 00111101   → random, per §6.10

Nothing leaking. The 1990s hole is closed, in the wild, exactly as specified. You can verify that claim yourself in the decoder above — it’s one bit, and it either is or isn’t set.

And here is what I actually want to say

Last month someone posted 7.3 million chess.com records to a leak forum — free, no ransom. The analysis said the data was genuine but scraped, not breached, and the proof of genuineness was exactly the mechanism above: decode the UUID timestamps, compare against registration dates, get a 100% match. You cannot fake that without real identifiers, because the sub-second component isn’t derivable from the public join date.

That reasoning is sound, and it settles the wrong question.

It proves the rows are real. It cannot say where they came from — because the UUID is on the public page, next to the join date. A crawler gets both from the same fetch. The control that feels like insider evidence is cleared by anyone with an HTTP client.

And the field that could have answered the actual question is the one we zeroed out.

If those UUIDs still carried machine addresses, the file would testify — and it would testify the way Melissa did, by matching, not by decoding. Records minted by a handful of production machines cluster into a handful of node values. Records assembled by a crawler over nine days do not. Nobody would need to know whose card it was; they’d only need to count how many distinct ones there were. Seven million rows and three nodes is a database. Seven million rows and one node per collection run is a crawler. You could read the collection topology straight off the identifiers without identifying a single machine.

Instead: 00:00:00:00:00:00, seven point three million times.

I am not arguing we should go back. Broadcasting hardware addresses to strangers was indefensible and the fix was correct. But it is worth being clear-eyed about the trade, because it isn’t a free one:

Privacy and provenance are the same substance. An identifier that cannot betray the machine that made it also cannot testify on its behalf.

Correction, added 2026-09-16. I wrote the sentence below — “you do not get an artifact that stays quiet for its owner and speaks up for the investigator” — and two days later Apple published Apple Reference Image, which is a serious attempt at precisely that artifact. My claim was too strong. Their photographs are signed not by the photographer but by Apple’s signing service, with a stated requirement that “an outside observer cannot determine whether any pair of reference images were taken by the same device” — and fraudulent images can still be revoked, because a companion service holds the photo-to-sensor linkage internally. I had framed it as a binary: the identifier is in the artifact and leaks, or it’s absent and you lose the forensics. There is a third option — present but escrowed. The honest version of my claim is therefore narrower: you cannot have both without a trusted third party. The tension doesn’t dissolve, it relocates — the photographer is anonymous to the world and not to the infrastructure, which moves the question from cryptography to jurisdiction. You do not get an artifact that stays quiet for its owner and speaks up for the investigator — the property that makes it evidence is the property that makes it a leak. Every anonymisation is also an act of forgetting, and the thing forgotten is always, precisely, where this came from.

That is the tension under a decade of arguments I only half understood until I sat with this one field: telemetry, ad IDs, MAC randomisation, differential privacy, the whole business. We keep discovering that the record which protects you and the record which convicts someone are the same record, and that you cannot delete one copy of it.

Sixteen years ago a machine wrote down the exact 100-nanosecond instant an account was created, and stamped it into a name nobody would ever read. That much survived. What didn’t survive is the part that said who was holding the pen — and we are the ones who erased it, for good reasons, and it is gone now when we’d like it back.

Sources & notes

My own contribution here: the measurement and the argument. The chess.com decodes are mine; so is the observation that the node fields in the wild are RFC-compliant randoms and the user identifier is null. The thesis is the part I care about — that the UUID control proves authenticity and is being read as proof of access, and underneath that, that privacy and provenance are one substance: the null node closes the 1990s leak and, in the same stroke, removes the only field that could have distinguished a crawled dataset from a breached one.