New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 766068 link

Starred by 64 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Feature
Team-Security-UX

Blocking:
issue 776416

Restricted
  • Only users with EditIssue permission may comment.


Participants' hotlists:
Hotlist-1

Show other hotlists

Other hotlists containing this issue:
Cpu-Throttling


Sign in to add a comment

Please consider intervention for high cpu usage js

Reported by sobi...@gmail.com, Sep 18 2017

Issue description

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?

Comment 3 by lgrey@chromium.org, Sep 20 2017

Labels: -OS-Mac
Getting this out of the Mac triage queue
Cc: kkaluri@chromium.org
Labels: Needs-Triage-M61
Status: Untriaged (was: Unconfirmed)
Since it is marked as feature request, untriaging this issue 

Comment 5 by raymes@chromium.org, Sep 25 2017

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.

Comment 6 by vakh@chromium.org, Sep 26 2017

Labels: Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Assigned (was: Untriaged)
ojan@ -- Please help triage this. Thanks.

Comment 7 by t...@wolvtech.com, Sep 30 2017

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/


Comment 8 by t...@wolvtech.com, Oct 7 2017

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.

Comment 9 by t...@wolvtech.com, Oct 13 2017

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

Comment 10 Deleted

Comment 11 by t...@wolvtech.com, Oct 13 2017

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

Comment 13 by ojan@chromium.org, Oct 19 2017

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. 

Comment 15 by ojan@chromium.org, Oct 19 2017

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.

Comment 16 by bry...@zadegan.net, Oct 19 2017

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

Comment 18 by pya...@gmail.com, Oct 20 2017

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.

Comment 19 by pya...@gmail.com, Oct 20 2017

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

Comment 22 by t...@wolvtech.com, Oct 20 2017

> 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

Comment 24 by t...@wolvtech.com, Oct 20 2017

> 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 ;)

Comment 26 by sscar...@gmail.com, Oct 20 2017

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

Comment 27 by kbr@chromium.org, Oct 20 2017

Cc: kbr@chromium.org

Comment 28 by kbr@chromium.org, Oct 20 2017

Blocking: 776416

Comment 29 by kbr@chromium.org, Oct 20 2017

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.

Comment 30 by ojan@chromium.org, Oct 21 2017

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.

Comment 31 by ojan@chromium.org, Oct 21 2017

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

Comment 34 by pya...@gmail.com, Oct 21 2017

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

Comment 35 by pya...@gmail.com, Oct 21 2017

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

Comment 36 by pya...@gmail.com, Oct 21 2017

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.

Comment 38 by t...@wolvtech.com, Oct 21 2017

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

Comment 39 by pya...@gmail.com, Oct 21 2017

> 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

Comment 40 by pya...@gmail.com, Oct 21 2017

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

Comment 41 by pya...@gmail.com, Oct 21 2017

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. 

Comment 44 by sobi...@gmail.com, Oct 24 2017

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. 

Comment 47 by pya...@gmail.com, Oct 30 2017

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


Comment 48 by pya...@gmail.com, Oct 30 2017

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.

Comment 49 by pya...@gmail.com, Oct 30 2017

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

Comment 51 by a...@rigo.sk, Nov 7 2017

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

Comment 54 Deleted

Comment 55 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 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

Comment 59 by t...@wolvtech.com, Nov 7 2017

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 2017

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

Comment 67 by t...@wolvtech.com, Nov 26 2017

30,000+ websites are now engaging in cryptojacking activities.

The latest cryptojacking campaign affected 1,400+ websites including those of Crucial Memory and Everlast. This was done via a compromised live chat widget.
https://www.bleepingcomputer.com/news/security/cryptojacking-script-found-in-live-help-widget-impacts-around-1-500-sites/


crucial memory.png
428 KB View Download
everlast.png
809 KB View Download
Issue 786846 has been merged into this issue.
Any progress on this? Javascript cryptominers are a scourge. The situation is getting increasingly worse. The web badly needs an emergency update to Chrome that deals with coin miners.

Comment 70 by ojan@chromium.org, Dec 20 2017

Owner: ellenpli@chromium.org
Ellen, assigning to you since you're driving now. :)

See also related issue 734848.
I do have to flag up also the fact that coinhive and the likes use an indecent amount of upload bandwidth. This is something that on some connections (my home broadband for example, or any customer with a low-quality router) causes every other connection to drop so the damage isn't only on lost computational power.

