Live data from Hacker News

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

auberon.xyz

31–40 of 198 posts

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

#31

while (true) console.log('this will freeze/crash dev tools') For more of a "I've been hacked!" effect, load infinite 3D models in Three.js that have millions of vertices each. You get those black boxes where the system has so low RAM it can't even draw the browser window.

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.

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

#32

Earlier quoted context omitted.

For me it just caused Safari to stop working until I quit and restarted it.

On my M1 MacBook Air with MacOS 12 it hangs. The mouse pointer still moves, but I can't bring up the force quit dialogue, and couldn't get anything else to work either. A youtube video in another tab kept playing until I held the power button to force a shutdown.

I'm using macOS 27.0 RC on M4 Max

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

#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 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?

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

#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?

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

#35
Metal is based on C++14, which means you can write Duff's Device in a shader. I've tried it on various Macs and it causes all sorts of critical failures in the compiler, but never an actual kernel panic. (It's pretty trivial to reproduce in KodeLife)

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

#36

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

Often not in the same way - even if there are multiple queues (that can be given a priority), they're often limited in what they can schedule between.

Often there's shared resources that are statically allocated to shaders (register space, local memory etc.) that means you often can't "just" add a new task if those shared resources are already in use. But not using those resources to their full would cause performance issues.

And the internal state of a GPU is often very large, much larger than a CPU, so suspending the current tasks, saving out their state and replace it with a "higher priotity" one can be very expensive - so often an afterthought of support at best.

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

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

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!

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

#38

I want to click it so bad, but I can't bring myself to do it.

After a long day at work I saw the page, saw the warning to not click it, and I proceeded to click it lol.

Locked up my entire M1 Macbook Pro, held power button and I was back into chrome in <20s but I did kinda go "why did I just do that?"

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

#39

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

[deleted]

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

#40

while (true) console.log('this will freeze/crash dev tools') For more of a "I've been hacked!" effect, load infinite 3D models in Three.js that have millions of vertices each. You get those black boxes where the system has so low RAM it can't even draw the browser window.

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
Post reply on HN