Intent to Implement and Ship: performance.memory improvements

[Timothy Dresser]

Contact emails

tdre...@chromium.org

Explainer

Doc

Design doc/Spec

This API is unspecified.

Summary

performance.memory is an unspecified API, seeing significant usage from some of our partners. Other browser vendors are currently uninterested in pursuing an API exposing concrete numbers for memory usage.

Site isolation results in two changes to this API:

• With site isolation, we group same origin tabs into the same process more frequently. With the current API, this makes the numbers harder to interpret, as we mix data for a varying number of tabs.

• Site isolation prevents putting different origins into the same renderer process, eliminating an avenue for possible side-channel attacks.

In response to site isolation, we propose the following changes:

• If multiple tabs are grouped into the same process, return null for the total and used JS heap size.

• If full site isolation is enabled, remove the coarse quantization and delay from values we report.

Motivation

Site isolation is reducing the utility of performance.memory. It also provides an avenue for easily increasing the accuracy and timeliness without risk of side-channel attacks.

We have key partners requesting higher quality data from performance.memory.

Ideally, we’d ship a standardized API for this, and we intend to do so in the future, but at the moment there’s no interest from other browser vendors in a solution that would meet our partners needs.

Risks

Interoperability and Compatibility

This feature is unspecified, which inherently causes some interop and compat risk.

The only additional risk is that some developers may currently depend on these APIs not returning null.

Other browser vendors are generally not in favor of this proposal. The primary concerns are:

• Security / interop issues

• We’ll ensure to get Chrome security / privacy review before shipping this change.

• High memory use isn’t inherently bad.

• This is true, but this API enables A/B testing, leak detection etc that is much more difficult with higher level APIs.

Much of the discussion here hasn’t been recorded, but there’s some notes here and here. The following is a rough sense of where other vendors stand with respect to implementing a standardized memory API which exposes memory consumption numbers. This has been discussed some here.

Edge: Negative signals in person

Firefox: No signals - open bug here

Safari: No signals (“Unsure” about this approach)

Web developers: We see ~13% of page loads (via UseCounter V8MemoryInfo_UsedJSHeapSize_AttributeGetter)  using this API on the web today, despite the issues with its accuracy and ease of use. Developers are often frustrated by the restrictions placed upon it for security purposes. OOPIF gives us an opportunity to easily make this API easier to use, and the results more actionable.

There are no interop tests, as this is unspecified.

Going forward, we must find a way to standardize an API which addresses these use cases. The memory pressure API is the current best candidate, but it doesn’t address all use cases. In particular, it doesn’t provide good signal for A/B testing memory usage of different site versions.

Ergonomics

The ergonomics of this feature are unchanged.

Activation

Developers will immediately benefit from these changes.

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

No. Android is not supported today, and we don’t intend to extend support further without a plan for standardization.

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

No, as this isn’t standardized. There is limited LayoutTest coverage.

Link to entry on the feature dashboard

Link

Requesting approval to ship?

Yes

[Daniel Bratell]

We discussed this at the API owners meeting today and concluded that this change does not require API owner approval.

(Personal comment: There are things to get right considering security and privacy but that will be implementation details rather than API details)

/Daniel

--
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/CAHTsfZB%2B4cvTB7D4LauULCtm0Uv746LeV7C%2BtkqEgqTd-EF-cg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Ilya Grigorik]

On Thu, Feb 1, 2018 at 11:09 AM Daniel Bratell <bra...@opera.com> wrote:

We discussed this at the API owners meeting today and concluded that this change does not require API owner approval.

Curious, what was the reasoning behind punting on this? We have many cases where we're revisiting / considering updating old ("pre i2i/i2s") APIs, what's the criteria for requiring owner approval?

[Rick Byers]

I wasn't able to make this meeting, but here's what I said on an internal thread about this:

If there are customers who say they get substantial value from it, then I'm OK keeping it in as long as we have a plan to eventually replace it with something standardized which we'd be prepared to prioritize if other browser vendors asked us to collaborate.  If no other engine currently has any interest in a memory API and we have customers who strongly prefer we keep it, then I don't see that much harm in keeping it around (it's not likely that users notice the site is somehow better in Chrome).

