While I'm sure it has its uses, particularly if someone really does want to game or do complex computational stuff purely within a web browser, I'll admit I've grown pretty cautious/tired around the ever increasing amount of hardware attack surface area the browser vendors seem to be rushing to expose as Google in particular appears determined to try to be the "operating system on the operating system" as much as it can. In this particular case it made me realize I'd awhile ago set dom.webgpu.enabled and pdfjs.enableWebGPU to false in Firefox, same as I disabled WebGL. Kinda figured if I ever saw something ultra cool I could enable it just that one time but so far I haven't. Semi-related, reviewing the available settings now for the first time in a bit I notice they have a dom.webgpu.blocked-domains with the sole entries being "easyeda.com,*.easyeda.com", I wonder what that's about?
It looks like per-domain WebGPU blocking was added exclusively just for easyeda.com !
Haven't read it all, but the story seems to be that EasyEDA's WebGPU usage was broken because it relies on some aspects which Firefox hasn't implemented yet. So they made this blocklist to get Firefox to behave as if it lacked WebGPU support completely on this domain, which makes EasyEDA fallback to some other non-broken version. Maybe they couldn't get in touch with EasyEDA directly, since it seems far easier to have them just disable WebGPU for some known versions of Firefox.
I'm with you. WebGPU has been used to compromise and fingerprint systems. Firefox (and related forks) are usually able to disable this kind of insecure fluff but it'd be nice if other browsers did as well.
>On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
I think near any anti-fingerprinting efforts though presume some floor level of system security and stability. If some particular hardware exposure feature lets attackers run arbitrary low level timing and hardware testing code or crash the system or break the sandbox the game is likely over for most people.
An extra bit of entropy isn't meaningless sure, but at some point there should be some weighing of absolute attack surface against it right? Some features just seem inherently anti-privacy/anti-security and one might just have to try to deal with that via other approaches.
Hopefully, but it's good to have it disabled as well so that your system isn't screwed by the next zero day and to help cover you in case the fingerprinters manage to find a technique to get identifying data from WebGPU that your ad-blocker hasn't accounted for. It's a constant arms race after all. Hopefully the ad-blocker is still feeding them randomized data even with it disabled, but otherwise other randomized data points should keep your fingerprint unique even if a lack of WebGPU support stays consistent.
WebGL is also a major security risk that has been used to compromise many machines. The world didn't end, but many people have been hurt because of it. I disabled WebGL the moment support was added in firefox too.
Quite so. When it first took off, I took no end of flames and downvotes for suggesting that WebGPU is a terrible idea. HTML and the browser were originally conceived to render documents, not serve as a bastardized application distribution platform.
The only arguments I've ever heard in favor of wasm/webgpu were that using native graphics/GUI toolkit APIs are a pain. That's definitely true, because I've written stuff with gtk and it sucks, but that doesn't mean we should just shovel an entire tech stack into the browser.
Just because we can, doesn't mean we should. I'm tired of these BigCos shitting everything up.
So, I kind of agree, but I don't know what a better solution looks like.
Is it really better for users to download and run straight up executables with no security model? We tried that in the 90s and 2000s and it was pretty bad. We can have OSes introduce a security model, like Android and iOS do. But then what about desktop Linux users like myself? Am I just to be excluded because I don't use a popular (and proprietary) operating system?
Okay, we can invent a standard, cross platform app distribution mechanism with a security model. And that's... exactly what web browsers are. In the end it seems like the least-bad solution to me. I quite like that I can run GPU accelerated programs without the dev having to put in special effort to support my Linux distro.
>Is it really better for users to download and run straight up executables with no security model?
Yes. Unambiguously, a system where the only code that runs is code that you explicitly run is more secure. Social engineering and basic tricks of telling someone an app does A while it really does B are not solved on the web, because social engineering cannot be solved. In the supposed safe gardens of app stores, apps do exactly that all the time and are not well moderated. Apple's supposed moderation approved a "Lastpass" password manager app that was not made by the actual Lastpass company. If that can get through, then anything can get through.
Meanwhile, the webapp solution is for any site you visit to be able to download and execute whatever they want, rather than whatever you want, and most sites also set a third party to have the ability to download and run whatever they want, and Google wants that system to have as much control over your local hardware as the OS does, so how is this better at all? It's strictly worse. The web security model is worthless. It depends on random third parties you have no affiliation with to not get hacked themselves, and not make stupid choices.
It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.
What is the "Security Model" of the web, that every random person willing to pay a few cents for an advertisement should be able to run code on your machine without your authorization? That anyone should be able to target individuals for RCE through advertising infrastructure?
> Unambiguously, a system where the only code that runs is code that you explicitly run is more secure.
I don't think so? If I want to run a 3D modeling program and I download their executable and run it, it has access to everything on my system. All my local files, open access to my network connection, whatever's going on with my internal network, etc. If they want to read all my files and upload them, they can just do that. This is not true for web applications.
Programs that run in a browser are sandboxed and only have access to what web standards say they have access to. They can open a file select dialog to get a file from my machine with my permission, but they don't just have access to all of my files like a local program does. Web standards developers put a lot of effort into finding a balance between security and capabilities for new web APIs.
> What is the "Security Model" of the web
Unlike locally running programs, web applications don't have access to everything on the system by default. Interactions with the local system are intermediated by the browser. Usually the user has to approve access, or there are limitations on what types of access a web app can have.
If you head into your Firefox settings and select "Permissions and data", you can see what kinds of things given websites are allowed to access. Usually when they first try to use one of those APIs, the browser will pop up some kind of browser-level dialog asking the user for permission to perform that type of action (eg "access local devices" or "show notifications"). These are all examples of the web app security model (and there's a whole lot more that is not as user-facing).
Local applications on the other hand, do not have any kind of security model. The 3D modeling program I downloaded can just package up all of my files and upload them to their server, completely silently. That's way worse than what web applications can do!
> It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.
People don't want documents. Almost everything useful you do on the web is some form of interactive app from a simple forum with no JS to Figma or 3D games.
I think we need to go the other way, all in on apps. The browser only has to expose permission based I/O, WebGPU and a way to build a11y semantic trees. Globally cached libraries can handle everything else. That would reduce the attack surface and core complexity while making the platform more flexible. HTML can run as a legacy layer on top.
Yeah in the end I probably agree on WebGPU, I haven't really seen a single use of it, except for running shader code examples in browser, which might as well be replaced by a looping video.
For WASM though, I do not agree at all! It's genuinely a great system for high performance browser code. So much stuff I use now had WASM as the backbone, and I even started applying it outside of the browser in some of my architecture. I wish we had way more enthusiasm behind things like WASM, and way less for something like WebUSB.
Hey you’re right, we should gladly accept every decision the big corps make. They know best, after all. We should probably lick their boots too, in gratitude for their benevolence.
The application delivery thing was done as far back as Netscape threatening to relegate Windows to "a poorly debugged set of device drivers" so Web-whatever is simply another step in that direction. Like I said, if you purists want just document delivery, you can use links or w3m or maybe Gemini.
Some kind of market forces kept Netscape in check back then. Now they aren't.
Like, Tesco would prefer that my operating system was a roast chicken, Baowu Group would prefer it was made of steel, Berghain would prefer that it had to queue for hours to possibly get in, and Jagex would prefer it was an in-game GUI within RuneScape. None of those companies got their way, what makes Netscape special?
The point is that browsers have been made and funded by BigCo, and treated as app delivery platforms at least for the last 20 years. Netscape, Microsoft, Apple, Google (for Mozilla and then Chrome). The last non BigCo mainstream(?) browser was probably Opera.
It's silly to complain now about BigCo, WebGPU, and ignore the past 20 years of history. The WWW has not been about document delivery only for the last 20 years. Instead of tiring themselves out complaining about the Web and modern browsers, they can use something else.