As user first I would like to get notified on the top when my browser is doing some heavy processing, in the very same way I get notifications about a tab that is probably stuck or in the very same way I get the notification about the blocked flash file.

If Chromium can detect a "mining" behaviour from Javascript then I think it should be absolutely disabled by default and allow the users to "opt-in" and support the website they're visiting enabling mining at their discretion.

If Chromium can't detect whenever it's mining or just using CPU on something legit then as a Web Developer I do _totally_ support what has been said on #65 and #66, I do work sometimes with WebGL and pages which drain a lot of CPU time but I am _absolutely_ fine if my user will be notified that the tab is taking a toll on CPU or battery life.

Comment 72 Deleted

Comment 73 Deleted

Cc: cbentzel@chromium.org
Escalate!  

This is a seriously big problem which doesn't seem to be getting the attention or expedience it deserves.

In the meantime, users will need to resort to using extensions to block these.  

Unfortunately, yet not surprisingly, there are already several malicious extensions which pretend to block such activity, but actually they inject ads or perform other nefarious activities.

One example:

Supposedly Legitimate "minerBlock" extension:
https://chrome.google.com/webstore/detail/minerblock/emikbbbebcdfohonlaifafnoanocnebl/reviews?hl=en

Here is a clone of the above "minerBlock" extension, which numerous users have reported is malicious:

MALICIOUS: https://chrome.google.com/webstore/detail/minerblock-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-%D0%BC%D0%B0%D0%B9/jdkbipcangaabpfffdcffcneenkilajh?hl=en

This is just the tip of the iceberg.  The problem is exploding exponentially because you are leaving the opportunity open for such malicious activity to target the Chrome userbase.

On Oct 19th, 2017 Raymes wrote:
"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."

Clearly this is the OBVIOUS way to go.  Like he said, this is a reasonable starting point and then from there you can tweak and adjust it.  At least this will help solve the problem for the vast majority of users.