And yes I think you could reasonably argue that reporting incorrect values in the case of process sharing is just a bug that you could likely just fix.  There's some compat risk, but my intuition is that it's pretty low and probably not worth being too proactive about - i.e. if sites break in practice due to the null then maybe we just need to return zero values or something.

...

The argument I'll make on the intent is that interop risk is all about cost/benefit tradeoff.  When we're designing a new API, spending even 4x more to design it in a way that's more likely to get others to follow even when there's currently no interest (high quality spec, web-platform-tests) is absolutely worthwhile.  In a perfect world we'd write a new WICG spec and whatnot for this (and while we're add it remove every non-specced behavior we have in blink), but ultimately we need to prioritize bang-for-the-buck.  If there's a couple tiny tweaks we can make to an existing non-standard API to get the same customer value as a >100x larger investment in a new standards-track API would get us AND there's currently no interest from other vendors in the use cases AND no user-visible behavior difference of popular sites with/without this API then I think we'd get much greater return on our WebPerf standards investment elsewhere (clearly Tim's team has no shortage of high-value WebPerfWG work to do) and just push the debt forward on this one...

--

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

[Chris Harrelson]

Our reasoning was that because this is an existing API and all that is changing is an "implementation detail" of how it arrives at the statistics returned by the API to be more accurate, it does not require API owner review. IOW, just a bugfix but not significant semantic change. (I think a public PSA is a good idea for a change this though, so appreciate greatly the email to blink-dev.)

We also had a discussion about whether we should advocate for removal of the API due to not being standard, and there being opposition from other browsers to such a standard being created, but in the end concluded we didn't have much reason to force this course of action. Two main reasons:

(a) it's not policy to unship APIs just because they were not standardized in the past (additional reasons are needed, or data to show it is almost unused)

(b) the API in this case likely provides real value to sites even if it is just implemented in Chrome, and taking action to reduce app memory use Chrome most likely improves performance on all browsers.

Chris

 

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADXXVKp3fmoKV2r5cDqVUPPFGiOPmOdR_w7axUz2nR3jwb9m7A%40mail.gmail.com.

[Ilya Grigorik]

Rick, Chris: thanks for the detailed context, makes sense.

A couple of quick comments on past discussions of memory related APIs in webperf WG:

