Intent to Ship: Align performance API timer resolution to cross-origin isolated capability

151 views
Skip to first unread message

Yoav Weiss

unread,
Mar 17, 2021, 11:59:50 AM3/17/21
to blink-dev

Contact emails

yoav...@chromium.org

Explainer


https://docs.google.com/document/d/1MpG4sBbfZ5xzXCH1GcUjKPuQndkt_kD0LJ7NfpJJ65s/edit#heading=h.f5lcp6q4pi0q

Specification

https://w3c.github.io/hr-time/#dfn-current-high-resolution-time


Summary

Currently `performance.now()` and related timestamps are coarsened based on site isolation status. This change will align their coarsening based on cross-origin isolation capability, regardless of platform. That would decrease their resolution on desktop from 5 microseconds to 100 microseconds in non-isolated contexts. It would also increase their resolution on Android from 100 microseconds to 5 microseconds in cross-origin isolated contexts, where it's safe to do so.


This change will also coarsen `performance.timeOrigin()`, to align with the spec.


Blink component

Blink>PerformanceAPIs

TAG review

I asked the TAG on a related review whether this requires a separate request, but haven't yet heard back. Since this feature does not change any API shape and the related subject of limiting features to isolated contexts was discussed, I tend to think a full TAG review is not required.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

From an interop risk perspective, there's no risk to coarsening timers on Desktop, as other vendors already coarsen their timers beyond what we do (1ms in both Firefox and Safari).

On the front of refining timer resolution in isolated contexts, Mozilla plans to follow that path as well. (clamping timers to 20 microseconds)

There's some risk that Apple may not follow, but even if they don't, the risk to user-facing interop is small, as the platform had timer granularity differences for a while now. From a compatibility risk perspective, as this aligns clamping with the current default on Android, and as other vendors have tighter restrictions, there's little to no risk that current content relies on 5 microseconds timer resolution on Desktop.



Gecko: Worth prototyping 
Firefox implemented this and clamped to 20 microsec in isolated contexts

WebKit: No signal (but I just sent the request, so...)

Web developers: No signals
The feature is not highly developer facing, so I wouldn't expect developers to care a whole lot either way. The main beneficiary here is users and their data.

Ergonomics

No API change, so N/A.



Activation

No API change, so N/A.



Security

Reducing timer granularity in non-isolated contexts increases security. Increasing granularity in isolated contexts is safe, as resources that are loaded in those contexts have opted-in to being embedded, providing guarantees that they don't contain secrets.



Debuggability

No API change, so mostly N/A. One note is that for User-Timing, the DevTools timeline will now have finer-grained timestamps than the ones exposed to the web, in order to enable fine-grain debugging/measurement there, even for marks and measures that result in the same web-exposed (coarse) timestamps.



Is this feature fully tested by web-platform-tests?

Yes

Mike West

unread,
Mar 18, 2021, 11:32:43 AM3/18/21
to blink-dev, Yoav Weiss
LGTM1.

I agree that this intent doesn't change the developer-facing contract of `performance.now()` in a way that seems useful to get the TAG's advice. It has explicit support from Mozilla, and Apple's comments seem to support the direction in which this intent pushes the granularity of the mechanism, though leaving clear disagreement about exactly how far to push it (they'd like an additional order of magnitude).

From a security perspective, this change is a clear improvement to the status quo, and is aligned with our general interest in limiting trivially high-precision timers to cross-origin isolated contexts (see also the `SharedArrayBuffer` intent).

I'd like to see some follow-on work done to see if we can get a little more alignment between browsers around the resolution that developers can expect in various contexts. It would be ideal if we could share a threat model, at least, even if we don't all ship exactly the same resolution given the differences in architectural nuance.

-mike

Chris Harrelson

unread,
Mar 18, 2021, 3:29:18 PM3/18/21
to Mike West, blink-dev, Yoav Weiss
LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/977e1759-6935-40dc-a2a0-2fcc0288bd2bn%40chromium.org.

Daniel Bratell

unread,
Mar 22, 2021, 10:01:12 AM3/22/21
to Chris Harrelson, Mike West, blink-dev, Yoav Weiss

LGTM3

/Daniel

Reply all
Reply to author
Forward
0 new messages