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.
A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations.
If we aren't confident in the security of the WebGPU implementation (and we're agreed that we aren't), the solution is simply to disable support for WebGPU in the browser. The browser can still offer facilities like the Canvas API.
> 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 how high the performance penalty is.
Going with guesswork though, it seems to me virtualisation doesn't offer particularly solid guarantees here. If the host OS has a buggy graphics driver, it would presumably be possible for it to leak data back to the VM. Any facilities the GPU can offer to help contain semi-trusted graphics contexts, should presumably be available for use directly by the browsers, without running a guest OS in virtualisation.
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.
> 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.
> Annoyingly Firefox is lagging behind in that regard.
This has not been true since quite a while. Firefox has employed sandboxing even before the multi-process work (which culminated in the Quantum branches of Fx releases that added more and more sandboxing with each release). Before that, Moz went a different way than OS level sandboxing by principal containerization (I forgot the correct term, sorry), which worked in terms of separation of execution contexts (of Web JS and other parts like the styling system, plus the browser internals). Elements of that implementation have been removed by now (iirc) since the multi-process split required different communication paths anyway (which also enabled per-origin/-tab/-window OS-Level sandboxing), so that code was no longer needed.
I would say there is no simple answer to your question. However, I am not able to give you an authoritative answer to your question anyway. If you are interested, you can start here[1] or try and ping the moz-security people
A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations.
If we aren't confident in the security of the WebGPU implementation (and we're agreed that we aren't), the solution is simply to disable support for WebGPU in the browser. The browser can still offer facilities like the Canvas API.