Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

auberon.xyz

Post reply on HN
Print view View original

141–150 of 198 posts

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

#141

Post by gregoriol »

socalgal2 wrote: post #86

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…

> All that happens is the perp loses any audience

You haven't heard about rickrolling, have you?

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

#142

Post by zipy124 »

socalgal2 wrote: post #86

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…

You can lose data though. Any open documents which aren't saved...

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

#143

Post by snek_case »

zelphirkalt wrote: post #92
socalgal2 wrote: post #86

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.

Ad impressions typically cost money, so there's a case to be made that this is sort of self-correcting too.

That being said, IMO no website should be able to freeze your machine. This is a bug. Steps should be taken to fix it.

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

#144

Post by lambdaone »

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 loop. With the resources available to Apple, they really have no excuse.

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

#145

Post by asimovDev »

abecedarius wrote: post #63
LoganDark wrote: post #15

Apple Silicon Macs have a lot of GPU problems. I find that after running any significant GPU workload, the entire operating system starts getting super slow until a reboot. Even if the entire process tree that ever touched the GPU has been completely terminated for days.

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?

only time i had slowdowns running LLMs on my M3 Max was when i was hitting the context limit so the memory pressure was hitting high yellow / red.

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

#146

Post by fingerlocks »

auberonedu wrote: post #77
mitxela wrote: post #71

Is there a reason you need the fake for loop and the vertex shader? Can a single infinitely looping shader not do the same thing? And what happens in WebGL?

In my testing, a looping compute shader was enough to crash the tab on its own, but it needed waiting render shaders to crash the WindowServer. Interestingly though there was another way to make only the tab crash, even if I had all three shaders in the pipeline: If I placed the canvas far offscreen using position: absolute, only the tab would crash even if the render shaders were waiting! There's some weird interact…

Render shader output is no-op for offscreen viewport buffers because the view delegates redraw to the render pipeline. A render shader writing to disk has the same effect

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

#147

Post by kllrnohj »

lambdaone wrote: post #144

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…

Well this is easy to detect and kind of intentionally so, but the broader issue is quite a bit harder. Replace "infinite loop" with some very difficult program that simply takes 30+ seconds to finish and you're back to the same problem.

It doesn't even need to be computationally difficult, you can also slam the memory bus with "far away" fetches that are randomly distributed, ensuring each fetch doesn't share a cache line with any surrounding fetches. There are popular UX effects with basically this workload, even, that's a naive implementation of a large radius gaussian blur basically...

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

#148

Post by pessimizer »

concinds wrote: post #115
isolay wrote: post #110

> Just hope that your browser doesn't automatically reopen the same tab when it starts up again Busted. My browser is configured to do just that.

Chrome asks whether to reopen windows if it didn't exit normally. Safari appears to just YOLO it. Don't know about Firefox.

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?

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

#150

Post by kllrnohj »

krackers wrote: post #34

>This spills over into other processes wanting to use the GPU, namely the WindowServer. Why does this spill over? Unlike CPU which is multiplexed by the kernel's scheduler (so infinite loops can't lock out other programs), is the GPU not multiplexed in the same fashion?

Not many GPUs support full pre-emption. And by "not many" I mean like Nvidia desktop GPUs only added this shockingly recently ( specifically with Pascal generation: https://docs.nvidia.com/cuda/pascal-tuning-guide/index.html#... )

Otherwise GPUs typically do context "pre-emption" by basically being cooperative and just injecting yield statements in the command queue or on things like tile boundaries for tile based renderers. So the smallest chunk of work they can yield between ends up actually being quite large, and with a full user-supplied program in the middle

Post reply on HN