Live data from Hacker News

Chrome ships WebGPU

developer.chrome.com

181–190 of 405 posts

Re: Chrome ships WebGPU

#181
post #30

Earlier quoted context omitted.

There is no way to escape fingerprinting. Just one example: A script which runs many different types of computations. Each computation will take a certain amount of time depending on your hardware and software. So you will get a fingerprint like this: computation 1: ** computation 2: **** computation 3: ********** computation 4: ** computation 5: ************** computation 6: ************ computation 7: ********* etc…

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

I do this since forever, but I have to give explicit permission to load and run JS, which solves a lot of other problems as well. Letting any site just willy-nilly load code from whereever and run it on your machine is insane, and it's well worth the effort to manually whitelist every site.

Re: Chrome ships WebGPU

#182
post #51

The browser truly is the new OS, for better or for worse.

They couldn't secure our OSes to run untrusted code safely, so they built a OS on top of a OS (yo-dawg meme here). It wouldn't even be so terrible, if it didn't tie us down to a crappy language (JS).

I think the real reason the web was built was because Google, etc... Decided they need a distribution platform that could not be locked by OS vendors, as that would be a theat to their business.

Re: Chrome ships WebGPU

#183
post #118

Earlier quoted context omitted.

Google has many hands in many pots. It's not that they are necessarily looking for easier ways to do fingerprinting. But they sure as hell wouldn't put up a fight to make it harder.

Then why does Chrome contain loads of features to make fingerprinting harder?

Chrome has to walk a fine line between what it does for privacy and what is says it does. So you have the protection against fingerprinting and at the same time you have the FLoC fiasco

Re: Chrome ships WebGPU

#184
I'm very curious about isolation. Nvidia doesn't allow virtual GPUs on their consumer card drivers so this isolation feels like it can easily be abused. Will there be more support for vGPUs in the future? I hope Nvidia and others are pushed to include better isolation and vGPU support so that WebGPU doesn't need to do all this security isolation themselves. Your browser could theoretically request a vGPU instance to work on.

Re: Chrome ships WebGPU

#185
post #145

Earlier quoted context omitted.

> But closer inspection showed that its use was to get user's IP address for better fingerprinting. Maybe that's why it fell to the wayside: scripts are no longer allowed to get the local IP address (taking with it the most useful aspect of WebRTC, true serverless p2p without internet[1]). [1] I'm not saying that I disagree with the decision, but still sad that we can't have nice things :(

Yes instead of IP address the API now provides Apple DNS hostname. But a proper solution would be to put this unnecessary API behind a permission.

There are too many APIs that need to put behind permissions for permissions to be useful.

No idea how to solve this though.

Re: Chrome ships WebGPU

#186

This is a comment from Aras Pranckevičius [1]: > WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol) > As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd itera…

Think about bindless as raw pointers vs handles. In bindless (pointers) you say "at this GPU memory location I have a texture with this params". In non-bindless you say "API create a texture with these params and give me a handle I will later use to access it". Bindless gives you more flexibility, but it's also harder to use since it's now your responsability to make sure those pointers point at the right stuff.

It's a bit more complex than that. In classical OpenGL (and thus WebGL) "bindless" is more significant: You had to bind resources to numbered stages like TEXTURE2 in order to render, so every object with a unique texture required you to make a bunch of API calls to switch the textures around. People rightly rejected that, which led to bindless rendering in OpenGL. Even then however you still had to create textures, the distinction is that you no longer had to make a billion API calls per object in order to bind them.

Critically however, things like vertex buffers and fragment/vertex shaders are also device state in OpenGL, and bindless textures don't fix that. A fully bindless model would allow you to simply hand the driver a bundle of handles like 'please render vertices from these two vertex buffers, using this shader, and these uniforms+textures' - whether or not you have to allocate texture handles first or can provide the GPU raw texture data is a separate question.

Re: Chrome ships WebGPU

#187

Earlier quoted context omitted.

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

> why highly paid Google ... developers "Completely co-incidentally", it's in Google's best interest to be able to fingerprint everyone. So, changing it to actually be privacy friendly while they have the lion's share of the market doesn't seem like it's going to happen without some major external intervention. :/

It's running on Chrome. Google doesn't need fingerprinting. By making it harder for others to fingerprint it actually cements Google position in the ad market.

Re: Chrome ships WebGPU

#188
post #30

Earlier quoted context omitted.

There is no way to escape fingerprinting. Just one example: A script which runs many different types of computations. Each computation will take a certain amount of time depending on your hardware and software. So you will get a fingerprint like this: computation 1: ** computation 2: **** computation 3: ********** computation 4: ** computation 5: ************** computation 6: ************ computation 7: ********* etc…

Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.

Saturating the user with permissions requests for every single website they visit is a dead-end idea. We have decades of browser development and UI design history to show that if you saturate the user with nag prompts that don't mean anything to them, they will just mechanically click yes or no (whichever option makes the website work).

Re: Chrome ships WebGPU

#190
post #172

Earlier quoted context omitted.

For a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue. In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the p…

> In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Counterpoint: if webpage with latest news (for example) immediately asks me to allow notification, access to webcamera and location I definitely know what is correct answer to these dialogs.

"Do you want to allow example.com to send you notifications" is way more understandable to a layperson than "do you want to allow access to WebGPU" or "do you want to allow access to your graphics card". Especially because they would still have access to canvas and WebGL.

Permission prompts are a HUGE user education issue and also a fatigue issue. Rendering is widely used on websites so if users get the prompt constantly they're going to tune it out.

Post reply on HN