New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 35 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 2
Type: Feature
Team-Security-UX

Blocking:
issue 776416


Participants' hotlists:
Hotlist-1

Show other hotlists

Other hotlists containing this issue:
EnamelAndFriendsFixIt
Cpu-Throttling


Sign in to add a comment
Please consider intervention for high cpu usage js
Reported by sobi...@gmail.com, Sep 18 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.49 Safari/537.36

Steps to reproduce the problem:
1. enter website with e-coin mining site (coin-hive.com/lib/)
2. super high cpu usage caught
3. booom, crash or not responding

What is the expected behavior?

What went wrong?
High CPU usage ( >100%) 
then chrome not responding

Did this work before? N/A 

Chrome version: 61.0.3163.49  Channel: beta
OS Version: OS X 10.13.0
Flash Version: Shockwave Flash 27.0 r0

Websites hostile to user use coin-hive (or any other) coin mining javascript is harmful to end-user.
browser not blocking them, should warn user the high cpu consuming,
end-users without e-coin + mining + js knowledge won't know what happened to their browser, and they should.
 
Components: UI>Browser>Permissions
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Feature
Summary: Please consider prompt "permit for running high cpu usage js` (was: Please consider prompt " permit for running high cpu usage js`)
This is effectively a feature request for the web platform permissions. Unfortunately, I don't think it's likely to be practical.
Cc: ojan@chromium.org
ojan - is this something the Interventions team is thinking about?
Labels: -OS-Mac
Getting this out of the Mac triage queue
Cc: kkaluri@chromium.org
Labels: Needs-Triage-M61
Status: Untriaged
Since it is marked as feature request, untriaging this issue 
Cc: -ojan@chromium.org
Components: -UI>Browser>Permissions Blink>JavaScript Internals>Permissions
Owner: ojan@chromium.org
Summary: Please consider intervention for high cpu usage js (was: Please consider prompt "permit for running high cpu usage js`)
I agree, I don't think we would ever have a permission for this but we may have heuristics. The complications here are not so much with coming up with a heuristic as enforcing it in the platform.

Assigning to ojan to triage.
Labels: Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Assigned
ojan@ -- Please help triage this. Thanks.
Coinhive abuse will only become more prevalent without intervention to control its usage. The majority of malicious Coinhive implementations don't impose throttling, leading to 100% CPU when the user visits the affected website.

Coinhive use on well-known websites and by malware developers has recently come to light.

https://www.theguardian.com/technology/2017/sep/27/pirate-bay-showtime-ads-websites-electricity-pay-bills-cryptocurrency-bitcoin
https://www.theregister.co.uk/2017/09/25/showtime_hit_with_coinmining_script/
https://www.bleepingcomputer.com/news/security/coinhive-is-rapidly-becoming-a-favorite-tool-among-malware-devs/
https://blog.malwarebytes.com/threat-analysis/2017/09/drive-by-mining-and-ads-the-wild-wild-west/


Coinhive knock-offs are starting to pop up.  A new one called "Crypto-Loot" -  https://crypto-loot.com/ has just been launched.  Chrome needs a mechanism to limit or stop high CPU JavaScript.
Yet another Coinhive knock-off has been discovered, this one called "Coin-Have"

https://coin-have.com/

No user opt-in and 100% CPU usage.

coin-have.png
50.9 KB View Download
Components: Blink>Scheduling
Here's an example of cryptojacking from today on Politifact's official website.
politifact.png
387 KB View Download
Components: -Internals>Permissions Internals>Permissions>Model
Cc: raymes@chromium.org
Sorry for the delays responding on this. Yes, we should do something about it. Not quite sure what.

Here's my current thinking:
If a site is using more than XX% CPU for more than YY seconds, then we put the page into "battery saver mode" where we aggressively throttle tasks and show a toast allowing the user to opt-out of battery saver mode. When a battery saver mode tab is backgrounded, we stop running tasks entirely.

I think we'll want measurement to figure out what values to use for XX and YY, but we can start with really egregious things like 100% and 60 seconds.

I'm effectively suggesting we add a permission here, but it would have unusual triggering conditions (e.g. no requestUseLotsOfCPU method). It only triggers when the page is doing a likely bad thing. raymes, does that sound bad to you?
At a high level that sounds good to me. It sounds like something we would want to use an anchored toast for to notify the user. 
The other issue that needs addressing is that this tab continues to use lots of CPU even when backgrounded. I suspect that it's because they use workers and we don't throttle workers. I filed issue 776416 to track throttling of workers in background tabs.
If I can volunteer an opinion on the topic of "coinjacking" (I like this term better) without derailing this thread too far away from the topic of JS CPU pegging: 

