It's a reasonable requirement on the server side to say that all clocks *must* be within 5 seconds of real UTC, and if they're not, we're broken and should alarm for operator attentoin. We can/will/do have monitoring for this in prod.
-Mark On Wed, Feb 19, 2014 at 12:20 PM, Richard Newman <[email protected]>wrote: > > One approach we took was that the Server Timestamp is generally > > distributed with every response from the server (The "Date:" header). > > The client simply recorded the difference between the server and local > > clock skew, and added that difference to the TS value used in the OAuth > > headers. > > That's pretty much the approach Hawk takes: the timestamp range limitation > approximates the circular buffer of nonces, and the clients use the server > timestamp to correct their time for the purpose of authenticating to that > particular server. > > The issue here is that we have three tiers of servers, each of which's > clock might differ, the third tier of which can change (different storage > servers), and a client clock that can be adjusted while we're working. Add > in questionable latency and the temptation to persist skews across > restarts, and things become complex -- and, I might add, complex without > eliminating some non-trivial percentage of errors. > > The OpenSignal folks suggest using the realtime clock in combination with > some kind of anchoring ping to simulate an independent monotonic clock on > Android. That seems like a reasonable idea -- "fake NTP". > > But the fact remains that this seems like a spiderweb of complexity that > doesn't really meet our needs... > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
