61–70 of 80 posts
Would this enable bitcoin mining using gpu in a browser?
Would likely just make it faster as you wouldn't have to read the results out of a canvas, although I haven't checked what the pure data API for WebGPU looks like.
After a bit more searching: https://bitcointalk.org/index.php?topic=27056.0
but no, we get experiment addons installed, canvas fingerprinting even though i have less use for canvas then i did for flash, etc, ect.
trying to play catch up with google crapping features on chrome is one thing, but also copying their irresponsability on hidding/not giving control to the end user is not what an open source company should do.
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…
Earlier quoted context omitted.
Running firefox 4 (or any other comparably old browser), this would be the least of your security problems, it's not even RCE. The stream of discovered vulnerabilities is constant.
What's your point? Do you really think I was suggesting that people are still running Firefox 4? When WebGL was first implemented in Firefox - long ago - it shipped with serious security flaws. This struck many people as sadly predictable, as graphics APIs like OpenGL are not intended to be accessible from untrusted code. WebGPU seems awfully similar to WebGL in this respect: it's trying to wrap a low-level graphics…
But yes I am guilty of some whataboutism here, WebGL did have some unique problems and WebGPU devs hopefully learn from them.
I have 2 projects using Three.js and pure WebGL: https://bad.city (multiplayer browser game engine + editor) and http://fonted.io (shader toy + fonts)
Earlier 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…
Could just have an interface to request access for use, such as with camera and sound/microphone.
Earlier quoted context omitted.
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 ou…
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.
Some Linux setups run Xorg, others run Wayland (with the world moving towards the latter). Yet, many times these new features (especially things related to rendering!) only work on older Xorg setups, but not on Wayland.
For anyone Linux users out there: these updates only work if you're still running Xorg.
Earlier quoted context omitted.
> 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 ou…
> 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…
What could an attacker do if they were able to trick the JIT into emitting evil native code?
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…