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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Wake ups are throttled independently per Window. This prevents a Window from learning about timers running in a cross-origin Window.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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
--
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.--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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5H-un4ofLdN9KyqWiRr6V%3DdjbVqrkv7EEqnoXg4d_h%3DTw%40mail.gmail.com.
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5E-i7Mve%2BF40JrNnRrn8bOF4nTVnrOqgAWnSrBM97%3DAkA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGD3t5FVwsTpbmWd3YmdTqOF1LxZXv15NnKiMFqfyTWsZBQ2-A%40mail.gmail.com.
Wake ups are throttled independently per Window. This prevents a Window from learning about timers running in a cross-origin Window.
LGTM2
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEifivWYrw4E2LQmwqVETgoJGyd_WdAgAh_WPDqVr0QJkg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b622a61-6ae1-c757-cf81-2068e890a2a8%40gmail.com.
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.
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).
Great! Still LGTM
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhjrXJHVtJ_--zwuLDct_1KDWk775bpM82aDR%3DtampfPA%40mail.gmail.com.
The Web app owners confirmed that the following change to the policy is sufficient to support their 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.