Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
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"?
Hey, author here. You're asking a couple questions, which I'll try to unpack.
You're right to be suspicious that Cloudflare CDN servers have the right time. I tried to call out that concern in the post. Cloudflare operates time services, but their CDN is not a time service and wouldn't be operated under the same controls. How accurate those servers are is an open question.
When writing the post I observed NTP client logs, a GPS-based clock, and the CDN-based clock report time that agreed within their stated error bounds. I've also seen NTP-synchronized and mobile network synchronized system clocks that fell outside the estimates of those other clocks. So it's an "odd one out" situation.
But I think you are asking the right questions!
their CDN is not a time service
No but time.cloudflare.com is. If I recall correctly, the server clocks are synchronised with the same time service. (Source: I work at Cloudflare)
Cool, thanks for taking a look! Do you know of any official reference for how the Cloudflare CDN server clocks are synced? I looked around but didn't find one.
I originally built the clock on Fastly, but they (appear to) have clock offsets of hundreds of milliseconds, so I didn't release that version. Cloudflare CDN seems synchronized better than what I can measure, although I'm wary of hard to test corner cases, like newly deployed servers.
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.)
Ooo, great find on the delay attack. I'll read up on that one today, but I think you're right.
The terms I'm using for this are web-native and a demo. Certainly not simple.
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.
