901982 - Prevent client clock skew from impacting metrics on submitted data

Status: RESOLVED WONTFIX

(Firefox Health Report Graveyard :: Client: Desktop, defect)

Description

[Daniel Einspanjer [:dre] [:deinspanjer]]

We currently have bug 818339 which mentions reporting the client clock skew, but we also need to attempt to fix the skew at least as far as not having it pollute the submitted data with bad dates.

Here is a proposal which involves lazy detection (prevents doubling the overall number of requests to the server) and client-side correction when significant skew is detected.

When client is in the neutral state (no current skew detected):
1. Client records the current system time as a valid epoch.
2. Client submits payload using that epoch and all recorded date values as-is.
3. Client retrieves a UTC epoch value from the server response and compares it to the recorded epoch.
4. If the response epoch is within PERMITTED_SKEW (e.g. 1 hour) of the recorded epoch, client does not change from neutral state.
5. If the response epoch is outside PERMITTED_SKEW, the amount of skew is recorded as the known skew for this submission date and the client moves into active correction state

When the client is in the active correction state:
1. Client records the current system time as an epoch.
2. Client pings the server requesting the current canonical epoch.
3. Client evaluates the delta between the two epochs and records the delta as the skew (or non-skew) for the data between last submission and this one.
4. Client corrects any time values in recorded data for time periods that have a recorded skew value
5. Client submits payload to server
6. If the delta of the latest epoch is within PERMITTED_SKEW, the client switches back to neutral state.

Comment 1

[Richard Newman [:rnewman]]

Two complications:

* Clocks jump around, particularly on mobile. Any attempt to fix that on our side converges on building NTP. 
* The FHR clients record integer day, not timestamp. Once recorded we no longer have granularity to do correction.

Pretty much the only sane approach I can think of that fits those constraints is to basically build a local clock using elapsedRealtime and periodic server contact, using that to sanity check the wall clock at time of recording. But I question the effort/reward tradeoff there.

Comment 2

[Georg Fritzsche [:gfritzsche]]

We want to measure client clock skew for Telemetry per bug 1040741, that is our current plan to deal with these issues.