Intent to Implement and Ship: Intensive throttling of Javascript timer wake ups

912 views
Skip to first unread message

François Doray

unread,
Jun 4, 2020, 2:01:35 PM6/4/20
to blink-dev
fdo...@chromium.org https://docs.google.com/document/d/105Hlbcb1mTV06bT9aDpwBotY13eZiKV5Hl4PW5LlyeE/edit?usp=sharing Specification: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html https://docs.google.com/document/d/1sd9EVERCtRWKvnJXnP3iZ83fM3FLwDbjiyfMkaKWEYk/edit?usp=sharing This change is spec-compliant. The spec says that it is possible to "Optionally, wait a further implementation-defined length of time" before running a timer. In a page that has been backgrounded for 5 minutes, align wake ups from Javascript timers with a timeout ≤ 5 minutes to 1-minute intervals. Also, align wake ups from Javascript timers with a timeout > 5 minutes to 1-second intervals. When a Javascript timer causes a wake up, all ready timers can execute, even if they didn’t cause the wake up. In a page that has been backgrounded for less than 5 minutes, keep the existing policy of aligning wake ups from timers on 1-second intervals. Local experiments demonstrate that this intervention extends battery life.
"Other vendors already shipping interoperable implementations" Safari is shipping a similar intervention. Timers are aligned on 40-seconds intervals instead of 1-minute intervals. If experiments show that battery gains are similar with 40-seconds and 1-minute intervals, we could converge on the same intervals as Safari. "A mature specification in the relevant standards body" This intervention is spec-compliant. "A shared test suite for that specification" It isn't clear what should be tested specifically for this intervention since the spec allows waiting for an "implementation-defined" length. "signals from other browser vendors" We are sharing this idea for the first time in June 2020. We will gather signals from other browser vendors in the next few weeks. Firefox: No public signals In Firefox 77.0.1, a recursive setTimeout with a 10 ms timeout runs every 10 ms. Edge: No public signals In Microsoft Edge 84.0.522.11, a recursive setTimeout with a 10 ms timeout runs every 1 second. Safari: Shipped In Safari 13.1.1, a recursive setTimeout with a 10 ms timeout runs: < 2.5 minutes in background: Every 250 ms - 30 seconds > 2.5 minutes in background: Every 40 seconds Web developers: No signals There were strong negative signals for page freezing on desktop https://groups.google.com/a/chromium.org/g/blink-dev/c/sotCDcI-E7Y/m/boghpXElDAAJ. This intervention provides similar performance benefits, but addresses breakages raised by Web developers. We will update this section when we get signals from Web developers specifically on this improved intervention.
We consider displaying a message in the Devtools console the first time that a Javascript timer is delayed by more than 5 seconds due to this intervention. Yes Yes This intervention doesn't require changes to the spec. Timers are already covered by Web Platform Tests. https://crbug.com/1075553 https://www.chromestatus.com/feature/4718288976216064

Dan McArdle

unread,
Jun 9, 2020, 5:19:04 PM6/9/20
to François Doray, blink-dev

Will timers across multiple sites be woken up at the same time? I’m worried that this creates an ephemeral fingerprinting surface as described here: https://github.com/asankah/ephemeral-fingerprinting.


One possible mitigation is to create one wakeup scheduler per context, each with a unique offset/start time.



--
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/CAGD3t5GK2BV%2BOeBG1vC6yOb5fP8T9XvuVDQJ5GbdEFKt0DQ1jQ%40mail.gmail.com.

François Doray

unread,
Jun 10, 2020, 1:44:05 PM6/10/20
to Dan McArdle, blink-dev

Re. Timer wake ups across multiple sites and ephemeral fingerprinting

In my original proposal, a wake up caused by a timer in any Window of a hierarchy allowed ready timers to run in all Windows of that hierarchy. Given the concern about ephemeral fingerprinting, I propose to change the policy to:

