Live data from Hacker News

Chrome ships WebGPU

developer.chrome.com

71–80 of 405 posts

Re: Chrome ships WebGPU

#71
post #30

Earlier quoted context omitted.

And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?

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…

You only get fingerprinting from your method if the variation of the “fingerprint“ between two different runs by the same user is lower than the difference you get between two different users. This is far from obvious since it depends a lot on the workload running on the machine at the time.

I'm not aware of a single fingerprinting tool that primarily use this king of timing attack rather than more traditional fingerprinting methods.

Re: Chrome ships WebGPU

#72
post #15

I lost all hope for WebGPU after they decided to roll their own ad-hoc shader language that kinda looks like, but is totally not rust. At least with WebGL you had C. Without SPIR-V support this spec is just another tire on the fire that is the modern web.

"ad-hoc shader language that kinda looks like, but is totally not rust." But is that language actually bad, or is it just not your favourite language? What don't you like about it?

Because it is too different from other C-like DSLs GLSL, HLSL. GLSL was doing its job perfectly and there was no reason to invent another one. With wgpu, I now need to spend time on searching through its reference pages for things that I already know how to do in shaders. Now all countless WebGL tutorials need to be migrated to completely new syntax. This could be much easier by just making a superset of GLSL. And I had't got any sane answer on "why it should look like Rust?"

Re: Chrome ships WebGPU

#73
post #60

Earlier quoted context omitted.

> I don't see how any of the vendors could break it without being extremely overt about it. > except WebGL, which is abandoned. So it can be abandoned

It becoming a stale standard is maybe the biggest threat, yes. It has the issue all standards have since several actors have to play along, except this time it isn't Nvidia, Apple, and AMD, but Wgpu/Mozilla and Google. Their incentives are hopefully better aligned with users than those of the hardware vendors. I suspect WebGL was different, since it was based on the old OpenGL/DX9 way of doing things, so a clean brea…

WebGL was based on OpenGL ES 2.0 and a subset of OpenGL ES 3.0.

Google refused to support WebGL compute based on OpenGL ES 3.0 compute shaders, citing WebGPU alternative, and there are still quite a few capabilites from OpenGL ES 3.2 missing from WebGL.

Some of which still not available in WebGPU 1.0.

Re: Chrome ships WebGPU

#74
post #62
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…

It's possible to have the runtime execute the computations in fixed time across platforms.

Sure. And nobody actually wants that, because it would be so restrictive in practice that you might as well just limit yourself to plain text.

The horse bolted long ago; there's little sense in trying to prevent future web platform features from enabling fingerprinting, because the existing surface that enables it is way too big to do anything meaningful about it.

Here are a couple of more constructive things to do:

- Campaign to make fingerprinting illegal in as many jurisdictions as possible. This addresses the big "legitimate" companies.

- Use some combination of allow-listing, deny-listing, and "grey-listing" to lock down what untrusted websites can do with your browser. I'm sure I've seen extensions and Pi-hole type products for this. You could even stop your browser from sending anything to untrusted sites except simple GET requests to pages that show up on Google. (I.e. make it harder for them to smuggle information back to the server.)

- Support projects like the Internet Archive that enable viewing large parts of the web without ever making a request to the original server.

Re: Chrome ships WebGPU

#75
post #32

Chrome _will_ ship WebGPU in the next update... Current is 112, WebGPU is 113. Seriously google, can't you just wait until you actually ship the stuff before you say you shipped it...

Even worse: "This initial release of WebGPU is available on ChromeOS, macOS, and Windows. Support for other platforms is coming later this year." I guess Linux support will come right after they ship Google Drive client.

Not even Google cares about "The Year of Desktop Linux", despite their heavy use of it.

Re: Chrome ships WebGPU

#76

Soon, there will be no need to install softwares to the computer. A modern browser will cover it all. What scares me is browsers getting bloated with all kinds of features while webapps getting bigger and bigger in size for no reason. Note, I am all for this feature getting widely adopted.

Adding broadly useful features to the web platform is a net gain if it removes bloat from N web apps that most users run.

It might take multiple years for something like WebGPU to start paying off, and even longer for the deprecation of older APIs for 3D rendering, video compression and compute.

Re: Chrome ships WebGPU

#77
post #15

I lost all hope for WebGPU after they decided to roll their own ad-hoc shader language that kinda looks like, but is totally not rust. At least with WebGL you had C. Without SPIR-V support this spec is just another tire on the fire that is the modern web.

"ad-hoc shader language that kinda looks like, but is totally not rust." But is that language actually bad, or is it just not your favourite language? What don't you like about it?

The language is called WGSL. It's not ad-hoc (I mean, all DSLs are to some extent?) and it has a pretty easy learning curve if you know GLSL. I don't get what the fuzz is about.

Re: Chrome ships WebGPU

#78

Soon, there will be no need to install softwares to the computer. A modern browser will cover it all. What scares me is browsers getting bloated with all kinds of features while webapps getting bigger and bigger in size for no reason. Note, I am all for this feature getting widely adopted.

For the general population, is this a bad thing? - less friction for users

- less hassle dealing with installer bloat

- ability to just “close” a webpage instead of having to remove many files in obscure locations if you want to uninstall something

- easier syncing of state across multiple devices with browser session sync

- granular permissions per “app” such as file access, camera access, etc. - lower barrier to enter for developers wanting to ship cross-platform software without having to bundle electron / tauri / whatever

Not to say there aren’t downsides.

- no longer “owning” your software (although debatable if this were ever the case)

- potentially being tied into vendor-specific browser implementations

Re: Chrome ships WebGPU

#80

In case you confused this with webgl as I did: > WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computation operations on a GPU, similar to Direct3D 12, Metal, and Vulkan. Unlike the WebGL family of APIs, WebGPU offers access to more advanced GPU features and provides first-class support for general computations on the GPU.

And to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?

As long you can keep it off or turn it off then I think this is a good option to have. I too would prefer to have the Web split into 2 parts, documents and apps , then I could have a browser that optimizes for JS , GPU speed and a simple safe browser for reading Wikipedia and articles.

I am sure there will be browsers that will not support this or keep it off so at worst you need to give up on Chrome and use a privacy friendly browser.

Post reply on HN