• There was/is interest in exposing some memory related telemetry from vendors. The scope of problem varies from browser to browser and hardware that it runs on but some motivating use cases were:  OOMs due to poor site implementation (e.g. infinite lists that don't prune memory), low memory devices under constant memory pressure, and the too-many-damn-tabs problem.
• We heard pushback on exposing ~memory bytes as a signal. In no particular order: 
• engines differ in how they use and allocate memory and without context this is not a useful signal on its own because there is nothing wrong with using more memory if its available
• concerns around incentivizing engine specific optimizations from developers, which are subject to change
• performance concerns: what should be counted, how often, stop-the-world vs, .... 
• lots of security and privacy unknowns
  
• There was general consensus that a first step could be to expose memory pressure as signal to developers
• It avoids most of the above while nudging developers towards optimizing in cases that matter
• It maps cleanly to existing mobile primitives / "easy" to implement
• As a related but separate initiative, we exposed memory device class. 

This is *not* an exhaustive list of all the past discussions, but just FYI.

On Thu, Feb 1, 2018 at 9:07 PM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Feb 1, 2018 at 7:51 PM, 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

On Thu, Feb 1, 2018 at 11:09 AM Daniel Bratell <bra...@opera.com> wrote:

We discussed this at the API owners meeting today and concluded that this change does not require API owner approval.

Curious, what was the reasoning behind punting on this? We have many cases where we're revisiting / considering updating old ("pre i2i/i2s") APIs, what's the criteria for requiring owner approval?

Our reasoning was that because this is an existing API and all that is changing is an "implementation detail" of how it arrives at the statistics returned by the API to be more accurate, it does not require API owner review. IOW, just a bugfix but not significant semantic change. (I think a public PSA is a good idea for a change this though, so appreciate greatly the email to blink-dev.)

We also had a discussion about whether we should advocate for removal of the API due to not being standard, and there being opposition from other browsers to such a standard being created, but in the end concluded we didn't have much reason to force this course of action. Two main reasons:

(a) it's not policy to unship APIs just because they were not standardized in the past (additional reasons are needed, or data to show it is almost unused)

(b) the API in this case likely provides real value to sites even if it is just implemented in Chrome, and taking action to reduce app memory use Chrome most likely improves performance on all browsers.

Chris

 

--
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.

[Rick Byers]

On Fri, Feb 2, 2018 at 6:43 PM, 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

Rick, Chris: thanks for the detailed context, makes sense.

A couple of quick comments on past discussions of memory related APIs in webperf WG:

• There was/is interest in exposing some memory related telemetry from vendors. The scope of problem varies from browser to browser and hardware that it runs on but some motivating use cases were:  OOMs due to poor site implementation (e.g. infinite lists that don't prune memory), low memory devices under constant memory pressure, and the too-many-damn-tabs problem.
• We heard pushback on exposing ~memory bytes as a signal. In no particular order: 
• engines differ in how they use and allocate memory and without context this is not a useful signal on its own because there is nothing wrong with using more memory if its available
• concerns around incentivizing engine specific optimizations from developers, which are subject to change
• performance concerns: what should be counted, how often, stop-the-world vs, .... 
• lots of security and privacy unknowns
  
• There was general consensus that a first step could be to expose memory pressure as signal to developers
• It avoids most of the above while nudging developers towards optimizing in cases that matter
• It maps cleanly to existing mobile primitives / "easy" to implement
• As a related but separate initiative, we exposed memory device class. 

This is *not* an exhaustive list of all the past discussions, but just FYI.

Thanks for the context Ilya, this is good to have.

The key use case I believe developers have for these memory APIs today is detecting memory regressions (and locking in improvements) in their own code.  It's true you can't meaningfully compare these values across different browsers (or even necessarily different versions of the same browser).  But holding the browser and target OS constant, it's clear developers using this API are getting a meaningful signal today about how the behavior of their own code is changing.

On Thu, Feb 1, 2018 at 9:07 PM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Feb 1, 2018 at 7:51 PM, 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

On Thu, Feb 1, 2018 at 11:09 AM Daniel Bratell <bra...@opera.com> wrote:

We discussed this at the API owners meeting today and concluded that this change does not require API owner approval.

Curious, what was the reasoning behind punting on this? We have many cases where we're revisiting / considering updating old ("pre i2i/i2s") APIs, what's the criteria for requiring owner approval?

Our reasoning was that because this is an existing API and all that is changing is an "implementation detail" of how it arrives at the statistics returned by the API to be more accurate, it does not require API owner review. IOW, just a bugfix but not significant semantic change. (I think a public PSA is a good idea for a change this though, so appreciate greatly the email to blink-dev.)

We also had a discussion about whether we should advocate for removal of the API due to not being standard, and there being opposition from other browsers to such a standard being created, but in the end concluded we didn't have much reason to force this course of action. Two main reasons:

(a) it's not policy to unship APIs just because they were not standardized in the past (additional reasons are needed, or data to show it is almost unused)

(b) the API in this case likely provides real value to sites even if it is just implemented in Chrome, and taking action to reduce app memory use Chrome most likely improves performance on all browsers.

Chris

 

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADXXVKp3fmoKV2r5cDqVUPPFGiOPmOdR_w7axUz2nR3jwb9m7A%40mail.gmail.com.

--
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/CADXXVKpubsATkq1wBQovoN9YhNQpvfYtQHukyFvg%3DJ_42ej53A%40mail.gmail.com.

[Boris Zbarsky]

On 2/5/18 3:59 PM, Rick Byers wrote:
> But holding the browser and target OS constant, it's clear
> developers using this API are getting a meaningful signal today about
> how the behavior of their own code is changing.

In some cases. And in some cases they're likely trading off memory
included in the performance.memory numbers for memory not included in
them, and getting a misleading measurement of the actual memory changes.
Assuming we can even define "actual memory changes" and that they
actually care about them.

This sort of think can be a pretty useful tool for someone who
understands both how the numbers it reports map onto actual engine data
structures _and_ how their code maps onto those data structures.
Without both sets of understanding, it's pretty easy to be going
sideways or backwards while thinking you're going forward. Doubly so if
you get creative about trying to optimize the metric.

I agree that as a "something is up" early-warning detection this sort of
thing can be useful, of course.

-Boris

[Rick Byers]

On Mon, Feb 5, 2018 at 4:44 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 2/5/18 3:59 PM, Rick Byers wrote:

But holding the browser and target OS constant, it's clear developers using this API are getting a meaningful signal today about how the behavior of their own code is changing.

In some cases.  And in some cases they're likely trading off memory included in the performance.memory numbers for memory not included in them, and getting a misleading measurement of the actual memory changes.  Assuming we can even define "actual memory changes" and that they actually care about them.

This sort of think can be a pretty useful tool for someone who understands both how the numbers it reports map onto actual engine data structures _and_ how their code maps onto those data structures. Without both sets of understanding, it's pretty easy to be going sideways or backwards while thinking you're going forward.  Doubly so if you get creative about trying to optimize the metric.

Yeah, point taken for sure.  This is a good argument for trying to invest in something better - and I know that's on our backlog for WebPerf.  But it's not clear to me how we can address this important developer need with a precisely specified API that is efficiently implementable in all engines.  Eg. With site isolation we have the opportunity in chromium to expose a more meaningful number - private bytes of the site's renderer process, but we've avoided doing so due to the interop challenges (and so are stuck with the status quoa of a loose-loose situation having both a dangerously misleading API and something non-standard).  Any suggestion on how best to resolve the tension here?  I'd love to replace Chrome's non-standard API with something at least a little better on the standards-track.  For example, do you think it would be crazy to try to define an API which is the browser's best guess of the page's contribution to total memory usage?

I agree that as a "something is up" early-warning detection this sort of thing can be useful, of course.

-Boris

--
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/143b862b-30f7-c018-3766-8af9dbb3470e%40mit.edu.

[Boris Zbarsky]

On 2/5/18 5:32 PM, Rick Byers wrote:
> But it's not clear to me how we can address this important
> developer need with a precisely specified API that is efficiently
> implementable in all engines.

Right. It's not entirely clear to me either.

> For example, do you think it would be crazy to try to define an API which is the
> browser's best guess of the page's contribution to total memory usage?

Not a priori crazy, but having such a guess that is:

1) good
2) zero performance overhead (or close to it) if no one asks for it
3) quick to compute when asked for, even in the face of a large heap

