[moron4hire]

What is your proposal? Forget the browser for a minute. Just any way, short of airgapping, that a user could receive an app, want that app to perform maximally, but also not have information about the system being egressed?

I don't appreciate it because it's childish. You want to make this out to be a privacy issue when it's not. It adds nothing meaningful to how easily you can be fingerprinted, but removing it would detract significantly from how performant a browser-based application can be made. Without it, you're pushing developers towards having to build native apps instead, giving even MORE access to the hardware fingerprint, where they are now stuck having to pay fealty to the platform gods, while also gaining nothing in reducing fingerprinting in the browser.

[seniorgarcia]

I do not dispute that you can use this in your app, my issue is with the server knowing about it (as it is in the demo here) and everything the server can call back from the client. It is not about airgapping but about realizing that current browsers can exfiltrate basically anything.

Your JS app wants to compute the amount of threads it can use on a client, that's great. If your JS app can calculate me switching browsers and using independent websites and their usage, that's cool. Why would you send that back to your server though?

If you do not think that current browser implementations have an issue with the amount of fingerprinting they can do, that is up to you as well. I think that the amount fingerprinting is at the very least difficult though. It is not about building native apps, it is about the amount of information that is send back. Or I'm drunk at this point and should go to sleep, I think I'm done in any case. Sorry about being an ass.