Would client-side cryptocurrency mining not be better handled by enabling alternative monetization right in the browser? Google's ads are unintrusive, so ideally this shouldn't cannibalize Google's revenue stream (by much), but the basic idea is that by creating an API in the browser that's battery-restricted, site owners can now have an alternate monetization vehicle that:
1) clears intrusive ads, and
2) drastically reduces prompts for permissions being discussed in this thread.

The idea: when plugged in, allow XX% CPU per tab to go towards mining so long as the user is actually on the page. And when not plugged in, battery-limit it such that the user isn't trading off unreasonable amounts of battery life to enjoy content.

Then, just let the browser-vendor e.g. Google take a cut. Industry norm is 20-30% for apps in an app store, so might as well stick with that range.

You'd still need to implement the permission to keep people from implementing this in JS as a workaround to squeeze an extra dime out, but ideally everyone would be encouraged to go through the API anyway, resulting in very limited instances of CPU Pegging Permissions Traps.

Thoughts?
Cc: chrisha@chromium.org
Please note that a class of web applications routinely uses lots of CPU. This class can roughly be described as:

- data processing and conversion (large 3D files, etc.)
- graphics intensive applications
- physics simulations
- scientific calculations/simulations
- games
- data conversion
- productivity tools dealing with large and/or complex data to be handled and processed.

One example from my own work would be the parsing of large collada files (500mb+) for relevant information and their conversion to a more compact, easier to read/write format for a 3D productivity software.

Another typical example that comes to mind would be a game that uses the JS main thread for UI/input/display, a web worker for physics simulations, another web worker for audio rendering and another web worker for GPU command queue assembly. In an involved game application (that needs to deal with 10-100x difference in machine performance) there are user toggles and automatically adjusted LOD algorithms to keep the application running smoothly at the best possible quality (the aim is to maximize use of the existing resources so that a desktop user gets a very good looking/behaving app, but a say a mobile user can still run the application satisfactory).

Any kind of of CPU pegging, locking, throttling, limiting etc. will massively hurt all of the aforementioned activities by web applications.

In addition, any kind of UI/prompt/interstitial/etc. displayed to the user to "unlock" more performance, is likely to be blindly clicked away by the user, and therefore leads to users getting inexplicably subpar/slow experiences on hardware that would be far more capable, leading to decreased user retention and acquisition.

The bottom line is: It's a very bad idea.
> It sounds like something we would want to use an anchored toast for to notify the user.

Experience with "toasts" (fullscreen, pointerlock, localstorage, etc.) has shown that a large proportion of users either doesn't see the toast, or blindly clicks it away as another unwanted interstitial (thus refusing whatever it asked for). In all but a few cases I've heard of users are confused by this, and application behavior/performance suffers as a consequence.
Comment 20 Deleted
I don't think a permission would work well, as the mining library can throttle itself to stay just under the line, while legitimate applications will now trigger annoying permission popups. 

Many extensions that can block miners area already available, I don't think this is something the browser should worry about. 

> Another typical example

None of those are typical examples of the average Chrome user.


> Any kind of of CPU pegging, locking, throttling, limiting etc. will massively hurt all of the aforementioned activities by web applications.

No web application should be using 100% CPU for a constant, sustained period of time.


> The bottom line is: It's a very bad idea.

It’s actually not. Can you provide any alternative solutions for this issue? I didn’t see any presented.


> In all but a few cases I've heard of users are confused by this, and application behavior/performance suffers as a consequence.

That sounds like a training issue with your user base, not Chrome’s notification method.


> I don't think a permission would work well, as the mining library can throttle itself to stay just under the line, while legitimate applications will now trigger annoying permission popups. 

What are some legitimate applications that use 100% CPU for a constant, sustained period of time?


> Many extensions that can block miners area already available, I don't think this is something the browser should worry about

Coinhive knock-offs and other cryptojacking scripts are literally popping up overnight.  No third-party extension can keep up with the names, URLs, IP addresses, etc. used for these clones.  This most definitely something the browser should worry about.  Reference: https://www.bleepingcomputer.com/news/security/the-internet-is-rife-with-in-browser-miners-and-its-getting-worse-each-day/



