[Proposal] navigator.cpu


I’m not sure if that was meant for me. I’m sorry if my talk hurt someone, never really meant that.

There are already other enough ways. This is not an excuse to be against the standard. Privacy conscious users could always disable this from the flags.


@Garbee Agreed.


Can you give a use-case of how your app would use this CPU information?

I have yet to see any direct example of how it is expected to function in the JS engine. What kind of code do you expect to write to take advantage of it? What will the engine be doing? I keep hearing what is essentially, “trust me, it’ll optimize” but no one showing what that optimization is. JS execution is inherently single-threaded. So unless you’re spinning up multiple web workers or doing other things to push processing off the main thread I don’t believe you’ll be getting what you expect out of having this API.

Since this feature adds to the capability of tracking individual users more specifically, it should be opt-in not opt-out. Regardless of how “well it’s already done so this must not be a privacy issue”, it adds to the capability. User privacy is extremely important to web standards.


Why should privacy be opt-in?


It shouldn’t, of course - and can’t be.

It’s OK for someone running some game or other to be able to do a tweak on their local system, just like overclocking or using a mechanical keyboard :slight_smile: but it would need to be per application. However, no measurements or other evidence have been provided to show the requested feature would be useful - maybe it’s being asked for by a couple of advertisers who want it to help them track people?

In addition, the ability to require a specific processor has a lot of potential problems, ranging from vendor lock-in to Web sites that stop working over time when they’re unmaintained. So feature tests where needed, ideally based on actual measurements on the client, and graceful fallback, sounds like a safer approach to me.

Also, as others have noted, knowing the number of CPU cores doesn’t necessarily help, as it doesn’t mean you can run parallel threads in your application directly, nor that you can create additional processes! It might be an indication of the number of browser windows/contexts that could be active, but that doesn’t take into account what else is running in the browser, or on the computer itself.

Anything added to the Web Platform has to work on all devices (where it makes sense of course) including desktop and notebook computers as well as mobile devices. Do you (original poster that is) have benchmarks you can post that show performance differences in a suitable range of devices? Or functionality you can do only if you know the CPU’s name?



As far our benchmarks, I’ll quote some of them:

Much more stability, max performance remains the same however.

We will fallback to no optimization when no CPU name is found in our database. There is no other way around this. 40% increase in stability of FPS. This data is not raw, and I made it into a quick spreadsheet for easier understanding.


I recognize that some posters on this thread have already dismissed any privacy (or “privacy”) concerns as irrelevant or as holding Web features back unnecessarily, but as this came up on a teleconference today I thought it would be useful just to add a little more detail.

Access to specific information about hardware is a particular privacy issue not only because it allows for browser fingerprinting (in this case, active, cross-origin browser fingerprinting) but also because it’s typically unchangeable by the user and thus persistent (which removes the ability of common user controls to reset cookies or other identity information) and available across browsers on the same device, across different browsing modes, present even when the user is on a different network, etc.

I think if people want to pursue this further, you’d want to explore a special opt-in capability; that this API wouldn’t generally be needed, but if you’re trying to install a specific high-performance game from a trusted developer, there could be some special permissions involved, applied to a particular top-level origin only. That’s been discussed sometimes around installable Web applications, although it’s hard to separate these especially significant permissions, particularly when the implications are hard to explain to end users.


Thank you, that sort of information is useful in building a case.

The cost of new features is very high, so the case for them has to be solid.

However, as i’ve said, and as others have said, a feature like this needs to be opt-in. I think Nick Doty’s point could be addressed by allowing users to override the CPU name, graphics card name, etc. in preferences, just as some browsers make it easy (or possible) to send a fake user agent HTTP header value, or not to send it at all.

I think also you need to be clearer about why the CPU name is required, rather than specific features the CPU supports.

It’s unfortunate that the graphics card name is already exposed in some browsers, using gl on a canvas, although that may change in the future.


Sadly, its because we built our products based on CPU name. Exact optimization for hardware works better than optimizing for features. We cant detect features with bench-marking. It is too inaccurate. We tried figuring out users clock speed with no luck. Too inconsistent.

