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…
A Taste of WebGPU in Firefox
21–30 of 80 posts
Re: A Taste of WebGPU in Firefox
#22Will 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…
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…
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.
Re: A Taste of WebGPU in Firefox
#23Will 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…
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.
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 the existing drawing APIs.
Re: A Taste of WebGPU in Firefox
#24Will 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…
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.
Re: A Taste of WebGPU in Firefox
#25Earlier 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…
Re: A Taste of WebGPU in Firefox
#26Earlier 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…
Moving applications that can do anything into sandboxed pages in a browser that can't do arbitrary things to the user's system is a win. The more capable the browser is, the more things that once would have been downloaded applications can become safely sandboxed pages.
Re: A Taste of WebGPU in Firefox
#27Re: A Taste of WebGPU in Firefox
#28Earlier 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.
Re: A Taste of WebGPU in Firefox
#29Earlier quoted context omitted.
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…
There is - it is a GPU with all the bells and whistles but even if the browser's security context is broken, the browser cannot access anything on a real desktop.
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.