> What are some legitimate applications that use 100% CPU for a constant, sustained period of time?

One legitimate use would be a raytracer.

https://threejs.org/examples/raytracing_sandbox.html
> One legitimate use would be a raytracer.

I tried that site multiple times and only saw 50% CPU use briefly for a few seconds.  How can I reproduce it at 100% use sustained and constant?
ray trace test.png
245 KB View Download
> I tried that site multiple times and only saw 50% CPU use briefly for a few seconds.  How can I reproduce it at 100% use sustained and constant?

Use a less powerful CPU ;)
> No third-party extension can keep up with the names, URLs, IP addresses, etc. used for these clones.

No need to. Use uMatrix, it blocks 3rd party connections(except for CSS and images) by default. Just whitelist those which you need to have and you're done. Random domain names/suspicious JSes will be easily identifiable via the logger or via the popup UI if you want to know. If you're using uBlock Origin with uMatrix, that's even better, they're already maintaining a Resource-abuse filterlist.
Cc: kbr@chromium.org
Blocking: 776416
Cc: juj...@gmail.com bradnelson@chromium.org junov@chromium.org
I share pyalot's concern above in #18 above that preventing tabs from using CPU will break legitimate uses of WebGL, where it's common to do a lot of processing on the CPU before uploading the resulting vertices, textures, etc. to the GPU.

Epic's Zen Garden demo at https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html , compiled to WebAssembly by colleagues at Mozilla, legitimately utilizes 75% CPU for long periods of time on a MacBook Pro Retina. This is just one example. I attempted to reproduce similar behavior with http://toji.github.io/webgl2-crowd/ by turning off the use of transform feedback and instancing (thereby doing more work on the CPU rather than the GPU), but was only able to achieve ~40% sustained CPU usage, even with 40x40 characters.

Other simple WebAssembly / asm.js use cases like http://floooh.github.io/oryol-samples/asmjs/Dragons.html can also use reasonable amounts of CPU: in this case, for 1000 animated objects, 55% CPU usage, sustained.

On the topic of throttling workers' CPU usage (Issue 776416), it's expected that graphical applications compiled to WebAssembly will run their entire application main loop on the worker, and use OffscreenCanvas to display the result on the main thread. In situations like this, pages may legitimately have a worker running at 100% CPU, and driving their own main loop, without calling postMessage in the steady state.

If considering some kind of intervention then it's important to not break applications like these and others.

Perhaps one heuristic would involve interaction with the page. If the user's actively interacting with the page then I would argue that it, and any dedicated workers, shouldn't be throttled. Maybe this should mean obviously intentional interaction like something other than simple scrolling: i.e. mousedown, even on touch displays. Also, if any throttling does occur, there should be UI associated with it which allows it to be bypassed.

For what it's worth, this is a change I've been wanting to make for a while. There's plenty of non-coin-mining cases that use excessive CPU. It's usually accidental. I don't have any problem with sites using a lot of CPU for coin-mining or other use cases as long as it's sufficiently disclosed to users in a way they can understand.

Regarding throttling workers, I'm just suggesting we throttle them the same way we do the top-level page. Which is to say workers in *background* tabs get throttled the same way as the rest of the tab.

If we do throttling of foreground tabs, we should apply the same policy to main frame and workers. I can't think of any reason to more aggressively throttle workers than the main frame and was not intending to imply anything like that.
An example of a site doing coin-mining in a user-friendly way: https://authedmine.com/. I'm hopeful any Chrome side mitigations will not be punitive to uses like this.
I think this should be up to the website. Google should not have the right to dictate the revenue stream for the website. This is against the spirit of the open web. Other-wise many websites will start reducing optimizations exclusively for Chrome, and it will lose users.

It is not Google's right to decide what to block, but the user's right if he thinks website becomes slow. 
Chrome is what's called a user-agent, meaning that it acts as the agent of the user.

https://www.w3.org/TR/html-design-principles/#priority-of-constituencies

Discussion of the general philosophy of interventions[1] need not be conducted in this bug.

[1] https://github.com/WICG/interventions
>> Another typical example
> None of those are typical examples of the average Chrome user.

Those are not examples of "chrome users" but examples of applications that get written these days on the web. It's not 1998 anymore.


