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

reply
incredibly, the underlying issue seems to be lack of support for shadowing built-ins and reserved keywords

which seems like an insane thing to need or support. literally just pick a different name, there are infinitely many!

i can understand just deciding to ignore the site

reply
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.
reply
On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
reply
>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.

reply
True, but randomizing other data points will keep your fingerprint unique which should help prevent associating your activity across sites/sessions.
reply
don't some of the adblock extensions randomly modify the fingerprinting you can get from this?
reply
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.
reply
WebGPU provides ZERO extra data that wasn't already available from WebGL in 2011. The world didn't end and it's been 15 years
reply
> The world didn't end and it's been 15 years

Maybe it did and you're just hooked up to the Matrix thinking it didn't

reply
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!
reply
WebGPU/WebGL is another thing that only trusted sites should be allowed to use, just like JS in general.
reply
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.

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

reply
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.
reply
deleted
reply
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.
reply
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.
reply
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?

reply