is a bit of an engineering challenge. For example, Firefox has a thing
that has properties (1) and (2) but not (3). And a separate thing that
has properties (2) and (3) but not (1)... Obviously something that does
not have property (2) is a non-starter. ;)

Sorry, I wish I had answers here too, because I agree that having a good
way for sites to detect when they're doing crazy stuff with memory via
telemetry would be good.

-Boris

[Rick Byers]

Ok, thanks for your thoughts and encouragement Boris.  And sorry for taking this intent thread on a tangent, I realize I should have put this discussion in a WebPerf WG github issue.

Worst case perhaps we'll eventually ship something that only has all three properties in Chrome today, but at least developers will use that to fix their memory issues which mostly hurt performance across all browsers.  I certainly worry about developers making performance improvements that over-target specific engines, but it's not like we don't already have that problem today (even with carefully specified WebPerf APIs) - I'm not sure we'd be likely to make it much worse.  One option could be to spec it to allow the UA to return 'null' when it felt it couldn't provide a good answer (eg. our site-sharing-a-single-process scenario), and then an engine could achieve #2 and #3 through amortization (eg. return a value no more than once a day, or something like that).

Rick

[Erik Chen]

Hi Boris,

 

Not a priori crazy, but having such a guess that is:

1) good
2) zero performance overhead (or close to it) if no one asks for it
3) quick to compute when asked for, even in the face of a large heap

