Threat model for isolating performance APIs

[yoavweiss]

The explainer suggests that all APIs behind performance (and performance.now() in particular) should be gated behind isolation primitives, but doesn't expand on why that should be the case.
Is it about avoiding explicit high-resolution timers in non-isolated contexts? Exposing resource load times? Both? Something else?

I'd love to understand the reasoning in order to see how we can continue to provide the performance measurement benefits of that API family without putting our users at risk.

[mikewest]

Hey, Yoav!

I think it's important that we give developers a solid understanding of the performance characteristics of their sites; that's good for users! Still, when doing so we need to consider the creation of new side-channels, and amplification of attacks using pre-existing channels. Chromium's "Post-Spectre Threat Model Re-Think" is a good recitation of the class of concerns I'm thinking of here.

The risks are somewhat broad, and we're still working out their contours. High-precision timers (SharedArrayBuffer, performance.now(), etc) certainly need to be part of the detailed threat model, as they're pretty clearly tied up with exploitation of side-channel attacks like Spectre/XSLeaks. Similarly, resource timing and memory APIs provide new capabilities that seem likely to create exploitable side-channels that reveal information about specific resources. It seems pretty reasonable to me to do our best to ensure that we're not providing more capability here than we intend.

It seems to me that COOP/COEP are a reasonable model for mitigations. If resources are obligated to opt-into exposing themselves to attack, it seems significantly less likely that they'll be inadvertently made available to malicious parties. Still, COOP/COEP might not be the best mitigation for every API you're thinking of, and we may be able to find more targeted solutions that leave some set of APIs in place more broadly. whatwg/html#5237 has some discussion around one such proposal; I'm not super-excited about that direction, but it's a conversation well worth having, and I expect we'll have more of those over time as we dive into the specific details of more APIs.

[yoavweiss]

High-precision timers (SharedArrayBuffer, performance.now(), etc) certainly need to be part of the detailed threat model, as they're pretty clearly tied up with exploitation of side-channel attacks like Spectre/XSLeaks

That seems reasonable. As a result of Spectre, high-precision timers were not removed from implementations, but curbed, making them significantly less high-precision. IMO, it would make sense to provide the high-precision variant only in isolated contexts, but that doesn't mean blocking the API in non-isolated ones, as least when it comes to performance.now() and DOMHighResTimestamp. A coarse version in non-isolated contexts seems like it would address many of the performance measurement use-cases without exposing users to further risk.

Similarly, resource timing and memory APIs provide new capabilities that seem likely to create exploitable side-channels that reveal information about specific resources

Regarding memory API proposals, I 100% agree that it makes sense to put them behind an isolated context opt-in.

Regarding Resource Timing, I'm less convinced. Detailed information already requires an explicit opt-in (Timing-Allow-Origin) and non-detailed timing shouldn't provide any information beyond what's readily available, e.g. with load events or Service Workers. Do you have specific examples of exploitation and how isolation would help to prevent it?

At the same time, I think it's worthwhile to talk about the relationship between TAO, CO{E,R}P and ACAO and see if we could unify some bits there.

[mikewest]

Hey Yoav! I'm archiving this repo. I think some of the questions here were dealt with via [CrossOriginIsolated] and/or https://www.w3.org/TR/post-spectre-webdev/? There are probably some left, but filing them elsewhere would be ideal. :)