• SteveTech@aussie.zone
    2 hours

    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.

  • tias@discuss.tchncs.de
    21 hours

    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”?

    • robalex@programming.dev
      11 hours

      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!

  • matsdis@piefed.socialEnglish
    19 hours

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

    • robalex@programming.dev
      11 hours

      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.