>> Any kind of of CPU pegging, locking, throttling, limiting etc. will massively hurt all of the aforementioned activities by web applications.
> No web application should be using 100% CPU for a constant, sustained period of time.

There are, as I've shown, many use-cases that possibly exhibit exactly that behavior (at least on a single core), for GPU command queue assembly (graphics rendering), data processing, audio rendering, physics simulations (games often use these), etc.

>> The bottom line is: It's a very bad idea.
> It’s actually not. Can you provide any alternative solutions for this issue? I didn’t see any presented.

You're asking for a "fix" sophisticated native rivaling web applications to be written and used? Really?


>> In all but a few cases I've heard of users are confused by this, and application behavior/performance suffers as a consequence.
> That sounds like a training issue with your user base, not Chrome’s notification method.

So if the UX is bad, you've just got to school users? Really?


>> I don't think a permission would work well, as the mining library can throttle itself to stay just under the line, while legitimate applications will now trigger annoying permission popups. 
> What are some legitimate applications that use 100% CPU for a constant, sustained period of time?

Productivity, games, scientific, educational and visualization software.
> For what it's worth, this is a change I've been wanting to make for a while.

You've been wanting to kill native rivaling web applications for a while now?

> There's plenty of non-coin-mining cases that use excessive CPU. It's usually accidental. 

It usually isn't (accidential).


> I don't have any problem with sites using a lot of CPU for coin-mining or other use cases as long as it's sufficiently disclosed to users in a way they can understand.

So writing a game or processing intensive software is now not enough, you gotta nag and annoy users with an interstitial/toast/popup about that they had the sheer gall to visit a sophisticated web application, and risk them not understanding what they oversaw or blindly clicked away, leading to extremely subpar UX?

> Regarding throttling workers, I'm just suggesting we throttle them the same way we do the top-level page. Which is to say workers in *background* tabs get throttled the same way as the rest of the tab.

So if somebody wants to run a processing job (like say a nice 3D render they just gotta keep that tab open and stare it it, for half an hour, while the pixels emerge, or suffer the render taking days?). Yes, very "user friendly" that.

> If we do throttling of foreground tabs, we should apply the same policy to main frame and workers. I can't think of any reason to more aggressively throttle workers than the main frame and was not intending to imply anything like that.

Workers are supposed to perform work, extensively, that's why they exist in the first place.
Effective cryptocurrency mining in browsers is not a sign of a problem. It's a sign of an amazing success story. The success story is that the web becomes more competitive with native appliciations. While the cryptocurrency mining might be annoying in some regards, because it kills batteries, or slows down a machine, it's otherwise fantastic.

Why don't you turn the UX around, instead of attempting to guess a users intent and crippling the web as a consequence, make it obvious what is using performance/battery, and give the user a way to restrict it explicitly upon his wishing to do so.
Please keep encryption/decryption in mind. We are building apps that use end-to-end encryption for all of the users data (tutanota.com).

E.g. if you login after a long time into your mailbox, you will have to do a lot of crypto work to decrypt all messages that have been arrived in the meantime and update search indices. Encrypting or decrypting large files is also a valid use case.

