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

Skip to first unread message

Yoav Weiss

Mar 17, 2021, 11:59:50 AMMar 17
to blink-dev

Contact emails




Currently `` 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


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


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.


No API change, so N/A.


No API change, so N/A.


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.


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?


Mike West

Mar 18, 2021, 11:32:43 AMMar 18
to blink-dev, Yoav Weiss

I agree that this intent doesn't change the developer-facing contract of `` 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.


Chris Harrelson

Mar 18, 2021, 3:29:18 PMMar 18
to Mike West, blink-dev, Yoav Weiss

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
To view this discussion on the web visit

Daniel Bratell

Mar 22, 2021, 10:01:12 AMMar 22
to Chris Harrelson, Mike West, blink-dev, Yoav Weiss
Reply all
Reply to author
0 new messages