Live data from Hacker News

The Deathray: A simple way for an untrusted site to freeze a Mac

auberon.xyz

51–60 of 198 posts

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#52
post #50
post #44

Earlier quoted context omitted.

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

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

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.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#53
post #44

Earlier quoted context omitted.

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.

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

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#54

Earlier quoted context omitted.

This doesn't even always work unless you log two different messages, because some DevTools will just keep a running count of how many of the same message there has been in a row.

fwiw it froze my tab in seconds just pasting that into dev tools

I think running it in the DevTools console is different from having a script on the page.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#55
post #33

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…

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…

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.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#56
post #55

Earlier quoted context omitted.

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…

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.

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.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#58
post #55

Earlier quoted context omitted.

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.

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.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#59
post #33

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…

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

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#60
post #33

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…

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

Post reply on HN