There is no reason in hiding that. GPU info is very easy to detect via benchmark. Vendors already know this. It is easier to expose this, so if an optimization exists for the card, we can use it, without wasting 30 sec bench-marking gpu.


Yes there is. Once again, it’s about fingerprinting a specific visitor more accurately. The very same thing already discussed multiple times that you seem to refuse to see as an issue.

Through JavaScript? Do you have an example of this working that you can share?

These numbers aren’t in themselves convincing that this feature is needed. They do compel a good number of questions though to see what is going on.

  1. Are these tests through a browser or via a native app?
  2. If it is through a browser, what is the code that ran?
  3. Could you provide a running sample that anyone can openly operate to compare results?

It’s one thing to provide a bunch of numbers. It’s another thing to provide that plus code others can run to see the results for themselves. It doesn’t need to be anything from your product directly, just some example that demonstrates this CPU optimization in the current web if this information is made available.


I’d rather not. You’re overly privacy conscious.

Because there are millions of other way to do the same thing. A browser is supposed to have security, and speed and give a path to developers to optimize their products to the top. Maintaining privacy is the task of the person using it, or extension.

  1. Browser (Chrome Canary)
  2. Benchmark the entire game. Took 4 days. We ran Javascript, WebAssembly and WebGL. Javascript for minor ui stuff. WASM for physics based calculations, and WebGL for rendering.
  3. No I’d rather not.

We’re not going leak our product at this point. Expect it to be presented at GDC 2019.

P.S: Web developers here have too limited knowledge only in their domain. I’m not sure why are people here overly privacy conscious. Everyone seems to be concerned too much about privacy where as no one is really willing to put features over that. It is mostly the senior developers who are too much concerned about “privacy” I have observed however, as they still stuck in 90’s ARPANET


You keep waving your hands and saying “but we can do it anyways, not a problem!” when in fact, yes it still is a problem. Browsers also make decisions to that protect user privacy. Like it or not, the vast majority of people using a web browser never touch a single setting. They don’t understand the privacy implications of what they do most of the time. Browser makers do have that understanding, so we attempt in standards to help protect privacy as best we can while providing new APIs to allow for cool new things to be built.

Which is why I asked for something not necessarily related to your product. Just anything that demonstrates the performance gain that can be openly shared. If you are incapable, that’s fine. I ask you don’t think I asked for your whole product to be shared just to demonstrate your numbers though, that’s certainly not the intent.

Maybe these two go hand-in-hand. Because we have knowledge about our domain, we understand the privacy implications it has for users here. Where on native, “Who cares? We could always query this stuff and no one thought twice about it.” Well, the web functions differently at it’s core. A different set of morals apply to what browsers can provide to developers at the cost of end users. You’re bringing native morals to the web and that doesn’t mix.

We do desire new features. However, they need to be brought in safely in a manner that helps protect people. The web isn’t, “What does native have that we don’t? Ok, let’s just do it.” there are different concerns that you don’t seem willing to accept exist.

@npdoty brought up an interesting point though. An origin-specific whitelist for the permission to occur is feasible. So developers using this info would need to get permission from vendors to even request it from users by the origin URL. While it is a difficult scenario UX wise for browsers, it does add a safety net if someone is found to be abusing this API they can have their access revoked. That’s the kind of thing we need to have some kind of oversight in the usage of this. Is that kind of permission model something you’d be willing to compromise on? Having a hard-line “ignore people’s privacy and give me what I need in a full publicly accessible API” is not going too far.


Uhm… kind of hard to decide. On one hand people say that it is the open web, on the other, there is an encouragement of giving something exclusive to larger corporations. Open web means that smaller competitors to us have the same ground. Does not hurt to get artificially better performance, however.

If the community is okay with it, we dont have a problem with us having an edge :stuck_out_tongue: Back to square one.


What is this “exclusivity”? Anyone could request permission, you would just need to basically provide a mutual promise on what the data is used for. If you’re found violating that, then your access would get revoked. Almost like how the HSTS preload list works, just with API access to more sensitive information. No restrictions based on company size has even been mentioned.


Not enforceable. Those who want to abuse will register new domains, and use them there. HSTS has no advantage for tracking therefore it is not abused.

