Address clock change risks

[jonathanmayer]

@rhelmer made the excellent point that we should think carefully about clock change risks. While a study extension is running, the system clock could change. That might be because of a user adjustment, or it might be because the operating system is synchronizing time (e.g., NTP) to account for clock skew.

After digging into this issue, it appears there are two different clocks we can use inside WebScience and study extensions.

• The ordinary system clock (i.e., new Date() or Date.now()). The upsides are that this clock is familiar to developers and typically accounts for skew on an ongoing basis (by default in major OSes). The downside is that this clock can change at any time, with no notice, while a study extension is running.
• The global monotonic clock specified by the High Resolution Time Level 2 standard (i.e., performance.timeOrigin + performance.now()). The upsides are that this clock is guaranteed to be monotonic from browser startup to shutdown, is unaffected by user clock adjustments, and typically accounts for skew with each browser startup. The downside is that this clock can reflect skew between browser startup and shutdown, introducing small timing errors for long-lived browsing sessions.

Our current WebScience implementation uses the system clock for all timestamps, except that when a page visit starts through ordinary navigation we use the global monotonic clock.

A few possible paths forward:

1. Use the global monotonic clock throughout WebScience and encourage study developers to also use that clock. I lean in this direction, since it avoids subtle bugs / unexpected behavior, introduces (likely) negligible timing errors, and is where the ordinary DOM Event.timeStamp property is headed anyway. We could also make this approach easy to maintain, by implementing a convenience function for the global monotonic clock (e.g., timing.now()) and an ESLint rule to warn for system clock usage in WebScience or a study extension.
2. Use the system clock throughout WebScience. This is pretty clearly a bad idea—we depend on clock monotonicity in pageManager and pageTransition, among other modules.
3. Use the system clock for external WebScience interfaces, but internally use the global monotonic clock (either throughout the library or where we need monotonicity). This approach would require carefully articulating some API semantics (e.g., if the system clock changes between pageManager page visit start and stop timestamps), but it's not implausible.

[rhelmer]

@rhelmer made the excellent point that we should think carefully about clock change risks. While a study extension is running, the system clock could change. That might be because of a user adjustment, or it might be because the operating system is synchronizing time (e.g., NTP) to account for clock skew.

I've dealt with this issue too but @Dexterp37 brought it to my attention recently re: webscience :)

This all sounds reasonable to me on first read, I'll dig into a bit more this week to make sure I understand.