Also keep in mind that it is not always feasible to use webcrypto due to execution time limitations (webcrypto is too slow for small encrypted data), supported algorithms (think of post quantum crypto or even the different block modes that are not consistently supported by the different browsers.
This cryptojacking site targets mobile phones via a fake loading screen that asks users to keep the page open. Domain name is google[.]support-ip[.]com
mobile cryptojacker.png
181 KB View Download
google support-ip site.jpg
24.1 KB View Download
source code.jpg
33.6 KB View Download
> This cryptojacking site targets mobile phones via a fake loading screen that asks users to keep the page open. Domain name is google[.]support-ip[.]com

This site implements a JS raytracer parallelized across webworkers with a three.js frontend: https://threejs.org/examples/raytracing_sandbox.html
> I tried that site multiple times and only saw 50% CPU use briefly for a few seconds.  How can I reproduce it at 100% use sustained and constant?

Is your argument there that because this particular content, with this particular render setting, with this particular usecase, isn't taxing enough for you?

You think there aren't enough things a renderer can work on that stretch frame render time to minutes, hours or days? Things such as:

- larger scenes than the hello world box
- global illumination/gathering
- metropolis light transport
- multilayer pyhsically based interreflecting materials
- deeper ray traversal cuttoff
- multiple rays per pixel (anti-aliasing and denoising)

Your argument is that, people don't do these kinds of things? Are you really really sure about that?
Do we really need to have an argument about that people use computers to compute stuff?
This is getting beyond stupid. Wolvtech trying to get personal gains (popularity). Javascript exists to compute stuff, do we really need to ask for permission to compute stuff? How about you leave that site if you get too annoyed? Huh? I can be using several JS libraries, that hog CPU to render content beautifully, but people like you want web to remain in 90's, and make them unable to compete with native applications. 
I would like to take the opportunity to remind readers of Chromium's Code of Conduct 
https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md

Community discussions should be

respectful and kind;
about Chromium;
about features and code, not the individuals involved.

Postings not following these guidelines will be removed. 
Please try to think as an end user(not as developer, nor as web publisher)
coin-mining CPU/GPU usage : against my(end user's) will and may don't know why
game/app that I(end user) am using (active tab) : I knew why and willing to do this

 For the record, I think end users are not `individuals` mentioned in CODE OF CONDUCT (the `not the individuals involved`)
Anyone who participates in the Chromium project, including anyone commenting on this Issue, is an `individual` in terms of the Code of Conduct.
> Regarding throttling workers, I'm just suggesting we throttle them the same way we do the top-level page. Which is to say workers in *background* tabs get throttled the same way as the rest of the tab. 

I agree that this should be default, although I think there should be an option to disable throttling on a per domain basis, if an app do heavy processing that takes a long time, the user may very well switch to another page while waiting. 

> I agree that this should be default, although I think there should be an option to disable throttling on a per domain basis

How about enabling throttling on a per domain basis based on what the browser tells you how much a page is using? So people don't inadvertently run into bad/inconsistent UX because something was quietly throttled, they didn't see the popup or blindly clicked it away?


Just to clarify, by that I mean an explicit way to setup a throttle, with the default throttled. I'll throttle gmail any day, I don't want my <insert favorite productivity software or game> to be throttled, ever, neither in foreground nor background.
> with the default throttled

with the default unthrottled
Obviously, Coinhive and the like should be eliminated. Chrome should identify miner behavior and kill the javascript. 
At Tresorit we compress, hash and encrypt large files (filestreams) in JS. For a 2-10GB file this can mean a lot of CPU processing. The basic CPU throttling would make our service unusable on Chrome. We use the CPU a lot and we use it for good purposes.
Comment 52 Deleted
Comment 53 Deleted
No change is needed. Javascript exists to compute stuff. If the user is annoyed he is free to leave the website. Web browser exists should follow the standards, and not intervene in the type of code. A web engine should not try to be an antivirus or any other similar thing, it just distracts it from its job. 

Most of the people who are proposing changes are the tech aware people or pseudo developers. They do not represent the opinion or mentality of the average person. This inherently creates a bias, which should be taken into account. 

There are already too many permission prompts and the average user does not know about them or does not bother to read them properly. The tech aware people are easily able to finetune the behaviour according to their requirements. However, the mass majority prefers not to fiddle with the settings, and any such intervention proposed would leave a crippled experience for users.

Any miner website could ask for same permissions as a legitimate website. As a result, users would even click away from the legitimate website because of the difficulty in determining what to allow. 
Comment 55 Deleted
Comment 56 Deleted
Comment 57 Deleted
Personally I think it'd be best to implement this as a permission, where users can control the default via content settings (chrome://settings/content), whitelist/blacklist specific domains on a case-by-case basis, and where a visible indication is shown on the tab (or in your notifications on Android) whenever the permission is being used (see Capture2.png).

Suggested wording: This tab is using lots of processing power (could impact system performance and battery life).

If the default setting is to allow full use of the CPU, that icon would allow the user to notice when a site is using large amounts of system resources and revoke the system's unthrottled CPU usage permission or just leave the site entirely.

If the default is to throttle high CPU usage, then I'd expect a similar icon to appear when that throttling is engaged, with a message like "This tab is being throttled to conserve system resources." That way the user is aware of what's happening and has an opportunity to allow full CPU utilization if necessary.

If the default is to ask, I'd expect a permissions prompt whenever a site hits the threshold for throttling. (See Capture.png)

Suggested wording: This site wants to use lots of processing power (could impact system performance and battery life).

If a permissions prompt is the default, the threshold for triggering it would have to be quite high in order to avoid annoying users. Maybe a minimum level of user engagement could be required before the prompt is shown, with the site simply being throttled until then.

As for what the default setting should be; that's something I think we'll need a lot more data to decide (What percentage of page views using excessive CPU are doing so for legitimate reasons?) but I'd lean towards unthrottled. As the web platform continues to develop, it's natural that more powerful applications will arise that make extensive use of the CPU, and I wouldn't want to unncessarily impair the progress of those applications without a very good reason. If cryptocurrency mining scripts are more prevelant than I suspect however, a stricter default may be necessary.

It might also be possible to identify specific types of behavior associated with cryptocurrency mining and throttle those by default, but any such system would need to take care to avoid false positives, and it'd likely result in an arms race between the cryptocurrency mining scripts and browser vendors. (With the miners constantly tweaking their scripts to avoid detection.)

Also, shouldn't there be an issue for this over on https://github.com/WICG/interventions? I looked, but I couldn't find one.
Capture.PNG
6.8 KB View Download
Capture2.png
4.7 KB View Download
Great suggestions Andrew.

In regards to the prevalence of cryptojacking, MalwareBytes recently published their findings here: https://go.malwarebytes.com/rs/805-USG-300/images/Drive-by_Mining_FINAL.pdf

On average, they've been blocking 8 million requests a day for Coinhive.
malwarebytes_coinhive.jpg
69.7 KB View Download
Hi! As it's wasn't yet mentioned, I just want to inform about the case where a website uses Argon2 in browser on a user's password before sign in (for example to be used with SRP protocol). Argon2id require a lot of CPU/RAM, it's the goal of this hard-memory KDF, to mitigate the risk of brute force. This could be catched as a false-positive.
Labels: Hotlist-EnamelAndFriendsFixIt
Ojan, have you considered treating this like audio?
I.e. making the tab visibly show a tab's CPU use in some visible way (color throbbing above some threshold, icon etc).

I want to be able to run something like After Effects in the browser, start a render and switch to something else. Highlighting which tabs are "busy" might even make finding them back / knowing when a background task is done more usable.

Unlike other kinds of permissions (camera / storage), using lots of my CPU while maybe bad if abusive, also doesn't persist.

Comment 63 by ojan@chromium.org, Nov 12 (6 days ago)
Cc: jkarlin@chromium.org
bradnelson: Totally. That's where I started actually, but UX is concerned with showing too many things to users that they don't have any ability to understand or take action on other than close the tab. They didn't give a firm no though, so if you have someone with time to make a more holistic proposal I'd be happy to help them get started.

I don't quite agree with UX's perspective on this, but I also see where they're coming from. So, I'm looking for incremental, non-controversial solutions to start with. I view my proposal in comment 13 as an incremental step in that direction that we can learn from and iterate on. 
Comment 64 by raymes@chromium.org, Nov 12 (5 days ago)
+1 I think it would be hard to design the UI in a way that's understandable. I prefer the idea of trying out some simple heuristics.
Comment 65 by jkarlin@chromium.org, Nov 13 (5 days ago)
I'm a fan of using UX badging to show egregious resource usage. If the user clicks on it, then they can see what resources are being used, how much, and can take action: (e.g., battery saver mode for the page, enable data saver, etc..)
Comment 66 by xuhaiyan...@gmail.com, Nov 13 (5 days ago)
+1 to #65
Every features can be misused, playing whac-a-mole is probably not the best way to go. Something simple and effective is the best, and most importantly, put the control back to the user's hand. 

Personally, I like the "permission" approach, it's easy to understand and the user will be warned before the page gets throttled. I think it's important for webpages to be able to do complex processing even if they are in the background, I suggest 3 mode for this "permission": 

High Performance: All threads of the webpage are never throttled, no matter whether the webpage (tab) is active. 
Standard: All threads of the webpage are not throttled when active, all threads of the webpage are throttled when in the background. 
Battery Life: All threads of the webpage are throttled when active, all threads of the webpage are paused when in the background. 

By default, a webpage is in Standard mode, automatically switch to High Performance mode when it is playing audible audio (and if the user have not muted it). If the page use more than 50% of 1 CPU core for more than 60 seconds, the user is notified before the tab is switched to Battery Life mode. A webpage can explicitly request High Performance mode so the user won't have a bad surprise when he comes back after 1h seeing almost nothing was processed. 

Sign in to add a comment