The only suitable option left it is to give access to all websites without any sort of whitelist. This is not how the web works, and nor do the people want this. The people who are concerned about ad tracking could disable in flags. The people who dont care (majority), can have a better experience.


We understand to you that the ability to disable it is all that is ever necessary. I don’t think it needs repeating, yet again.

A well done white list of origins could do the trick. However, GDPR negates the ability to do that now. So thinking over it again that isn’t a good option.

Any other ideas for achieving informed user consent before access to this kind of API would be allowed? I don’t feel our current notification method would do the trick. “This site is asking for CPU information. Would you like to provide it? Yes/no” isn’t very informing. Most people wouldn’t understand the ways this kind of thing could impact them.


I meant less a browser-maintained list of origins (although that has been considered, and is in use for HSTS, and HSTS indeed does have documented abuses for tracking and browser vendors do deploy countermeasures because they have identified that user privacy concerns are significant), but rather that you’d want to design a special user-permission to be granted (for top-level origins, rather than embedded iframes, as otherwise advertising tracking scripts would be by the far the most common user of this API) for certain installable, processor-intensive games. Yes, permissions can be abused, and attackers do register new domain names to get around safe browsing and other browser restrictions on abusive domains, but having the ability to mitigate abuse is still useful.

I recognize that you believe that no one cares about the privacy implications, or that it’s only a subset of technical users who can disable certain features in their browser. If you have data on the number of users who want to automatically share their detailed CPU information and the number of users who specifically don’t care about privacy of tracking online behavior, you should feel free to share it with us. I don’t think repeatedly dismissing expressed concerns that you don’t care about is a useful way forward.


I’m talking about the HSTS preload list.

It is not vendors fault if people are unable to determine the privacy risks, if they really care. Either way, I think if everyone is too concerned about privacy, than lets end this here. We wont be distributing our product on the open web however. Guess will make our own fork of Chromium than, and distribute it on play store. People could use our product there only however, and other websites can than leverage the information for better user experience or tracking if they wish for more relevant ads. If you want to stop the progress of the web, better to not follow the standards that are too precautionary. It could than be implemented as a non standard, and just like EME and DRM, the W3C will have to agree to this too.

90’s is now gone. It is time to put user experience > pseudo-privacy.


As a comparison here, it is then perfectly fine to install a cryptocurrency miner on users computers behind another application, say a 2048 game, without them knowing. In this case, app stores should have no right to revoke the apps from the stores, because if “end users cared” they’d figure it out on their own.

There is an ethical obligation of anyone making software that helps users access other developers’ software also help prevent abuses against end users.

You’re asserting that everyone on the planet should understand everything about how the internet works. That’s just a bad scapegoat to try and make your case. Not even people who work in the web fully understand the implications various things may have. How could we possibly expect this of every person on the planet? My veterinarian should not have to know what CPU Info even is, much less how that could be used to determine them within a network. People assume privacy is a default. Even in Facebook when they “have clear controls with each post to set who it is shown to”, most complaints I here are, “but I didn’t know it was going to everyone.”

If you’re coming from the stance of “everyone should know this and if not it’s their own fault” you’ve already lost. The goal is, “What are other people expecting?” and “What can we do to help make sure those expectations are met?”. Expectations go far beyond just “the best experience”. People do what good experiences, but if they meaningfully understood some of those tradeoffs, they’d be very wary of doing so. When building web standards having empathy for other people’s situations is an absolute must. Instead of having none of it and saying, “Well if you don’t know it is your fault.” No, it’s not their fault. It’s the fault of organizations that believe they should have access to anything and everything without question and have no true accountability for their actions.


Since this is going no where, its all right. I understand the concerns of the web community, therefore will go native. We don’t want to harm users choice, so our minor product is no reason to risk people’s choices.

Thanks a lot everyone for your input.

Mod’s I’m abandoning this account, please delete my posts, especially the one with the title “post withdrawn by the author)”. After this, any content written here in the future is not my responsibility as there is no option of deleting the account. It was created using a temporary email address, which will be accessible to anyone after I delete it, and anyone else can control this account.