Intent to Implement: getMemoryEstimateUASpecific

[Erik Chen]

Contact emails: erik...@chromium.org, hpa...@chromium.org

Explainer: link

Design doc/spec: N/A

Summary: Provide developers a mechanism to identify releases of their site that regress memory usage.

Motivation: This API provides a mechanism for web developers who use staged releases to determine that a release has increased memory usage in Chrome. This is similar to the chrome-only API performance.memory but accounts for all memory, rather than just JS memory. 

Risks [Interoperability and Compatibility]:

Edge: No public signals. During WebPerf WG they mentioned they might be interested if other vendors were interested.

Firefox: Neutral, leaning positive. There's been positive support but no explicit confirmation. There's concern about ability to fully implement. Open question is whether a partial-implementation provides utility to developers.

Safari: No public signals. During private discussions, they did not express strong interest, and had technical concerns during initial discussions with an early draft of the explainer.

Web Developers: GSuite, Gmail and Facebook have expressed interest in using this API.

Debuggability

No support requested.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The Chrome implementation will depend on site-per-process isolation [which is not yet rolled out to 100% on all six platforms].

Link to entry on the feature dashboard:

Link

Requesting approval to ship?

No

[Yoav Weiss]

Thanks for working on this! Would be exciting to see the use-case tackled in a non-proprietary way :)

--
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/CAEYHnr33vEm_JE7WfLxzXWSo8Ogg6aq16wQ4SjzyxtoZdzsFbA%40mail.gmail.com.

[a...@google.com]

Hi Erik,

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.

Cheers,

-Artur

[Thiemo Nagel]

Hey Erik,

following Artur's comments, could you please file for privacy review if you're moving forward with this proposal?

Thank you,

Thiemo

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c465bc32-117b-41cd-ba39-8a51dea16a8b%40chromium.org.

[Erik Chen]

This has been discussed off-thread with Chrome's privacy + security teams.

The current proposal on the table is to add a feature policy which makes all requests [including default no-cors requests] into cors requests. Combined with site-isolation, this means that the renderer will only contain readable (not embeddable-but-unreadable) resources. 

I've reopened the privacy review.

[Daniel Bratell]

The current proposal is made possible from a security point of view by site-isolation, where iframes that are from other domains will be moved to different processes. That is good, but it seems it will also reduce the usability of this feature.

The goal of the getMemoryEstimateUASpecific is to give web developers a way to detect when they have regressed memory usage and I suspect the most common way to regress is to add/change embedded ads. Those will not be included in these reports. We learned from ad blocking that ads can be a majority of the resource usage (cpu, battery, memory) on a site so it will matter.

I don't have any solution or suggestion here because it looks like a conflict with security whatever you do, but is this something you have thought about and do you have any idea for how to not accidentally lull the developers into false sense of complacency.

/Daniel

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/6c2637f7-9efd-4858-b38c-87c8d90898d5%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */