The Deathray: A simple way for an untrusted site to freeze a Mac
Posted by auberonedu 1 day ago
Comments
Comment by socalgal2 1 day ago
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 since this was possible and the world didn't end and the whole internet isn't freezing your machine.
Also, this is arguably a MacOS bug. Window and Linux have had GPU monitors that power cycle the GPU if a command takes too long. Windows since before WebGL shipped. Linux a few years after. Macs still don't recover from excessive GPU use.
Comment by jonahx 1 day ago
Since the machine is actually frozen, it enables many plausible social engineering scams ("We have detected a virus that froze your machine. Call this number for help..."), and I bet it has been used that way.
Not to mention possible data loss, interruption of work at a critical time, and so on.
Comment by zelphirkalt 1 day ago
I think this point of view is making it a bit too easy.
Comment by socalgal2 1 day ago
> I think this point of view is making it a bit too easy.
It's been 15 years since this was possible. How many times have you heard of this being an issue? Again, it's self correcting. Site freezes machine, user stops going to site. There's zero incentive to do this and tons of incentive to not do it. Even an ad, your ads would get banned, not good for you, no incentive.
Comment by sersi 1 day ago
Comment by trollbridge 22 hours ago
So to get it to stop doing this on restart, I had to be very quick to force-quit Safari as the machine rebooted. You don't get a chance to tell it "Don't reopen all windows" when you hold the power button down.
Comment by jpc0 19 hours ago
Comment by xingped 1 day ago
Comment by socalgal2 22 minutes ago
Comment by DrewADesign 1 day ago
This is basically an old-man-and-the-starfish situation for me.
> You're making a big assumption that a user will even connect the dots
If they do, it’s because their wildly inaccurate mental model happened to guess the right answer. What most will think is “I was just browsing the internet and my computer froze.” Maybe they’ll connect it with that notification they just got about renewing their antivirus software subscription. Maybe it will confirm their (probably mistaken) impression that their computer has been “acting weird” since something arbitrary and unrelated happened. And similarly, some people with an accurate mental model will mistakenly assume that they deduced the cause because they’re smarter, rather than having a different focus with corresponding lacking mental models in other areas.
Comment by alt227 19 hours ago
Comment by DrewADesign 3 hours ago
Comment by alt227 23 hours ago
What about url shorteners and redirects?
You seem to dismiss the issue based on a very narrow avoidable case.
Comment by eks391 21 hours ago
Sure, there are countless ways it could be abused, and you point out some, but what had actor will want to pursue even one? They gain nothing. And good actors only lose out, in the form of lost credibility and future audience. Therefore it doesn't get abused and a fix isn't needed.
The last 15 years is evidence of the argument.
Comment by alt227 20 hours ago
> but what had actor will want to pursue even one? They gain nothing
Ask that to anyone who has ever rickrolled somebody.
Comment by exlr 21 hours ago
Comment by chrisjj 1 day ago
Not true, given any unknown link or button press can redirect/go to such a site.
Comment by ktm5j 1 day ago
Comment by andyferris 1 day ago
Comment by ktm5j 1 day ago
Comment by CrompyBlompers 23 hours ago
Comment by ktm5j 22 hours ago
Comment by CrompyBlompers 21 hours ago
Comment by phoghed 1 day ago
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!
Comment by zelphirkalt 18 hours ago
Comment by snek_case 1 day ago
That being said, IMO no website should be able to freeze your machine. This is a bug. Steps should be taken to fix it.
Comment by lxgr 1 day ago
What do regular users do about a malicious ad that runs on thousands of different sites?
> Turning off WebGL = no more Figma, no more Canva, no more Google Maps
Which is why you should probably rather turn off the actual vulnerable API, i.e. WebGPU, not WebGL.
Comment by graemep 1 day ago
Comment by pipe2devnull 1 day ago
Comment by jonahx 21 hours ago
For example, an ad provider itself can be hacked by a malicious party, so the "pay money for" part no longer applies.
Or an attack by a state actor or other large entity, where paying for a coordinated disruption of some region or company makes financial or military sense.
Those are just two things that came to my mind, and are likely a fraction of plausible incentives someone might have now or in the future. People are creative and unpredictable. Weird shit happens. Fact is stranger than fiction...
Instead, just ask: should visiting a website ever have the power to freeze your computer without your consent? If you think the answer is no, this is a security bug and it should be fixed.
Comment by pipe2devnull 12 hours ago
Comment by zipy124 1 day ago
Comment by sans_souse 14 hours ago
Comment by gregoriol 1 day ago
You haven't heard about rickrolling, have you?
Comment by washadjeffmad 1 day ago
If it didn't crash your computer, it eventually displayed a single popup that said "Congrats on not using Internet Explorer!". I wish I still had the hate emails.
Comment by Matheus28 1 day ago
Comment by zdc1 1 day ago
Comment by parl_match 1 day ago
Comment by davkan 1 day ago
Comment by QuantumNomad_ 1 day ago
With that one, Ctrl+Alt+Delete, Task Manager, kill iexplore.exe was usually all you needed to do thankfully. No hard power off necessary.
Comment by amatecha 1 day ago
Comment by r3trohack3r 1 day ago
If not, I have fond memories of using yours!
Comment by StilesCrisis 1 day ago
Comment by gucci-on-fleek 1 day ago
Comment by isolay 1 day ago
Busted. My browser is configured to do just that.
Comment by concinds 1 day ago
Comment by tgv 1 day ago
Comment by pessimizer 1 day ago
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?
Comment by concinds 1 day ago
Comment by jonahx 1 day ago
Comment by mrguyorama 18 hours ago
When you switch to one of the other tabs, that's the first time they are actually instantiated and run. So if you had this tab in the background, your machine crashed, and Firefox reopened on boot, it would not crash again.
Often, it will report "We are having trouble restoring your session", seemingly without reason, and that dialog has a very simple system for choosing which windows and tabs to recreate vs which to discard. I think you can change a setting to always use this dialog.
I can't recall if chrome has the same interface.
Comment by amelius 1 day ago
Comment by guidopallemans 1 day ago
Comment by trollbridge 22 hours ago
Comment by lxgr 1 day ago
Comment by 1over137 1 day ago
Comment by tetrahedon 1 day ago
Comment by socalgal2 1 day ago
Comment by xoa 1 day ago
Comment by varenc 1 day ago
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.
Comment by ruined 1 day ago
which seems like an insane thing to need or support. literally just pick a different name, there are infinitely many!
i can understand just deciding to ignore the site
Comment by autoexec 1 day ago
Comment by mh- 1 day ago
Comment by xoa 1 day ago
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.
Comment by autoexec 1 day ago
Comment by seany 1 day ago
Comment by autoexec 1 day ago
Comment by socalgal2 1 day ago
Comment by autoexec 20 hours ago
WebGL is still putting people at risk:
CVE-2026-87464
CVE-2026-87488
CVE-2026-87438
CVE-2026-87527Comment by Razengan 1 day ago
Maybe it did and you're just hooked up to the Matrix thinking it didn't
Comment by StilesCrisis 1 day ago
Comment by userbinator 1 day ago
Comment by stackghost 1 day ago
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 with gtk and it sucks, but that doesn't mean we should just shovel an entire tech stack into the browser.
Just because we can, doesn't mean we should. I'm tired of these BigCos shitting everything up.
Comment by coldpie 1 day ago
Is it really better for users to download and run straight up executables with no security model? We tried that in the 90s and 2000s and it was pretty bad. We can have OSes introduce a security model, like Android and iOS do. But then what about desktop Linux users like myself? Am I just to be excluded because I don't use a popular (and proprietary) operating system?
Okay, we can invent a standard, cross platform app distribution mechanism with a security model. And that's... exactly what web browsers are. In the end it seems like the least-bad solution to me. I quite like that I can run GPU accelerated programs without the dev having to put in special effort to support my Linux distro.
I dunno, maybe I'm missing an option?
Comment by mrguyorama 18 hours ago
Yes. Unambiguously, a system where the only code that runs is code that you explicitly run is more secure. Social engineering and basic tricks of telling someone an app does A while it really does B are not solved on the web, because social engineering cannot be solved. In the supposed safe gardens of app stores, apps do exactly that all the time and are not well moderated. Apple's supposed moderation approved a "Lastpass" password manager app that was not made by the actual Lastpass company. If that can get through, then anything can get through.
Meanwhile, the webapp solution is for any site you visit to be able to download and execute whatever they want, rather than whatever you want, and most sites also set a third party to have the ability to download and run whatever they want, and Google wants that system to have as much control over your local hardware as the OS does, so how is this better at all? It's strictly worse. The web security model is worthless. It depends on random third parties you have no affiliation with to not get hacked themselves, and not make stupid choices.
It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.
What is the "Security Model" of the web, that every random person willing to pay a few cents for an advertisement should be able to run code on your machine without your authorization? That anyone should be able to target individuals for RCE through advertising infrastructure?
Comment by coldpie 17 hours ago
I don't think so? If I want to run a 3D modeling program and I download their executable and run it, it has access to everything on my system. All my local files, open access to my network connection, whatever's going on with my internal network, etc. If they want to read all my files and upload them, they can just do that. This is not true for web applications.
Programs that run in a browser are sandboxed and only have access to what web standards say they have access to. They can open a file select dialog to get a file from my machine with my permission, but they don't just have access to all of my files like a local program does. Web standards developers put a lot of effort into finding a balance between security and capabilities for new web APIs.
> What is the "Security Model" of the web
Unlike locally running programs, web applications don't have access to everything on the system by default. Interactions with the local system are intermediated by the browser. Usually the user has to approve access, or there are limitations on what types of access a web app can have.
If you head into your Firefox settings and select "Permissions and data", you can see what kinds of things given websites are allowed to access. Usually when they first try to use one of those APIs, the browser will pop up some kind of browser-level dialog asking the user for permission to perform that type of action (eg "access local devices" or "show notifications"). These are all examples of the web app security model (and there's a whole lot more that is not as user-facing).
Local applications on the other hand, do not have any kind of security model. The 3D modeling program I downloaded can just package up all of my files and upload them to their server, completely silently. That's way worse than what web applications can do!
> It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.
In fact, they don't have access to that unless you give it to them. Bluetooth access is gated by a permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...
Comment by tancop 22 hours ago
I think we need to go the other way, all in on apps. The browser only has to expose permission based I/O, WebGPU and a way to build a11y semantic trees. Globally cached libraries can handle everything else. That would reduce the attack surface and core complexity while making the platform more flexible. HTML can run as a legacy layer on top.
Comment by Melonai 1 day ago
For WASM though, I do not agree at all! It's genuinely a great system for high performance browser code. So much stuff I use now had WASM as the backbone, and I even started applying it outside of the browser in some of my architecture. I wish we had way more enthusiasm behind things like WASM, and way less for something like WebUSB.
Comment by stmw 1 day ago
Comment by lmz 1 day ago
Comment by stackghost 1 day ago
Comment by lmz 1 day ago
Comment by mitxela 1 day ago
Like, Tesco would prefer that my operating system was a roast chicken, Baowu Group would prefer it was made of steel, Berghain would prefer that it had to queue for hours to possibly get in, and Jagex would prefer it was an in-game GUI within RuneScape. None of those companies got their way, what makes Netscape special?
Comment by lmz 16 hours ago
It's silly to complain now about BigCo, WebGPU, and ignore the past 20 years of history. The WWW has not been about document delivery only for the last 20 years. Instead of tiring themselves out complaining about the Web and modern browsers, they can use something else.
Comment by slicendice 1 day ago
Comment by willio58 1 day ago
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?"
Comment by navtoj 1 day ago
Comment by asimovDev 1 day ago
Comment by 12_throw_away 1 day ago
Comment by LoganDark 1 day ago
Comment by bittercynic 1 day ago
Comment by LoganDark 1 day ago
Comment by embedding-shape 1 day ago
Comment by LoganDark 1 day ago
Comment by inventor7777 22 hours ago
When I click the death ray, it freezes Opera completely, and pins my 40 core GPU at 100% indefinitely.
However, contrary to what should happen, macOS continues merrily along. It lags a bit and some UI elements don't appear instantly, but I can summon the force quit menu and simply kill Opera, at which point the OS returns to normal.
However, there *is* _something_ confused, as my GPU is sitting at 6W and full boost, yet with no active processes. Seems to suggest that something is orphaned yet still running. I am now going to log out and back in to see if I can fix it without rebooting.
EDIT: fixed the 100% use, but not the power draw, by putting it to sleep and waking it back up. Interesting!
Comment by monster_truck 1 day ago
Comment by LoganDark 1 day ago
Comment by mitxela 1 day ago
And what happens in WebGL?
Comment by auberonedu 1 day ago
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 interactions going on I don't yet fully understand.
Comment by fingerlocks 1 day ago
Comment by kg 1 day ago
Comment by mitxela 1 day ago
Comment by SugarReflex 1 day ago
Comment by krackers 1 day ago
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?
Comment by kimixa 1 day ago
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.
Comment by kllrnohj 1 day ago
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
Comment by davsti4 1 day ago
In Chrome on Linux:
WebGPU is experimental on this platform. See https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#... deathray/:9
Failed to create WebGPU Context Provider main @ deathray/:9 (anonymous) @ deathray/:113
Uncaught (in promise) TypeError: Failed to execute 'configure' on 'GPUCanvasContext': Failed to read the 'device' property from 'GPUCanvasConfiguration': Required member is undefined. at main (deathray/:17:17)
Comment by fionera 1 day ago
Comment by asimovDev 1 day ago
Comment by fionera 1 day ago
Comment by fionera 1 day ago
"termination" : {"flags":0,"indicator":"monitoring timed out for service","code":1,"namespace":"WATCHDOG","details":["(1 monitored services unresponsive): checkin with service: WindowServer (0 induced crashes) returned not alive with context:","is_alive_func returned unhealthy : 0x2|33130:33130:1|04000000:04000000:04000000 0x4|30324:30324:0|04000400:04000400:04000400 0x5|99275:99275:2|04000400:04000400:04000400","40 seconds since last successful checkin, 139478 total successful checkins since 1481204 seconds ago, has not exited since first loaded"]},Comment by ilnmtlbnm 1 day ago
I encountered the same type of death freeze when trying (and failing) to run models in browser tabs, but didn't spend much time trying to understand how severe it is.
Hope they don't disable WebGPU...
Comment by wartywhoa23 22 hours ago
Comment by eliwang 1 day ago
Comment by germandiago 1 day ago
Comment by sgentle 1 day ago
Of course, plenty of other uses. Disable your adblocker or we crash your computer. Watch the whole ad or we crash your computer. Click the follow button or we crash your computer.
Maybe I'm crazy, but "crash your computer" as a building block seems powerful enough to be a security issue. Is denial of service not a security thing anymore?
Comment by jeroenhd 1 day ago
Making the user force-reboot the computer would make the usual fake AV shtick a lot more believable.
Comment by mitxela 1 day ago
It is, but only when a big corp isn't doing it. X is allowed to deny you service without an account and Reddit is allowed to deny you service without uploading your personal documents to Persona.
Comment by code_duck 1 day ago
Comment by mitxela 1 day ago
Comment by pessimizer 1 day ago
Comment by mitxela 23 hours ago
Comment by code_duck 11 hours ago
Comment by thin_carapace 1 day ago
Comment by pjmlp 1 day ago
A OpenGL ES 3.0 application without any issues, might be super slow when ported to run on WebGL 2.0.
Comment by itstrueitried 1 day ago
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.Comment by anakaine 1 day ago
Comment by LoganDark 1 day ago
Comment by yesitdoes22 1 day ago
Comment by LoganDark 1 day ago
Comment by yesitdoes22 1 day ago
If you printed to some div in the page, you will get the same effect.
Do you understand the topic? Doesn't seem like it
Comment by LoganDark 1 day ago
Since you are so polite I tested all of it just now and it turns out you are correct that running it directly from the devtools console does not cause any worse behavior than running it from a normal script tag.
However indeed logging only a single message simply causes it to be combined and show a counter instead of crashing. Logging two different messages causes the log to explode pretty instantly and hang DevTools fairly quickly.
For context on how not-crashy a single message log was, I was able to navigate to the Sources tab and pause the webpage in the middle of its infinite loop, which is not something you should be able to do if the DevTools are truly overwhelmed. (When that happens, sometimes the Sources tab simply does not load, other times trying to pause execution simply does nothing.)
Comment by wzdd 1 day ago
Worse and less defensible on the web of course.
Comment by a3w 1 day ago
Comment by hbroom 23 hours ago
Comment by alwaysmrno 1 day ago
Comment by flemhans 1 day ago
Comment by TedDoesntTalk 1 day ago
Comment by water-drummer 1 day ago
Comment by splittydev 1 day ago
Comment by LoganDark 1 day ago
Comment by abecedarius 1 day ago
Comment by asimovDev 1 day ago
Comment by dermacentor 1 day ago
Comment by LoganDark 1 day ago
Comment by abecedarius 1 day ago
Comment by LoganDark 15 hours ago
My Intel Mac from 2015 could be up for months without interruption or slowdown. (mostly because I stopped updating after Mojave, but my point is it never needed a reboot)
Comment by xcc3641 1 day ago
Comment by auberonedu 1 day ago
Comment by xcc3641 12 hours ago
Comment by nottorp 1 day ago
The funny thing is the page describing the problem stutters like crazy in firefox/mac while the rotating nuclear hazard wheel is displayed.
Comment by john_owl 1 day ago
Comment by dataf3l 1 day ago
- macOS 14.7.3 (23H417)
- Chrome 152.0.7977.84
- Hardware: MacBookPro17,1 (Apple M1)Comment by lambdaone 1 day ago
Comment by auberonedu 23 hours ago
Comment by kllrnohj 1 day ago
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...
Comment by jonathanlydall 1 day ago
A true scientist! (see https://xkcd.com/242/)
Comment by g-b-r 1 day ago
I tried several webview-based browsers, Chrome, and Brave, with them the phone completely freezes (except that the audio keeps going for a bit).
I tested webview browsers because by chance the first place I ran it on was Telegram's internal browser (on which the phone does freeze).
It doesn't do anything on Firefox though, and weirdly enough not even on the Chromium-based Cromite (after enabling WebGL).
I only tried waiting for a few minutes, but it wasn't giving signs of life.
If someone wants to try, keep in mind that to force restart a Pixel you have to press the power button for 30 seconds (during which you might break out in a cold sweat).
Comment by jeroenhd 1 day ago
Wonder what made the difference. I must've disabled some shady JS attack surface at some point.
Comment by g-b-r 17 hours ago
Comment by mjmjmjmj 1 day ago
Comment by chrisjj 1 day ago
How about the irrecoverable loss of data in RAM, though?
Comment by avaer 1 day ago
GPU driver engineering has received a tiny fraction of the resources of CPU engineering, while being significantly more complex. And GPU users will not pay for performance hits that better the architecture, they will just buy the other guy's GPU/use their driver. So it's a race to the top with performance and race to the bottom with architecture and stability.
Comment by Markoff 1 day ago
Comment by achierius 1 day ago
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.
Comment by jeroenhd 1 day ago
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!
Comment by stevomacdaddy 1 day ago
Comment by selectodude 1 day ago
Comment by skinfaxi 1 day ago
Comment by embedding-shape 1 day ago
Comment by layer8 1 day ago
Comment by iAMkenough 1 day ago
Comment by wpm 1 day ago
It's always funny to me when you put computers into such states. Last time I was tickled this was was when I nuked the TCC database permissions for Zoom while in a meeting, sharing my screen, using my microphone and camera. The OS rrrrreally didn't like that.
Comment by jmkni 1 day ago
Comment by devenquan 1 day ago
Comment by vivzkestrel 1 day ago
Comment by dang 1 day ago
From https://news.ycombinator.com/newsguidelines.html:
"Don't be snarky."
"Edit out swipes."
Comment by auberonedu 23 hours ago
Comment by hyperhello 1 day ago
Comment by StilesCrisis 1 day ago
Comment by SahAssar 1 day ago
Comment by LoganDark 1 day ago
It did do it to all tabs though.
Comment by mikestew 1 day ago
Comment by hyperhello 1 day ago
Comment by StilesCrisis 1 day ago
Comment by JumpCrisscross 1 day ago
"It's just" dismissals are annoying when they're blatantly wrong. An infinite-loop counter in Orion.app shouldn't cause my entire machine to freeze, down to being unable to force quit.
Comment by demibabs 1 day ago
Comment by LoganDark 1 day ago
Comment by fuzzfactor 1 day ago
Plus provide a corrective upvote from time to time especially when a knee-jerk robot is suspected, or a maybe it's an actual person where you can't tell the difference.
Sometimes it gets so bad that people hate it when you try to keep a decent article from plummeting under the depths of a sea of slop.
I think it's well-recognized that robots are more prevalent than ever and it doesn't seem to be making things better at this point.
Comment by fuzzfactor 1 day ago