[tw061023]

WebGPU is supposed to be properly sandboxed.

The bigger issue is that WebGPU is basically dead on arrival for the same reasons WebGL is - it is impossible to get enough data to the client for it to actually matter, Awwwards-style design tricks notwithstanding.

I suppose browser vendors understand this and don't really care for either.

[_factor]

“WebGPU is supposed to be properly sandboxed.“

GPU must therefore provide open API for proprietary processing space.

Magic “packets” are therefore possible to execute arbitrary functions on “sandboxed” DMA devices.

Still a problem until we can audit the hardware. NV, and to a lesser extent AMD and ARC play somewhat open with a few omnipotent cards in their pockets. The prime of the issue is that gamers don’t care, only security professionals do. Because they’re the ones who see the 0-days fly by every day.

[nmfisher]

What do you think could fix this? Access to genuinely permanent storage?

[tw061023]

That's one part of it, yes. A browser API providing a few GBs of persistent storage with proper isolation and user management, obviously with some kind of compression/decompression going on to save both download times and loading times.

As an example, consider Infinity Blade, the poster child of mobile gaming: released in 2010, 595 MB download, 948 MB installed. Even the first version of WebGL is capable of providing this kind of experience, we just cannot get it to the user via browser.

[pjmlp]

I found out another fellow soul, that is exactly one of my complaints with Web 3D, the failure to 15 years later to provide the same experience as Infinity Blade, used by Apple to show off iPhone's OpenGL ES 3.0 capabilities.

Or Unreal Engine Citadel demo, originally done in Flash / C++.

[ossobuco]

That may be true (for now) for web apps, but what if you serve your app/game as a desktop app, for example with tauri?