We've put together a work-in progress spec in a private github repo that we believe satisfies these properties. This requires an additional constraint:

• There is only a single top-level frame being hosted in the process.

In Chrome, this constraint will increasingly often be true as we move towards a site-isolated world. I believe the other browser vendors are also moving in that direction. When this constraint is true, we can use per-process accounting from the OS to return a metric that satisfies all the desired constraints.

Thoughts/feedback welcome. 

[Boris Zbarsky]

On 2/27/18 10:50 AM, Erik Chen wrote:
> We've put together a work-in progress spec in a private github repo

> <https://github.com/erikchen/performance-memory/blob/master/explainer.md> that

> we believe satisfies these properties. This requires an additional
> constraint:
>

> * There is only a single top-level frame being hosted in the process.

Erik, thank you for the link.

I'm not sure this constraint is sufficient, but it may depend on what
you mean by this constraint. For a specific worrisome example, say a
page at origin A window.open()s a page at origin B which loads a
subframe from origin A. That subframe and the original page are in the
same process (because they have synchronous DOM access to each other,
per spec). The page from origin B is in a different process. In this
case, is the process with the two origin A frames satisfying your
constraint? Or put another way, does "single top-level frame" mean
"there is only one top-level frame" or "there is only one frame and it
is top-level" or something else?

The "usedJSHeapSize" and "totalJSHeapSize" may or may not satisfy my
three criteria, depending on how one defines "JS heap". For example, is
the backing store of an ArrayBuffer part of the "JS heap"? Is the
backing store of a CanvasRenderingContext2D? The backing store of an
XMLHttpRequest that has a bunch of responseText? Note that from an
implementation point of view the answers might be different, and the
proposed implementation outline says so, but, critically, they might be
different across implementations too. As a specific example, nothing
says that CanvasRenderingContext2D can't be implemented internally on
top of an ArrayBuffer when done off the GPU; same thing for
XMLHttpRequest. And there may well be good reason for doing it that
way. For example, one might want to self-host XMLHttpRequest on top of
the fetch API.

As another example, servo uses the "JS heap" for allocating all of its
DOM objects[1]. So the "does not include memory of objects used by the
DOM" claim would be false there. Computing a "usedJSHeapSize" that
_excludes_ DOM objects would not have the three properties I posited we
want in servo. Computing one that _includes_ them would not have those
properties in Blink or Gecko as of today, as far as I know.

-Boris

[1] DOM objects in servo have a part that's allocated from the
"JS heap" and a part that is not. The exact split of memory between
them has been and will be in flux; there are proposals to allocate
entirely from the "JS heap" for small enough objects...

>
> In Chrome, this constraint will increasingly often be true as we move
> towards a site-isolated world. I believe the other browser vendors are
> also moving in that direction. When this constraint is true, we can use
> per-process accounting from the OS to return a metric that satisfies all
> the desired constraints.
>
> Thoughts/feedback welcome.
>

> --
> 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
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25929fd9-9b6c-4174-a986-7171e6045ecf%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25929fd9-9b6c-4174-a986-7171e6045ecf%40chromium.org?utm_medium=email&utm_source=footer>.

[Erik Chen]

Erik, thank you for the link.

I'm not sure this constraint is sufficient, but it may depend on what
you mean by this constraint.  For a specific worrisome example, say a
page at origin A window.open()s a page at origin B which loads a
subframe from origin A.  That subframe and the original page are in the
same process (because they have synchronous DOM access to each other,
per spec).  The page from origin B is in a different process.  In this
case, is the process with the two origin A frames satisfying your
constraint?  Or put another way, does "single top-level frame" mean
"there is only one top-level frame" or "there is only one frame and it
is top-level" or something else?

Hi Boris, thanks for the fast response! The goal of the API is to return null in the case that you described. What do you think of the following updated wording:

"""

The results are non-null if and only if all frames hosted by the process are part of a single frame tree.
"""

[Erik Chen]

Hi Boris!

Hannes and I have updated the proposal based on feedback from facebook and gmail/gsuite. If you have further feedback, we'd love to hear it. If not, that's okay too, but please let us know so we know not to wait for your feedback.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/no00RdMnGio/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e41d23d-1a92-45ba-8c14-d54962b4846c%40chromium.org.

[Boris Zbarsky]

On 3/9/18 11:01 AM, Erik Chen wrote:
> If you have further feedback, we'd love to hear it. If not, that's okay
> too, but please let us know so we know not to wait for your feedback.

Erik,

I somewhat worry about numberOfTabs exposing cross-origin information
about what frames other sites are loading things from. Maybe that's
already exposed by window[n] access, but worth thinking about carefully.

I think that's all for feedback on the changes. My previous comments on
usedJSHeapSize/totalJSHeapSize stand: they are heavily
implementation-dependent as defined and the descriptions seem to be
assuming Chrome's implementation of various stuff in ways that are hard
or impossible to map onto other implementations.

-Boris

[Erik Chen]

On Fri, Mar 9, 2018 at 12:54 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/9/18 11:01 AM, Erik Chen wrote:

If you have further feedback, we'd love to hear it. If not, that's okay too, but please let us know so we know not to wait for your feedback.

Erik,

I somewhat worry about numberOfTabs exposing cross-origin information about what frames other sites are loading things from.  Maybe that's already exposed by window[n] access, but worth thinking about carefully.

To clarify, the current proposal indicates that browsers should return "null" for all fields anytime cross-origin information could be leaked.

"""

// Any or all of these values may be |null| if:

//  - The browser is unable to provide accurate information due to

//    implementation limitations.

//  - Exposing the information could leak information across frames from

//    different origins.

"""

From Chrome's perspective, we intend to return non-null results only if site-isolation is enabled. Does that satisfy your concerns?

 

I think that's all for feedback on the changes.  My previous comments on usedJSHeapSize/totalJSHeapSize stand: they are heavily implementation-dependent as defined and the descriptions seem to be assuming Chrome's implementation of various stuff in ways that are hard or impossible to map onto other implementations.

That's a good point. We think that the current proposal for usedJSHeapSize/totalJSHeapSize does provide utility to developers, but recognize that there's no way to nail down a consistent definition across JS-implementations. The possibilities I see are:

* drop usedJSHeapSize/totalJSHeapSize entirely.

* Add some type of implementation-specific, optional dictionary member that browsers can fill with whatever they want. This would allow Chrome to keep usedJSHeapSize/totalJSHeapSize, and eventually add additional members [e.g. memory usage from video elements, etc.]. Other browsers could fill in with whatever fields they wanted, or leave it empty. 

Thoughts?

 

-Boris

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/no00RdMnGio/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f550da94-72db-4203-4591-73c7ef7dc53f%40mit.edu.

[Boris Zbarsky]

On 3/9/18 1:13 PM, Erik Chen wrote:
> From Chrome's perspective, we intend to return non-null results only if
> site-isolation is enabled. Does that satisfy your concerns?

I'm specifically talking about the numberOfTabs value. I don't think
that whether it exposes information is affected by site isolation...

> * drop usedJSHeapSize/totalJSHeapSize entirely.
> * Add some type of implementation-specific, optional dictionary member
> that browsers can fill with whatever they want. This would allow Chrome
> to keep usedJSHeapSize/totalJSHeapSize, and eventually add additional
> members [e.g. memory usage from video elements, etc.]. Other browsers
> could fill in with whatever fields they wanted, or leave it empty.
>
> Thoughts?

My gut feeling if I were doing this would be to drop and revisit with
more involvement from Edge/Safari and a better understanding of what
sort of information sites are really looking for here....

-Boris

[Erik Chen]

