[Proposal] navigator.cpu


#43

No one said it can’t go anywhere ever. There are privacy concerns that should be vetted and discussed before it moves forward in my opinion. You however seem to be entirely against the notion that it is an issue. From that you’re refusing to try and actively work towards a solution that respects users. The only person currently that is holding this request back, is yourself.

An important part of the specification process is having push-back in various areas. It helps make the idea more concrete even if the original proposal is unchanged. People making requests need to be accepting of this and attempt to be productive within it. If you’re not willing to even consider that even one part of your suggestion is wrong in the slightest; then the process as a whole becomes much more frustrating and laborious than it otherwise would be for everyone involved.

If this push-back doesn’t happen, things like AppCache happen. You throw a bunch of brilliant people into a room to solve a problem in mostly isolation. That spec then ends up being so narrow in applicable uses it is nearly unusable for the majority of people. That’s just one example of how things can go wrong if parts of proposals aren’t questioned.

If you’re going to propose web features, you need to be prepared for this. It involves understanding that you’ll need to defend various points. Provide data to support your claims. Have processes and examples ready to show developers on their own hardware what you mean if it is something that can run in some form today. That way, you can construct a strong case for your request as it was made. It also means being prepared that maybe you aren’t considering the whole situation. In those cases, you may need to compromise in some fashion with browser vendors or developers from the community contributing to these discussions.


#44

Personally I do not have the knowledge to add much to this discussion, however I think with upcoming technologies like https://oysterprotocol.com which depends on “Website visitors contributing a small portion of their CPU and GPU power”, concerns from website visitors may arise (as an aside I must agree that this solution seems better than the current state of ads on the web).

I would assume, browsers would need at some point interfere with how much CPU an application may “borrow” from the user.


#45

Unless you are a small or medium-sized company trying to sell a product, in which case you need to use ads to tell people about the product. Ideally you’d like to restrict this to people who are likely to be interested, but today that involves more of an invasion of privacy than most Web users (or a very large minority of Web users) seem happy about.

APIs that would facilitate fingerprinting generally need to show a strong benefit to a wide range of applications, rather than an incrememntal improvement to a single unknown application in a possibly- proprietary manner.

Liam


#46

Chrome for one is already looking into this. But, pushing that kind of thing forward is a discussion for another topic. Highly valuable discussion to have, just not on this un-related thread.


#47

Native applications are not generally installed from random websites. People use trusted sources to install them. Both Windows, Linux and OSX have mechanisms to verify that the source of the application is trustworthy, and that means a good deal of red tape for application developers to distribute their application. None of these mechanisms are perfect, but dropping them would leave users in a way worse situation, which is why these operating systems still choose to trade better UX (install whatever you want in 1 click) for safety.

Conversely, the web doesn’t have any of that red tape. Anyone can register a domain and host code there. Therefore, the web is much more exposed to bad actors trying to ship malicious code to the users. There is no central authority that certifies that a website is safe and users can rely on. It’s good that web standards push hard against features that expose users to new attack vectors, both in terms of security as well as privacy. Privacy isn’t just about ads. When a malicious website can identify that you are the same user that visited a genuine website earlier, they can create more targeted phishing or hijacking attacks against you, so privacy concerns can turn into security concerns.

That said, I also have a background in realtime graphics, and I understand how choosing code paths based on the CPU and GPU specifications can improve consistency of frame rates. This feature request is useful to bring more high quality video games to the web, but it needs to do so in a responsible way.

Providing access to the exact CPU model seems worrying for all the reasons stated above, even if it is protected behind a permission, because users won’t understand the danger. But perhaps that information can be quantized in a way that’s still useful for real-time applications while not uniquely identifying users, or we can come up with other ways to protect users.

I’d like this discussion to not be shut down just because the first proposal wasn’t perfect. Can we keep iterating on the design to find something that is still both useful for the original objective and improves privacy?