Programming

I actually made a similar thing a few years ago, and mostly relied on WebSockets with a HTTP fallback: https://github.com/Steve-Tech/My_Time

You actually seem to know what you're doing with Workers though, mine was pretty much a half-assed attempt at porting my python code (which again could probably be better).

Also my desktop is PTP synced to a GNSS disciplined time server, and I've found the My_Time workers demo to be fairly accurate. I also feel Cloudflare should be reasonably accurate given they have database products you're intended to use with workers, but yeah, there's no guarantees.

If your device’s clock is set to the wrong time, it should tell you how far off the clock is set.

Why are we assuming that your HTTP-based method running in JS in a browser, using servers that are already distributed and time-synched with tech stacks that you have no insight into, is the "right time" and the directly NTP-synchronized clock of my machine is the "wrong time"?

The authenticated encryption of HTTPS similarly protects the CDN-based web clock approach. This avoids situations where an attacker-in-the-middle tampers with insecure NTP responses, messing up your system’s clock.

Almost... there is this fun thing called a delay attack that works despite encryption! (I'll admit that it's probably not a practical concern.)

Anyway, the article talks about time measurements through an absurd amount of abstraction layers. Please don't ever call this "simple" or even "cloud-native time" or the like.

If you start trying to improve this setup you'll find so many face-palm moments. Like TCP retransmissions (which the article mentions, to be fair). You'd have to use WebRTC to avoid that, which I bet the CDN network doesn't support. Or the fact that web browser timers have intentionally reduced precision to resist fingerprinting. (Granted, if you are still in the milliseconds range it is not a problem.)