On Fri, Mar 9, 2018 at 1:40 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/9/18 1:13 PM, Erik Chen wrote:

 From Chrome's perspective, we intend to return non-null results only if site-isolation is enabled. Does that satisfy your concerns?

I'm specifically talking about the numberOfTabs value.  I don't think that whether it exposes information is affected by site isolation...

Could you clarify with an example that would cause information to leak across origins?

* drop usedJSHeapSize/totalJSHeapSize entirely.
* Add some type of implementation-specific, optional dictionary member that browsers can fill with whatever they want. This would allow Chrome to keep usedJSHeapSize/totalJSHeapSize, and eventually add additional members [e.g. memory usage from video elements, etc.]. Other browsers could fill in with whatever fields they wanted, or leave it empty.

Thoughts?

My gut feeling if I were doing this would be to drop and revisit with more involvement from Edge/Safari and a better understanding of what sort of information sites are really looking for here....

Understood. Thanks for the feedback! I will confer with Hannes and respond on this thread later.

 

-Boris

[Boris Zbarsky]

On 3/9/18 1:46 PM, Erik Chen wrote:
> Could you clarify with an example that would cause information to leak
> across origins?

Sure. Say a page does:

<a href="https://other-origin.html" rel="noopener">Click me</a>

Right now, if the user clicks that link the page has no way to extract
information from the resulting cross-origin page about the subframes
it's loading, because it has no way to access that window. At least
without cooperation from those subframes. ;)

numberOfTabs, if implemented in a strict process-per-tld+1 setup, would
allow detecting whether https://other-origin.html loads any subframes
from the same tld+1 as the original page.

-Boris

[Erik Chen]

Thanks for the example! 

Agreed that this leaks information across origins, and that this is worth considering carefully. I will note that even without numberOfTabs, any type of process-wide information exposed will likely leak the same information [e.g. process memory total will go up by a lot if a subframe is loaded in the same process]. Will bring this up with our security/privacy teams to get more feedback/thoughts.

[Erik Chen]

Boris,

Hannes and I discussed your feedback [w.r.t. JS measurements] and agreed that we should leave them out of the spec proposal for now. We've updated the Privacy section to explicitly call out the example you provided and have requested that Chrome's privacy + security teams take a look at the whole proposal. Assuming that works out, and after +erham has had a chance to do a review, our tentative plan is to bring this spec to WICG. 

Thanks again for all of your help! Do you have any other feedback for us? Does the current form of the spec proposal seem reasonable to you?

[Boris Zbarsky]

On 3/19/18 12:39 PM, Erik Chen wrote:
> Thanks again for all of your help! Do you have any other feedback for
> us? Does the current form

> <https://github.com/erikchen/performance-memory/blob/master/explainer.md#privacy>

> of the spec proposal seem reasonable to you?

Erik,

Thank you for the updates. That looks reasonable as a starting point.

-Boris

[n...@chromium.org]

FYI: We've updated the ChromeStatus entry because our current plan is as follows:

• If the renderer is locked to an origin, remove the coarse quantization and delay from values we report. Changed from using site isolation flag: this flag does not guarantee that we only host one origin per process.
• We will report the total heap size instead of total physical size in |total_js_heap_size|. This will result in increased values for this attribute in some OSs. This change aims to fix crbug.com/807651 where |used_js_heap_size| would occasionally be greater than |total_js_heap_size|, which should never happen.
• In the future: if multiple origins are grouped into the same process, return null for the total and used JS heap size. This change is now punted until later on to reduce the breakage of this API. For now, we will continue to return bucketized values in this case (even though they may not be super helpful).

Developers can distinguish between bucketized vs unbucketized values by looking at the values (bucketized values are heavily rounded), but we may add an additional signal in our performance.memory to tell whether the values being considered are bucketized or not.

[n...@chromium.org]

Update: we changed the proposal in crbug.com/807651 and I forgot to update the information in here. The current proposal is to remove the quantization and delay by only 50 ms when the renderer is locked to a site. This is what site isolation does, not lock to origin, and it seems that locking to an origin is rare and there seem to not be any significant privacy concerns from this change.