"""
In a Window whose top Window has been backgrounded for 5 minutes, align wake ups from timers with a timeout ≤ 5 minutes to 1-minute intervals. Also, align wake ups from timers with a timeout > 5 minutes to 1-second intervals. When a timer causes a wake up in a Window, all ready timers in that Window can execute, even if they didn’t cause the wake up.
"""

Discussion:
  • Wake ups are throttled independently per Window. This prevents a Window from learning about timers running in a cross-origin Window.
  • This policy is spec-compliant, even though it allows timers from same-origin or same-agent Windows to run out of order. Step 16 of the "timer initialization steps" specifies that ordering is only guaranteed per method context, where the method context is the Window. Spec
    • We propose to implement a stricter ordering only if field experiments show that this is required to prevent breakages to existing pages.
  • The throttling is enabled at the same time for all Windows in a hierarchy, to avoid breakages when cross-origin Windows in the same hierarchy communicate with each other. The change of visibility for a Window hierarchy is already observable across multiple origins through onvisibilitychange.
dmcardle@: Does this updated policy address your concerns about ephemeral fingerprinting?

sligh...@chromium.org

unread,
Jun 11, 2020, 3:56:55 PM6/11/20
to blink-dev, dmca...@chromium.org
Hey all,

API owners discussed this today. The data on battery impact is great! Thanks for that. Daniel Bratell noted that the implementation work is likely to be small, so we should probably consider this mostly as an I2S, which makes sense to me.

