I'm worried about the security consequences of this API, in particular the undoing of protections from side-channel attacks built into the performance.memory API
. getMemoryEstimateUASpecific seems to be both removing some of the original restrictions on performance.memory.usedJSHeapSize which sets much stricter rate limits and value quantization, and -- at the same time -- it's significantly increasing the scope of the feature by tracking not just the size JS objects, but sizes of all other resources (images, stylesheets, canvas, media elements, etc), most of which can be loaded cross-origin. The current design would make getMemoryEstimateUASpecific a convenient side-channel to disclose cross-origin resource sizing information and conduct related attacks.
A concrete attack based on the current proposal would be to load cross-origin resources from an attacking site and measure the amount of memory they consume. In this context expanding the scope to non-script resources is likely an even bigger problem than reducing the quantization of output values because it enables attackers to leak the sizes of arbitrary resources (as opposed to just scripts).
Note that the current approach outlined in the security section
of the explainer would likely be insufficient to prevent such attacks: rate limits don't help here because an attacker could establish a baseline for the amount of used memory offline, then load the resource(s) and measure the amount of memory exactly once -- the value computed in the victim's browser would reveal the amount of memory consumed by the resource. Similarly, adding noise is also problematic because an attacker can arbitrarily increase the size delta by loading the same resource many times (potentially also from the cache to avoid making many network requests), run the attack concurrently from multiple frames hosted in separate origins, and do statistical analysis to filter out the sizing noise added by the browser.
Overall, here are some points that are probably worth addressing in the explainer:
- Reconsider the overall security model of the API. In particular, adding noise to values returned by the API likely offers inadequate protection -- we had similar discussions about the Content Size Policy API which proposed a related approach, and here attacks would be much less time consuming, easier to conduct, and potentially more damaging.
- If finding a better security model seems impossible, and you believe the currently-proposed protections are the best approach, significantly reduce the granularity of the values return by the API. For example, perhaps it would make sense to time-cap the number of API calls from the same top-level window to once every 30 minutes, and have more coarse-grained buckets similar to usedJSHeapSize -- this doesn't seem to materially impact the usability of this API. It would also make sense to require browsers to implement these restrictions (rather than speccing them as a recommendation.)
- Remove the possibility of tracking information from related similar-origin browsing contexts
. This would allow be an SOP leak which would disclose sensitive information about same-site cross-origin windows. My guess is that any potential users of your API don't heavily rely on setting document.domain (we'd certainly view it as a high-risk vulnerability in Gmail) so you might be able to take into account only same-origin browsing contexts without making the API less useful.