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?

▲

varenc 23 minutes ago | parent | next [-]

> notice they have a dom.webgpu.blocked-domains with the sole entries being "easyeda.com,*.easyeda.com", I wonder what that's about?

I found this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1980392 and commit: https://phabricator.services.mozilla.com/D262053

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.

▲

userbinator 23 minutes ago | parent | prev | next [-]

WebGPU/WebGL is another thing that only trusted sites should be allowed to use, just like JS in general.

▲

StilesCrisis 2 hours ago | parent | prev | next [-]

With Chromebooks, Chrome is in fact put in the position of being a real operating system and is the only surface exposing the hardware's capabilities!

▲

autoexec 2 hours ago | parent | prev | next [-]

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.

▲

mh- 2 hours ago | parent [-]

On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.

▲

xoa an hour ago | parent | next [-]

>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.

▲

autoexec 2 hours ago | parent | prev | next [-]

True, but randomizing other data points will keep your fingerprint unique which should help prevent associating your activity across sites/sessions.

▲

seany 2 hours ago | parent | prev [-]

don't some of the adblock extensions randomly modify the fingerprinting you can get from this?

	▲	autoexec an hour ago \| parent [-]
		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.

▲

stackghost 2 hours ago | parent | prev [-]

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.

▲

lmz an hour ago | parent [-]

The BigCos are the reason you have that browser in the first place. If you don't like it, you know where to download ... links or something.

▲

stackghost an hour ago | parent [-]

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.

	▲	lmz an hour ago \| parent [-]
		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.