A few questions seem open that would be good to close on:
  • Is the plan here to do this as a fractional (finch'd) rollout, given the potential impact on enterprise scenarios?
  • There is some confusion about the details of the policy itself. For instance, if one schedules a few hundred timers to run 1s away from each other but more than 5 minutes from now, do we see wakeups every second? Or is there something I missed about it it regarding coalescing those far-out timers too?
Regards
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Dan McArdle

unread,
Jun 11, 2020, 5:54:02 PM6/11/20
to sligh...@chromium.org, blink-dev
Wake ups are throttled independently per Window. This prevents a Window from learning about timers running in a cross-origin Window.

I think this is almost right, except perhaps each Window's throttler should add a random duration to the first timer it throttles.

Is it possible for an external event, like turning off a mobile device's screen, to cause many Windows across browser tabs to start throttling their timers at the same instant? If so, we are effectively in the same situation as a global scheduler that synchronizes all the Windows' timers.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Jun 11, 2020, 6:43:31 PM6/11/20
to François Doray, blink-dev
On Thu, Jun 4, 2020 at 11:01 AM François Doray <fdo...@chromium.org> wrote:
fdo...@chromium.org https://docs.google.com/document/d/105Hlbcb1mTV06bT9aDpwBotY13eZiKV5Hl4PW5LlyeE/edit?usp=sharing Specification: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html https://docs.google.com/document/d/1sd9EVERCtRWKvnJXnP3iZ83fM3FLwDbjiyfMkaKWEYk/edit?usp=sharing This change is spec-compliant. The spec says that it is possible to "Optionally, wait a further implementation-defined length of time" before running a timer. In a page that has been backgrounded for 5 minutes, align wake ups from Javascript timers with a timeout ≤ 5 minutes to 1-minute intervals. Also, align wake ups from Javascript timers with a timeout > 5 minutes to 1-second intervals.

Just checking: is this written backwards? It would make more sense to me if timers with shorter timeouts had shorter alignment buckets, but you said the opposite.
 
When a Javascript timer causes a wake up, all ready timers can execute, even if they didn’t cause the wake up. In a page that has been backgrounded for less than 5 minutes, keep the existing policy of aligning wake ups from timers on 1-second intervals. Local experiments demonstrate that this intervention extends battery life.
"Other vendors already shipping interoperable implementations" Safari is shipping a similar intervention. Timers are aligned on 40-seconds intervals instead of 1-minute intervals. If experiments show that battery gains are similar with 40-seconds and 1-minute intervals, we could converge on the same intervals as Safari. "A mature specification in the relevant standards body" This intervention is spec-compliant. "A shared test suite for that specification" It isn't clear what should be tested specifically for this intervention since the spec allows waiting for an "implementation-defined" length. "signals from other browser vendors" We are sharing this idea for the first time in June 2020. We will gather signals from other browser vendors in the next few weeks. Firefox: No public signals In Firefox 77.0.1, a recursive setTimeout with a 10 ms timeout runs every 10 ms. Edge: No public signals In Microsoft Edge 84.0.522.11, a recursive setTimeout with a 10 ms timeout runs every 1 second. Safari: Shipped In Safari 13.1.1, a recursive setTimeout with a 10 ms timeout runs: < 2.5 minutes in background: Every 250 ms - 30 seconds > 2.5 minutes in background: Every 40 seconds Web developers: No signals There were strong negative signals for page freezing on desktop https://groups.google.com/a/chromium.org/g/blink-dev/c/sotCDcI-E7Y/m/boghpXElDAAJ. This intervention provides similar performance benefits, but addresses breakages raised by Web developers. We will update this section when we get signals from Web developers specifically on this improved intervention.
We consider displaying a message in the Devtools console the first time that a Javascript timer is delayed by more than 5 seconds due to this intervention. Yes Yes This intervention doesn't require changes to the spec. Timers are already covered by Web Platform Tests. https://crbug.com/1075553 https://www.chromestatus.com/feature/4718288976216064

--

François Doray

unread,
Jun 12, 2020, 2:18:39 PM6/12/20
to Chris Harrelson, blink-dev
Re Api Owners: Is the plan here to do this as a fractional (finch'd) rollout, given the potential impact on enterprise scenarios?

Yes, this change will follow the following rollout plan:
  • 50% Canary/Dev
  • 50% Beta
  • 1% Stable
  • 100% Stable (synchronized with a milestone update)
Between each stage of the rollout plan, we will assess impact on guiding metrics and battery-specific metrics and we will monitor feedback from Web developers.

Additionally, it will be possible to set an enterprise policy to force-enable or force-disable this intervention. The enterprise policy will be provided for at least 4 milestones after the intervention ships to 100% Stable. This decision was taken following an internal discussion with the enterprise team, in order to make the change enterprise-friendly (see Shipping changes that are enterprise-friendly).

Re Api Owners: There is some confusion about the details of the policy itself. For instance, if one schedules a few hundred timers to run 1s away from each other but more than 5 minutes from now, do we see wakeups every second? Or is there something I missed about it it regarding coalescing those far-out timers too?

Yes, scheduling timers 1s away from each other but more than 5 minutes from now will cause wake ups every second.

Rationale:

There are timers for which enforcing a 1-minute alignment will not have a significant power impact but will be surprising to the user. For example, if the user sets an alarm in 5 minutes and 10 seconds (example), they expect it to fire at that exact time. The opt-out for timers with a timeout > 5 minutes, combined with the fact that this intervention starts after 5 minutes in background, ensures that it is possible to make an alarm that fires at an arbitrary time.

It is a non-goal for this project to prevent pages from intentionally doing work in the background. This is why we are not particularly worried about timers scheduled 1s away from each other but more than 5 minutes from now. See examples of timers that we want to throttle. That being said, it would be undesirable if timers that Web developers do not intend to run in background started being scheduled ahead of time with a delay > 5 minutes, due to library code or copy-pasted code from forums.

Alternative policy:

To prevent abuse, we propose this alternative policy:

"""
In a Window whose top Window has been backgrounded for 5 minutes, timers can run aligned on 1-minute intervals or > 1 minute after the last timer has run in any Window with the same window agent.
"""

With this alternative policy, if a window agent schedules timers that are 1-minute apart from each other, they are not subject to alignment. Also, a window agent cannot cause more than 1 wake up per minute on average.

Do you prefer this alternative policy?

Re dmcardle@: Is it possible for an external event, like turning off a mobile device's screen, to cause many Windows across browser tabs to start throttling their timers at the same instant? If so, we are effectively in the same situation as a global scheduler that synchronizes all the Windows' timers.

Yes, it is possible for an external event to cause many browser tabs to be hidden at the same time, and intensive throttling starts in all Windows of a tab 5 minutes after it is hidden. However, all frames in a page (even cross-origin) can already observe when the page is backgrounded through the visibilitychange event. Because of that, it is unclear to me what additional information the latest version of the policy exposes to Windows?

Re. chrishtr@: Just checking: is [the policy] written backwards? It would make more sense to me if timers with shorter timeouts had shorter alignment buckets, but you said the opposite.

It wasn't written backwards. Throttling timers with a long timeout is less important because they have less impact on power usage. In my reply to Api Owners above, I propose an alternative policy that might be easier to reason about.

Chris Harrelson

unread,
Jun 12, 2020, 2:36:40 PM6/12/20
to François Doray, blink-dev
On Fri, Jun 12, 2020 at 11:18 AM François Doray <fdo...@chromium.org> wrote:
Re Api Owners: Is the plan here to do this as a fractional (finch'd) rollout, given the potential impact on enterprise scenarios?

Yes, this change will follow the following rollout plan:
  • 50% Canary/Dev
  • 50% Beta
  • 1% Stable
  • 100% Stable (synchronized with a milestone update)
Between each stage of the rollout plan, we will assess impact on guiding metrics and battery-specific metrics and we will monitor feedback from Web developers.

Additionally, it will be possible to set an enterprise policy to force-enable or force-disable this intervention. The enterprise policy will be provided for at least 4 milestones after the intervention ships to 100% Stable. This decision was taken following an internal discussion with the enterprise team, in order to make the change enterprise-friendly (see Shipping changes that are enterprise-friendly).

Re Api Owners: There is some confusion about the details of the policy itself. For instance, if one schedules a few hundred timers to run 1s away from each other but more than 5 minutes from now, do we see wakeups every second? Or is there something I missed about it it regarding coalescing those far-out timers too?

Yes, scheduling timers 1s away from each other but more than 5 minutes from now will cause wake ups every second.

Rationale:

There are timers for which enforcing a 1-minute alignment will not have a significant power impact but will be surprising to the user. For example, if the user sets an alarm in 5 minutes and 10 seconds (example), they expect it to fire at that exact time. The opt-out for timers with a timeout > 5 minutes, combined with the fact that this intervention starts after 5 minutes in background, ensures that it is possible to make an alarm that fires at an arbitrary time.

It is a non-goal for this project to prevent pages from intentionally doing work in the background. This is why we are not particularly worried about timers scheduled 1s away from each other but more than 5 minutes from now. See examples of timers that we want to throttle. That being said, it would be undesirable if timers that Web developers do not intend to run in background started being scheduled ahead of time with a delay > 5 minutes, due to library code or copy-pasted code from forums.

Alternative policy:

To prevent abuse, we propose this alternative policy:

"""
In a Window whose top Window has been backgrounded for 5 minutes, timers can run aligned on 1-minute intervals or > 1 minute after the last timer has run in any Window with the same window agent.
"""

With this alternative policy, if a window agent schedules timers that are 1-minute apart from each other, they are not subject to alignment. Also, a window agent cannot cause more than 1 wake up per minute on average.

Do you prefer this alternative policy?

I think so, because it's more consistent, yet still allows not aligning events when not necessary.

However, consider this example:

function myTimerCallback() {
  setTimeout(callback1, 62 * 1000);
  setTimeout(callback2, 61 * 1000);
}

Under this policy, callback2 will run exactly 61 seconds from the time of a call to myTimerCallback, but callback1 will run at 61 + 60 seconds from now? (I'm assuming here that the alignment policy will only round up times to the next minute boundary, is that correct?)

I guess that's ok, and merely highlights a need for the app to coordinate its timers if timing is important.

 

Re dmcardle@: Is it possible for an external event, like turning off a mobile device's screen, to cause many Windows across browser tabs to start throttling their timers at the same instant? If so, we are effectively in the same situation as a global scheduler that synchronizes all the Windows' timers.

Yes, it is possible for an external event to cause many browser tabs to be hidden at the same time, and intensive throttling starts in all Windows of a tab 5 minutes after it is hidden. However, all frames in a page (even cross-origin) can already observe when the page is backgrounded through the visibilitychange event. Because of that, it is unclear to me what additional information the latest version of the policy exposes to Windows?

Re. chrishtr@: Just checking: is [the policy] written backwards? It would make more sense to me if timers with shorter timeouts had shorter alignment buckets, but you said the opposite.

It wasn't written backwards. Throttling timers with a long timeout is less important because they have less impact on power usage. In my reply to Api Owners above, I propose an alternative policy that might be easier to reason about.

On Thu, Jun 11, 2020 at 6:43 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Jun 4, 2020 at 11:01 AM François Doray <fdo...@chromium.org> wrote:
fdo...@chromium.org https://docs.google.com/document/d/105Hlbcb1mTV06bT9aDpwBotY13eZiKV5Hl4PW5LlyeE/edit?usp=sharing Specification: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html https://docs.google.com/document/d/1sd9EVERCtRWKvnJXnP3iZ83fM3FLwDbjiyfMkaKWEYk/edit?usp=sharing This change is spec-compliant. The spec says that it is possible to "Optionally, wait a further implementation-defined length of time" before running a timer. In a page that has been backgrounded for 5 minutes, align wake ups from Javascript timers with a timeout ≤ 5 minutes to 1-minute intervals. Also, align wake ups from Javascript timers with a timeout > 5 minutes to 1-second intervals.

Just checking: is this written backwards? It would make more sense to me if timers with shorter timeouts had shorter alignment buckets, but you said the opposite.
 
When a Javascript timer causes a wake up, all ready timers can execute, even if they didn’t cause the wake up. In a page that has been backgrounded for less than 5 minutes, keep the existing policy of aligning wake ups from timers on 1-second intervals. Local experiments demonstrate that this intervention extends battery life.
"Other vendors already shipping interoperable implementations" Safari is shipping a similar intervention. Timers are aligned on 40-seconds intervals instead of 1-minute intervals. If experiments show that battery gains are similar with 40-seconds and 1-minute intervals, we could converge on the same intervals as Safari. "A mature specification in the relevant standards body" This intervention is spec-compliant. "A shared test suite for that specification" It isn't clear what should be tested specifically for this intervention since the spec allows waiting for an "implementation-defined" length. "signals from other browser vendors" We are sharing this idea for the first time in June 2020. We will gather signals from other browser vendors in the next few weeks. Firefox: No public signals In Firefox 77.0.1, a recursive setTimeout with a 10 ms timeout runs every 10 ms. Edge: No public signals In Microsoft Edge 84.0.522.11, a recursive setTimeout with a 10 ms timeout runs every 1 second. Safari: Shipped In Safari 13.1.1, a recursive setTimeout with a 10 ms timeout runs: < 2.5 minutes in background: Every 250 ms - 30 seconds > 2.5 minutes in background: Every 40 seconds Web developers: No signals There were strong negative signals for page freezing on desktop https://groups.google.com/a/chromium.org/g/blink-dev/c/sotCDcI-E7Y/m/boghpXElDAAJ. This intervention provides similar performance benefits, but addresses breakages raised by Web developers. We will update this section when we get signals from Web developers specifically on this improved intervention.
We consider displaying a message in the Devtools console the first time that a Javascript timer is delayed by more than 5 seconds due to this intervention. Yes Yes This intervention doesn't require changes to the spec. Timers are already covered by Web Platform Tests. https://crbug.com/1075553 https://www.chromestatus.com/feature/4718288976216064

--
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/CAGD3t5GK2BV%2BOeBG1vC6yOb5fP8T9XvuVDQJ5GbdEFKt0DQ1jQ%40mail.gmail.com.

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

François Doray

unread,
Jun 12, 2020, 2:45:12 PM6/12/20
to Chris Harrelson, blink-dev
Yes, under the new policy I'm proposing, callback2 will run exactly 61 seconds from the time of a call to myTimerCallback, if no other timer runs in the meantime. callback1 will run on the next 1-minute aligned time, which is guaranteed to be ≤ 60 seconds after callback2. Having background wake ups that are 1-second apart indicates that the page could have been written in a more power-efficient way, and we are comfortable adding a delay to the 2nd wake up.

Dan McArdle

unread,
Jun 12, 2020, 6:05:16 PM6/12/20
to François Doray, Chris Harrelson, blink-dev
Re dmcardle@: Is it possible for an external event, like turning off a mobile device's screen, to cause many Windows across browser tabs to start throttling their timers at the same instant? If so, we are effectively in the same situation as a global scheduler that synchronizes all the Windows' timers.
Yes, it is possible for an external event to cause many browser tabs to be hidden at the same time, and intensive throttling starts in all Windows of a tab 5 minutes after it is hidden. However, all frames in a page (even cross-origin) can already observe when the page is backgrounded through the visibilitychange event. Because of that, it is unclear to me what additional information the latest version of the policy exposes to Windows?

To clarify, the concern is that two origins in different frame hierarchies can correlate a user's identity. Origins in the same hierarchy are free to communicate.

Given the proposed throttling behavior, scripts in different frame hierarchies can independently estimate the onset of throttling with high accuracy by repeatedly scheduling short timers and measuring their wakeup times. The estimated onset of throttling is a low entropy identifier that can be joined across sites.

The visibilitychange event is less of an ephemeral fingerprinting surface because it only fires across a small number of frame hierarchies simultaneously. That is, it fires for two hierarchies when switching tabs, and one when the screen turns off (assuming one visible browser window).

To increase the entropy / reduce the accuracy of the timestamp estimation, I'm suggesting you add a random fudge factor to throttled timers.

Dan McArdle

unread,
Jun 15, 2020, 2:28:15 PM6/15/20
to François Doray, Chris Harrelson, blink-dev
After chatting with Francois, I've learned I was missing a critical piece of this design: throttling for a frame hierarchy begins when visibilitychange fires. This means that the screen turning off only affects the frame hierarchies that are currently visible, rather than all of them simultaneously.

I'm no longer concerned about this proposal introducing an ephemeral fingerprinting surface.

Thanks!

François Doray

unread,
Jun 15, 2020, 3:04:12 PM6/15/20
to Dan McArdle, Chris Harrelson, blink-dev
Thanks Dan for making sure that this feature does not introduce a new ephemeral fingerprinting surface.

Blink API Owners: Following discussions on this email thread, I would like to move forward with this policy:

"""
In a Window whose top Window has been hidden [1] for 5 minutes, timers run aligned on 1-minute intervals or > 1 minute after the last timer has run in any same-origin Window in the same tree [2].
"""

This policy ensures that an origin that schedules timers that are at least 1 minute apart is not affected by this intervention. An origin that schedules timers more frequently is subject to a 1-minute alignment. An origin cannot learn about timers running in other origins.

Yoav Weiss

unread,
Jun 16, 2020, 3:27:58 AM6/16/20
to François Doray, Dan McArdle, Chris Harrelson, blink-dev

Dan McArdle

unread,
Jun 16, 2020, 12:01:24 PM6/16/20
to François Doray, blink-dev
Wake ups are throttled independently per Window. This prevents a Window from learning about timers running in a cross-origin Window.

I think this is almost right, except perhaps each Window's throttler should add a random duration to the first timer it throttles.

Is it possible for an external event, like turning off a mobile device's screen, to cause many Windows across browser tabs to start throttling their timers at the same instant? If so, we are effectively in the same situation as a global scheduler that synchronizes all the Windows' timers.

Daniel Bratell

unread,
Jun 17, 2020, 1:57:05 PM6/17/20
to Yoav Weiss, François Doray, Dan McArdle, Chris Harrelson, blink-dev

Chris Harrelson

unread,
Jun 17, 2020, 1:58:55 PM6/17/20
to Daniel Bratell, Yoav Weiss, François Doray, Dan McArdle, blink-dev
LGTM3

I think the Chromium behavior should be documented somewhere so that affected developers can take action. Could you write a web.dev article or similar?

François Doray

unread,
Jun 17, 2020, 3:16:34 PM6/17/20
to Chris Harrelson, Daniel Bratell, Yoav Weiss, Dan McArdle, blink-dev
Hi Blink API Owners,

Thanks for taking the time to look into this feature.

After discussing with dcheng@, I realized the "sandbox" attribute on iframes make it easy for a page to create N frames with different origins and use them to schedule an arbitrary amount of unaligned wake ups (since each origin can wake up unaligned if there was no wake up from that origin in the last > 60 seconds). To avoid exposing this abuse surface, we would like to slightly change the policy to disallow unaligned wake ups in origins that are different from the main frame:

In a Window whose top Window has been hidden for 5 minutes, timers can run:

  • aligned on 1-minute intervals, or,

  • if the Window is same-origin with the top Window, > 1 minute after the last timer has run in any Window in the tree that is same-origin with the top Window.


From a few local tests, we do not think that forcing alignment in cross-origin frames will disrupt user experience. Of course, as I said in a previous email, we will go through a Finch rollout to validate this hypothesis. The design doc was updated with our various attempts to design a policy that supports use cases that users care about about while preserving isolation between origins. See also latest feedback [Google-internal] from dcheng@.

Thanks for taking the time to review the many versions of this policy. I think that what we will end up shipping will be better than what I initially had in mind :) 

François

Yoav Weiss

unread,
Jun 17, 2020, 6:06:11 PM6/17/20
to François Doray, Chris Harrelson, Daniel Bratell, Dan McArdle, blink-dev
On Wed, Jun 17, 2020 at 9:16 PM François Doray <fdo...@chromium.org> wrote:
Hi Blink API Owners,

Thanks for taking the time to look into this feature.

After discussing with dcheng@, I realized the "sandbox" attribute on iframes make it easy for a page to create N frames with different origins and use them to schedule an arbitrary amount of unaligned wake ups (since each origin can wake up unaligned if there was no wake up from that origin in the last > 60 seconds).

Are we concerned that pages would do that just to drain batteries? Or are there other concerns with that scenario?

François Doray

unread,
Jun 18, 2020, 9:43:35 AM6/18/20
to Yoav Weiss, Chris Harrelson, Daniel Bratell, Dan McArdle, blink-dev
Re yoav@: Are we concerned that pages would do that just to drain batteries? Or are there other concerns with that scenario?

We are not concerned about intentional abuse. This policy attempts to reduce battery usage from timers that Web developers would happily run at a lower frequency in the background if there was no development cost to make that change.

However, we are concerned that Web developers could realize that their timers do not run at the expected frequency in the background, and "fix" the problem by using a solution found on the Web that relies on sandbox frames (e.g. a library or a code snippet). In that case, the Web developer circumvents the wake up throttling without realizing the performance impact.

We prefer not to expose this abuse surface. We think that preventing unaligned wake ups in cross-origin frames is an easy mechanism to prevent abuse, and that it will not negatively affect users.

Re chrishtr@: Could you write a web.dev article or similar?

Yes, definitely, we will publish an article before shipping, as soon as we are confident that we have correctly formulated the policy.

Yoav Weiss

unread,
Jun 18, 2020, 3:20:05 PM6/18/20
to François Doray, Chris Harrelson, Daniel Bratell, Dan McArdle, blink-dev
Thanks!

The only thing that slightly concerns me about aligning the timers of cross-origin iframes is that we might be re-introducing the ephemeral fingerprinting surface that was raised as a concern earlier.
Dan - can you confirm that this is not a concern with the latest proposal?  

Dan McArdle

unread,
Jun 18, 2020, 3:39:54 PM6/18/20
to Yoav Weiss, François Doray, Chris Harrelson, Daniel Bratell, blink-dev
I'm not concerned about the ephemeral fingerprinting surface.

Communication between cross-origin frames in the same hierarchy is already possible, so aligning their timers is no worse than the status quo.

(The ephemeral fingerprinting issue would rear its head if we started intensive throttling at the same time across many frame hierarchies.)

Thanks!

Yoav Weiss

unread,
Jun 18, 2020, 4:05:08 PM6/18/20
to Dan McArdle, François Doray, Chris Harrelson, Daniel Bratell, blink-dev
Great! Still LGTM

Chris Harrelson

unread,
Jun 18, 2020, 4:15:23 PM6/18/20
to Yoav Weiss, Dan McArdle, François Doray, Daniel Bratell, blink-dev


On Thu, Jun 18, 2020 at 1:05 PM Yoav Weiss <yo...@yoav.ws> wrote:
Great! Still LGTM

IOW, per additional decisions at the API owners meetings, you still have your 3 LGTMs and can proceed to ship.

Thanks for the excellent discussion and consideration of all factors!
 

François Doray

unread,
Sep 3, 2020, 4:00:40 PM9/3/20
to Chris Harrelson, Yoav Weiss, Dan McArdle, Daniel Bratell, blink-dev
Hi Blink API Owners,

We experimented with this intervention on the Beta channel and obtained great CPU and memory reduction results.

Policy used for the M85 Beta Experiment
In a Window whose top Window has been hidden for 5 minutes, timers can run:
- aligned on 1-minute intervals, or,
- if the Window is same-origin with the top Window, > 1 minute after the last timer has run in any Window in the tree that is same-origin with the top Window.

In a page that has been backgrounded for less than 5 minutes, keep the existing policy of aligning wake ups from timers on 1-second intervals.


However, we received feedback that the policy breaks this use case:

Upon detecting than an XMLHttpRequest long poll connection is broken, a Web app tries to recreate the connection with exponential backoff.  The exponential backoff is implemented with a timer that starts with a 2 seconds timeout, which increases gradually. With intensive throttling of Javascript timer, the Web app can wait up to 1 minute before attempting to reconnect.

The Web app owners confirmed that the following change to the policy is sufficient to support their use case:

Alternative policy: Special handling of timers with nesting level <=5
In a Window whose top Window has been hidden for 5 minutes, a timer wake up can occur:
1. on a 1-second aligned interval when a timer with nesting level <= 5 has reached its deadline, or,
2. on a 1-minute aligned interval when any timer has reached its deadline, or,
3. if the Window is same origin with the top Window, at any time if 1 minute has passed since the last timer wake up
When a timer wake up occurs in a Window, all timers that have reached their deadline in that Window are executed.
In a page that has been backgrounded for less than 5 minutes, keep the existing policy of aligning wake ups from timers on 1-second intervals.  

Timers with nesting level > 5 are much more frequent than timers with nesting level <= 5, so we don't expect that this change will significantly affect CPU and memory reduction. We are supportive of that change, as it would minimize disruption on existing Web apps when intensive throttling of Javascript timers launches. That being said, we think that service workers are a better fit than background pages to deliver notifications, so we would communicate that the item #1 in the above policy would be removed after ~1 year (i.e. after ~1 year, we would go back to the previously agreed upon policy).

What's your feedback about this alternative policy? 

Thanks!

Chris Harrelson

unread,
Sep 3, 2020, 8:06:36 PM9/3/20
to François Doray, Yoav Weiss, Dan McArdle, Daniel Bratell, blink-dev
This adjustment LGTM. Thanks for asking.

If you don't hear back from another API owner in the next week, consider it approved.
Reply all
Reply to author
Forward
0 new messages