Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Taste of WebGPU in Firefox

hacks.mozilla.org

Post reply on HN
Print view View original

51–60 of 80 posts

Re: A Taste of WebGPU in Firefox

#51

Post by notyourday »

MaxBarraclough wrote: post #36
notyourday wrote: post #35

Earlier quoted context omitted.

> It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. That was my mistake - i was not clear. I'm talking about virtualized GPUs that can be passed to a VM running a minimum system needed to boot a browser.

Ok, so you're suggesting always running the browser in a VM, and using the GPU from within the VM (via the host OS of course). I believe significant work has been done on the browser/graphics sandboxing problem. Whether browsers use techniques comparable to virtualisation, I don't know. I'm afraid I don't know much about how that's done, or how effectively virtualisation is able to contain the operations of VMs, or h…

The reason why I want to see a virtualized web browser is because it is becoming an insanely complex piece of software with an insanely large attack surface.

I do not want my browser to be able to talk to Bluetooth devices that are connected to my desktop. I do not want want my browser to be able to access random files on my file system simply because it is accessible to me. I do not want a web browser have ability to have GPU access outside the specific virtualized section of it that can only access the part of the screen and off-screen buffers associated with the window of a browser.

I started localizing different web browsers into dedicated VMs that have just a minimal operating system and a web browser. It works well enough for my use case ( i can playback youtube video almost like I could do it on my 2015 laptop ) but it is definitely hacky.

Re: A Taste of WebGPU in Firefox

#52

Post by thewebcount »

I love how much this is like Metal! I've been really getting into Metal lately and I find it so much easier to use than I did OpenGL.

The one glaring exception is binding. It's the thing I hate most about OpenGL. I don't really have to think about it in Metal at all. The fragment shader just takes a texture or buffer as a function argument and I can use it just like I'd use any other C++ object or struct in the shader. From the calling side, I just say, here's the texture that goes with that argument (by name in the code, not by some random ID assigned at runtime). No figuring out which texture unit to use, or which texture target. No cases of accidentally forgetting to enable a texture unit or bind a texture to it, or using the wrong texture target. All of that fiddling around makes OpenGL such a pain in the ass to use. But it seems like WebGPU kept some of that nastiness. Why?

Re: A Taste of WebGPU in Firefox

#53

Post by MaxBarraclough »

notyourday wrote: post #51
MaxBarraclough wrote: post #36

Earlier quoted context omitted.

Ok, so you're suggesting always running the browser in a VM, and using the GPU from within the VM (via the host OS of course). I believe significant work has been done on the browser/graphics sandboxing problem. Whether browsers use techniques comparable to virtualisation, I don't know. I'm afraid I don't know much about how that's done, or how effectively virtualisation is able to contain the operations of VMs, or h…

The reason why I want to see a virtualized web browser is because it is becoming an insanely complex piece of software with an insanely large attack surface. I do not want my browser to be able to talk to Bluetooth devices that are connected to my desktop. I do not want want my browser to be able to access random files on my file system simply because it is accessible to me. I do not want a web browser have ability t…

> The reason why I want to see a virtualized web browser is because it is becoming an insanely complex piece of software with an insanely large attack surface.

This is true, and it's the reason Chromium goes to great lengths to sandbox itself to contain the damage regarding JavaScript engine exploits. Annoyingly Firefox is lagging behind in that regard.

> I do not want a web browser have ability to have GPU access outside the specific virtualized section of it that can only access the part of the screen and off-screen buffers associated with the window of a browser.

Virtualisation will improve your general security, but it's isn't a perfect abstraction especially when it comes to GPUs, and it's not a rock-solid guarantee of the isolation assurances you want. [0] I believe cloud-computing providers never split a GPU between customers, for instance. Disabling sharing of the GPU with the VM would further improve your security at the price of performance.

[0] https://www.hpcwire.com/2018/05/31/gpus-excellent-performanc...

Re: A Taste of WebGPU in Firefox

#54

Post by EastSmith »

ape4 wrote: post #5
MaxBarraclough wrote: post #2

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-... Edit I should have given a quote from one of the articles covering the issue, so here's one: > anyone running Firefox 4 with WebGL support is vulnerable to h…

Fingerprinting is one security concern.

Crypto mining is another

Re: A Taste of WebGPU in Firefox

#55

Post by kvark »

thewebcount wrote: post #52

I love how much this is like Metal! I've been really getting into Metal lately and I find it so much easier to use than I did OpenGL. The one glaring exception is binding. It's the thing I hate most about OpenGL. I don't really have to think about it in Metal at all. The fragment shader just takes a texture or buffer as a function argument and I can use it just like I'd use any other C++ object or struct in the shade…

The binding model of WebGPU is nothing like OpenGL. I don't know where you get that idea, especially considering a dedicated section in the article describing this.

Metal binding model works well because each buffer can contain references to other resources (`MTLArgumentBuffer`). So you can change whole packs of resources at once with this. But argument buffers are not implementable on other APIs. We chose Vulkan's descriptor set-like model as the least common denominator.

Re: A Taste of WebGPU in Firefox

#56

Post by tracker1 »

MaxBarraclough wrote: post #23
notyourday wrote: post #21

Earlier quoted context omitted.

Browsers should be run in a VM, via a fake GPU which is mapped to a window ( possibly root window ) of a main desktop. Giving code fetched from the internet in real time full access to hardware, especially complex hardware, is lunacy. I'm shocked that neither Google nor Mozilla still have internalized this lesson.

The browser should simply disable WebGPU by default. It's already intended to be sandboxed, but given what happened with WebGL, I'm not convinced we can trust it. There's nothing to gain by faking a GPU. Edit For clarity, I'm saying you may as well just disable WebGPU. A CPU-based simulated GPU would indeed improve security, but its performance would be so atrocious that there would be no point having it compared to…

Could just have an interface to request access for use, such as with camera and sound/microphone.

Re: A Taste of WebGPU in Firefox

#57

Post by tracker1 »

hutzlibu wrote: post #46
m_eiman wrote: post #13

Earlier quoted context omitted.

I’d like Javascript to be opt-in. Turning it on by default was a mistake.

You are free to disable it as a very small minority. The web is not a static document viewing anymore. Now I agree, that sites should have a static fallback, as I also do not want to run a full webapp, when all I want is a static article for example. But this is because of a different problem - the financing of most of the web, through advertisment and not the fault of javascript.

Much like frames, iframes and window.open are really useful features... advertisers and abusers made it bad. I remember the first time I saw a popup in the 90's, my first thought was, "oh this is going to get bad." And I would never buy a product from X10.

Re: A Taste of WebGPU in Firefox

#59

Post by moron4hire »

MaxBarraclough wrote: post #2

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-... Edit I should have given a quote from one of the articles covering the issue, so here's one: > anyone running Firefox 4 with WebGL support is vulnerable to h…

This is really old information

Re: A Taste of WebGPU in Firefox

#60

Post by indolering »

JulienSchmidt wrote: post #22
kvark wrote: post #3

Earlier quoted context omitted.

It's up to the browser to decide if it's enabled by default at some point in the future. There is nothing in a Web API saying that it has to be forcefully enabled. I do share the concern that security of talking to the GPUs is hard. We'll do our best. I think it's important for the Web platform to reach this capability. Interestingly, the implementations are more diverse, because there isn't a single Angle-like libra…

I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life. WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.

What you really want is a security first web browser, not something that must prioritize feature completeness to achieve commercial success. I would love a spin-off of the Tor browser sans Tor.
Post reply on HN