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.)