Live data from Hacker News

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

auberon.xyz

161–170 of 198 posts

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

#161

Not 100% surprised that this wasn't picked up as a security issue; denial-of-service is bad, but ultimately doesn't give you a direct path to stealing secrets / hijacking identity / etc. It is pretty egregious though, I hope they fix this. I expect there'll be a Radar tracking this now that it's made it to the HN front page.

The usual read on cybersecurity determines how bad an issue is using (something akin to) impact on confidentiality, integrity, and availability.

Being able to freeze a computer from the browser is a plain availability risk. It's not exactly a high-priority risk, but still something that should be considered a risk in my opinion.

With operating systems like macOS+Safari reopening a page after reboot, a malware domain can claim to take your computer hostage by te-freezing the PC every time the user moves away from the page until money is paid. People already fall for "we have hacked your computer pay X bitcoin to get it back", this just adds to that.

According to the comments here, this has been a thing for ages, so I kind of doubt that they'll fix it this time. But fingers crossed!

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

#162

Earlier quoted context omitted.

What if you needed all of your other tabs? It enrages me that how the browsers all decided that my state and my history were worthless to me. You know what happens when your business is a browser and you gradually deprecate different functions of a browser, rather than refining and expanding on them?

You're enraged by a popup that asks if you want to restore your tabs, given that it just crashed?

I'd guess GP id enraged that you can't selectively choose, or that there is no option to have the tabs restored without auto-loading, so you can keep your list of open work without being forced to reload a freezing tab.

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

#163

Earlier quoted context omitted.

Sounds like a problem that'd hit anyone running LLMs. I haven't tried on mine so far, but people do talk about ordering a $10k Mac Studio just for that. Anyone else see this? Does the OS version matter?

I don't think I had the issue before macOS 26, but honestly I have no way to tell. I did run into one other HN commenter that suffers from the same slowness problem, but they didn't connect it to workloads, only uptime. I think it was the same issue though.

fwiw I also observed a persisting slowdown soon after upgrading my Studio to OSX 26. Since I haven't been using it very much I'm short on data bearing on the cause -- maybe it was GPU use though I don't recall doing anything like that.

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

#164
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…

It's interesting because we learned this lesson with JVM applets, Flash and X controls in the browser, yet somehow insist on revisiting it...

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

#165

This has been around since 2011 when WebGL shipped. It's documented in the spec. It's a self correcting problem. You go to a site, it freezes your machine, you never visit the site again. No data is stolen, no privacy is lost. All that happens is the perp loses any audience. Turning off WebGL = no more Figma, no more Canva, no more Google Maps. A few self correcting sites seem acceptable. Evidence, it's been 15 years…

Do you think a regular user knows how to block a specific website or never click a link leading to it again? And what about the ads people, adding such a thing if you don't load their ads? I think this point of view is making it a bit too easy.

> And what about the ads people, adding such a thing if you don't load their ads?

Through what mechanism? You don’t load their code, so then they presumably load this malicious code? If they could do that they would have just loaded the ad!

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

#167
post #127

Earlier quoted context omitted.

As someone who supports some bottom of the barrel "regular users".. they aren't monkeys. They have brains that function enough to process "oh, I shouldn't do that again".

Nitpick: monkeys have enough brains for "oh, I shouldn't do that again".

Is that really an important detail? I think what I said got my point across.

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

#169
post #167

Earlier quoted context omitted.

Nitpick: monkeys have enough brains for "oh, I shouldn't do that again".

Is that really an important detail? I think what I said got my point across.

My brain stuck on the inaccurate monkey comparison and caused unnecessary work to get past it and back onto the point you were making.

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

#170

It would seem relatively easy to eliminate this sort of infinite loop by ensuring that all loops are finite, function call depth limited and so on. It isn't a case where you hit the halting problem; the halting problem applies to general programs, not programs deliberately constructed out of parts with finite and calculable limits to runtime - no building the Ackermann function for example, as it contains a recursive…

Amusingly, some of this is technically already happening. The shaders pass through downstream compilers that complain if they see what they determine to be a no-op infinite loop. To prove to the compilers that the loop terminates, most WebGPU implementations inject a u64 counter (technically a vec2) that counts down from u64:MAX and terminates the loop once it reaches 0. But that's such a large amount to count that the WindowServer is long gone. Fun discussion on this PR for wgpu, a Rust implementation of WebGPU: https://github.com/gfx-rs/wgpu/issues/6572
Post reply on HN