As always, I write with the utmost respect, admiration and appreciation.  Thank you very much for your time and efforts.  But seriously, this needs to be prioritized.  That being said, please provide a status update.
MinerBlock_scam.PNG
52.9 KB View Download
Since this change will break many sites, I would like the owner of this issue to explain what will be implemented before doing it. I have a factorization calculator ( https://www.alpertron.com.ar/ECM.HTM ) which is visited by hundreds of people each day which naturally uses 100% of a CPU core, but it performs no communication to any server (I believe all Javascript miners have to perform some communication to retrieve the results).

Many scientific applications have the same behavior.

So I think that only the scripts that behave like a crypto miner should be stopped.

Comment 77 by t...@wolvtech.com, Jan 18 2018

What change will break many sites?

What "many scientific applications have the same behavior" as cryptojacking?

"naturally uses 100% of a CPU core"
In my tests, your website only used 15% of my CPU.
factorization.png
330 KB View Download

Comment 78 Deleted

Your processor has six cores, so 100% of a core is 16.7% of the entire CPU.

Scientific applications perform large calculations, normally in only one thread, so they use one processor core.

If this use case is not restricted (say up to 200% of a processor core), I have no problem.

Anyway, it would be difficult to know if a particular tab in the Web browser is consuming 100% of the complete CPU. For example, if you go to two different Web pages which mine cryptocurrency, both of them will open lots of workers and after fighting for processor resources, each tab will use 50% of the CPU, so none of them will be restricted. How can the owner of this bug detect this condition?
There are two problems here when a tab wants to open lots of workers to consume 100% of CPU: Web browser or operating system responsiveness and battery drain in mobile devices.

The first problem can be easily solved by decrementing the priority ("nice" in Linux parlance) of the threads or processes (I do not know how Chrome implements Web Workers) which holds the Web Worker.

In this case even if the workers consume 100% of CPU, the foreground Javascript and the browser can always respond quickly.
Hey, sorry if I'm not that knowledgeable enough to help on this. But here are my two cents:

Why not color-code the tabs based on CPU usage on Chrome desktop?
Let's say that we could use 2 shades of red (one darker and one lighter), the current gray and two shades of green (one lighter and one darker)

We change the color of the tab on the tab strip based on how much CPU it's using. Something like this:

 CPU usage --- color of tab
---------------------------
100% - 70% ---  dark red
 69% - 50% --- light red
 50% - 30% ---       gray
 30% - 20% --- light green
 20% -  0% ---  dark green

I'm not actually a typical user, but a bit closer to power user.
Since I tend to have a lot of tabs open at once, having the tabs color coded by resources usage would make it a lot easier to know what to close, especially if the laptop fan starts spinning too fast.
We could also extend such a system to also show RAM usage in the future.
IMO, s background tab using 20% deserves to be dark red.

I have 25 tabs open right now, and I'd love to throttle everything except this one to 2%.
Ok, so expanding on the color-coded idea but taking also @skenned comment into account.

First, why color coding tabs instead of adding an icon on the tab:

I have a large number of tabs open at every moment. The tabs get so small on the tab strip that I can't see neither the favicon nor the mute icon, I'm only able to see half of the first character on the page title.
Color coding the tabs would allow both me and people who have similar setups (lots of tabs) to use the feature.
Color coding might make the typical user pay more attention since the tab will be, for no apparent reason, red and their computer hot.


It could be good idea to restrict the colors to red on tabs based on CPU usage. Maybe do something like the following:

For 20% CPU usage show a light shade of red, for 21% until 99% CPU usage show a progressively darker shade of red, for 100% show a dark shade of red.

The green shades would be instead used to mark which tabs were allowed to use CPU without being throttled.
Since, if you are a power user, you are likely to use the pin tab functionality, maybe using that might be a considerable way to solve the issue.

Assuming the tab CPU usage gets over 20% then the following is done:

If it's the foreground tab on the foreground window then color it dark Green. (No throttling)
If it's the foreground tab on a background window then color it light Green. (No throttling)
If it's the a pinned tab on any window then color it light Green. (No throttling)
Else color it a shade of red equivalent to the usage. (Throttling)

It could be useful to add a exception system visible to the user: if they go away from a resource intensive tab the tab would get red, when they get back there could be a banner asking "This tab wants to do some heavy computing, allow?". Allowing that would opt-out of throttling.
Note that staying on the tab doesn't activates the throttling.

These are my two cents. There might be an useful idea in what I wrote.
It has been four months since this was first raised.

From an enterprise IT director's position - we first started seeing this on a wide spread basis in mid-December 2017.  The symptoms not only included high CPU usage but sites resulting in "aw snap" errors.  With a little bit of investigation we were able to determine these issues were related to coinminer JavaScript (as the code was found in Chrome temp files).

The antivirus / endpoint protection vendors seem to be somewhat on top of this now.  BUT: not everyone has a suitable product on their system and most people have nothing on mobile devices.

The enterprise product we use (whilst initially was providing no protection) seems to be helping mitigate impact from coinminers.  Still - over the last few months the miscreants that are serving up this stuff are evolving their delivery mechanisms.  Initially we saw plain text JavaScript files and that morphed into various kinds of \HEX encoding and obfuscation to WebAssemblies.

While initial reports of coinminers indicated many sites had the JavaScript embedded in the site, our experience is that this is all being served up by third parties (likely ad servers).  And NONE of the coinminers I've seen ever let the user know that their system will be used for this purpose, allow them to set a throttle or opt out.  The intent is clear: get the coinminer code running on as many systems as possible (and without the user being aware of it).

A lot of discussion in this thread has revolved around the fact that the undesired coinminer script has high CPU utilisation.  High CPU utilisation isn't necessarily an indicator that something is nefarious.  While I like the feature of colour coding Chrome tabs I am not sure that is going to help the general user.  (I currently have 11 Chrome processes in Windows 10 and only 4 Chrome tabs open.)

And while giving the end user a way to see Chrome's CPU utilisation (the original issue asks for "intervention for high CPU usage JS") I think the real issue here is eliminating the mechanisms that allow Chrome and a user's system to be hijacked (by coinminers today, and who knows what else tomorrow).

Some interesting stats from the eset virus radar site - the prevalence of coinminer has been running at +20x other threats for some months now.:
http://www.virusradar.com/en/JS_CoinMiner/detail
http://www.virusradar.com/en/JS_CoinMiner/map/month
http://www.virusradar.com/en/statistics/10

In comment 54 it was mentioned "A web engine should not try to be an antivirus or any other similar thing, it just distracts it from its job."  While I tend to agree Chrome does have features to help protect users from malicious sites, certificate issues, etc.  When a problem like coinminer occurs I think there is value in the core product providing some level of protection versus having to rely on end users having some kind of antivirus or endpoint protection software on their device or system.

Comment 66 mentions "playing whac-a-mole is probably not the best way to go."  I agree.  And setting a CPU threshold utilisation point would be just that.  Whatever number you set it to ... the miscreants can just set their code to run at a point or two below that ... and it is under the radar.

Conclusion: while I think there may be some value for addressing high CPU usage in Chrome I think that in itself isn’t going to do much to mitigate the issue of coinminer or anything similar that gets delivered up in the future.  
Cc: shivanisha@chromium.org
Another aspect that I do not see mentioned is VDI environments. Everyone has been discussing resource management in chrome in regards to security but there is also the performance aspect as well. I opened issue 699252 before this case was open to review high CPU utilization in the chrome browser and it's impact in VDI environments. This case has much more traction, insight, and discussion and I wanted to add to the thread.

I see Bob's comment #84 considering the browser's role as well as the security solution's role. I agree that throttling malicious content doesn't address the fact that the content is still running - it only addresses the resource runaway. I tend to agree stopping the malicious content would not be the responsibility of the browser - it would be in a security solution's purview. 

I do see use cases for managing the resources at the browser level though. I do not believe content on a site should have the ability to have an adverse impact on the entire client. Allowing a site to runaway without checks and balances to assist with handling poor/inefficient or malicious code impacts more than just that site in that tab. It has a snowball effect on the other tabs in the browser, other processes on the machine, and in a VDI environment, the hypervisor itself which then impacts other user sessions. 

It was mentioned content on sites may have legitimate reasons where resources will spike which is understandable but I believe the functionality should be available to manage the resources whether it be a dynamic automated process or an administratively set option under the experimental flags. 

Comment 87 by t...@wolvtech.com, Feb 2 2018

Google advertisements were pushing Coinhive for a week onto YouTube users.
https://arstechnica.com/information-technology/2018/01/now-even-youtube-serves-ads-with-cpu-draining-cryptocurrency-miners/

Comment 88 Deleted

Comment 89 Deleted

Labels: -Hotlist-EnamelAndFriendsFixIt
Dear Google Chrome Team,

I think there is no excuse not to add this feature, it is very simple to do and you should look at this github plugin found here: https://github.com/xd4rker/MinerBlock

They create a simple whitelist like a CSP Type style to block mining just like xss.
Please don't restrict this to just looking for mining hacks. The palm beach post web site, https://www.mypalmbeachpost.com/, often triggers 100% cpu usage for completely undetermined reasons (which I assume is incompetently coded javascript) and I was just at the cnn page https://www.cnn.com/2018/02/20/us/thoughts-and-prayers-florida-school-shooting-trnd/index.html where something (no idea what) is using so much CPU that I often cannot scroll the page without huge delays. Something that would pop up a message saying "this javascript is using vast amounts of CPU, shall I kill it?" would be perfect.
It seems to me that the following would be a great step:

- add a setting "Inform me when a site uses more than [value1]% CPU for more than [value2] seconds" (where I can set value 1 & 2).

- when I am warned, I get to choose to throttle the site or block script execution entirely. I also get to make this a permanent setting for the site.

This feature would deal not only with crypto miners but the all-too-common broken sites that just misbehave.


Cc: -raymes@chromium.org
Making this a site (host name / IP address) based setting probably wouldn't
be of much value because the miscreants that create this kind of code
(cryptominers and the like) use throwaway domains and frequently change
hosts (and IP addresses) in order to avoid this kind of blocking.

Such a setting (percent CPU utilisation) would need to have a default and I
would suspect that to avoid detection anyone who creates something like a
coinminer script would just set it to run under / below that default
setting.

I would also be very concerned about default settings that would end up
creating a lot of false positives ...

While those who are subscribed to this list could probably understand such
an interaction with Chrome (warning Will Robinson, excessive CPU
utilisation on blah blah blah) ... whatever the implementation of a
protection mechanism is ... I believe its in everyone's best interest in
that it works for the masses.

I think the solution is simple for many sites where 100% of the content can
be delivered from the site: block content that comes from other third party
sites (think XSS and the like).  The reality today is that sites typically
rely on adverts for revenue and much / most of that is served up by third
parties.  Gets worse with the handling of remnant advertising ... and this
is likely where much of this malware comes from.  (Other than a site being
hacked / infected.)
Labels: Restrict-AddIssueComment-EditIssue
I think there's been sufficient input here and it really needs someone (along with a PM) to take it and to compare concrete options and outcomes in a document to work towards a solution. So I'm restricting further comments.
Cc: -junov@chromium.org
Cc: -kbr@chromium.org ericrobinson@chromium.org

Sign in to add a comment