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.
The Deathray: A simple way for an untrusted site to freeze a Mac
31–40 of 198 posts
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#32Earlier 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.
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#33Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#34Why 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
#35Re: 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 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
#37While 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…
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#38I want to click it so bad, but I can't bring myself to do it.
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?
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#40while (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.