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 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.
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.
A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes. Guess I won't go there again"
> 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.
I think a lot of HN commenters are way too disconnected from the average person. You're making a big assumption that a user will even connect the dots until the same thing happens multiple times, if even then. The average computer user is extremely bad at connecting cause and effect on their computer. Think of how many times you hear "my computer is broken!" when actually it's something like the printer was unplugged/turned off and they were just having trouble printing a document (or, if you are so disconnected from average users/people, the answer is _this happens a lot_). Even what we think of as simple stuff completely befuddles them.
> I think a lot of HN commenters are way too disconnected from the average person
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.
An average user will not know that the site caused the issue. The first time after force turning off the computer, it will restart and reopen all windows causing the computer to crash again. The next time, they might click on the button to prevent reopening all windows and everything will be fine until they opens safari which will cause the same issue. At that point, they'll call whoever is their computer expert user to help them out.
It's worse than that: a default macOS install with Safari will re-open Safari, complete with re-opening the tab that was open upon a hard power off and power back on.
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.
They are addressing the fact that no bad actor will care to make it, not that they can't.
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.
Im arguing against the parent point that "Site freezes machine, user stops going to site." Its a gross oversimplification, and it doesnt hold water becasue there are lots of other vectors to a user coming across this than just "oh I recognise that web address as bad so I wont go there".
> but what had actor will want to pursue even one? They gain nothing
Ask that to anyone who has ever rickrolled somebody.
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".
> 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!
You could be blocking specific third-parties. I know I do. Site owner could load from other party, that you happen to have whitelisted for example. Or site owner could use first party scripts for that, feeling smug showing their anti-ad-block warning and then bombing you, if after some time you don't comply and deactivate your ad-blocking solution.
I just don’t think people are doing malicious ads like that. Like I’m sure it exists but like what’s the point? If you are the malicious person you pay money for ads to freeze someone’s computer and that’s it? It’s not even like you would gain anything from it
Failure to imagine an incentive doesn't mean there isn't one. You can't rely on this type of thinking to reason about security. The thing you would have never thought of is what gets you.
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.
That’s why I said I’m sure it does exist but based on it only freezing the computer until you reboot it that’s not useful for hackers doing it to make money and doesn’t seem that useful for disruption unless of course you do hack a bigger ad network then I could see it legitimately being disruptive rather than a slight nuisance. It definitely should be fixed though, it’s crazy it’s gone so long with no fix
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.
Back in the 90s when the web was non-commercial and fun, I added a "Don't Click Me" link that loaded a 'browser test' page (after a series of "are you really really sure?" dialogs) that exploited every historical browser bug I could find. Infinite popups, inescapable dialogs, ActiveX quirks, various hangs and crashes, the works.
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.
I remember when `alert` would lock up the entire browser UI. So if you put it on an infinite loop, that was it. You had to kill the browser process to shut it off.
there was a common "shock site" called "last measure" that did this. it loaded all sorts of offensive images, blasted a loop of a guy yelling something offensive about pornography, and then proceded to lock up your machine.
And also the more innocent “You Are An Idiot, hahaha hahaha” page that would sing those words and spam pop up windows with white and black text blinking, that would float around the screen. Every time you click close on one window, two new ones pop up.
With that one, Ctrl+Alt+Delete, Task Manager, kill iexplore.exe was usually all you needed to do thankfully. No hard power off necessary.
I was just talking about that one with someone a few days ago! Amazing hahah XD I still remember the song and was singing it while laughing profusely at how obnoxious that site was!
I remember in the 2000s, Dattebayo fansubs had a custom 404 page (for anyone trying to download an episode before they published it I guess), that would do similar. Endless popups, a really bad full volume audio loop, and every other trick to make it impossible to close the page. Was quite the jumpscare.
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)
Huh, this completely crashed my Firefox on Linux, which I've never had happen before. At least the rest of the programs on my desktop seem to have been completely unaffected.
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?
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.
On Firefox, when it reopens, it isn't actually running any tab other than the one you were looking at when it closed.
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 tested this on my Mac Studio M4 Max running Sequoia 15.7.9. The only browser I use other than Safari (which requires Tahoe for WebGPU) is Opera, so I tested it there.
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!
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?
I'm with you. WebGPU has been used to compromise and fingerprint systems. Firefox (and related forks) are usually able to disable this kind of insecure fluff but it'd be nice if other browsers did as well.
Hopefully, but it's good to have it disabled as well so that your system isn't screwed by the next zero day and to help cover you in case the fingerprinters manage to find a technique to get identifying data from WebGPU that your ad-blocker hasn't accounted for. It's a constant arms race after all. Hopefully the ad-blocker is still feeding them randomized data even with it disabled, but otherwise other randomized data points should keep your fingerprint unique even if a lack of WebGPU support stays consistent.
>On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
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.
WebGL is also a major security risk that has been used to compromise many machines. The world didn't end, but many people have been hurt because of it. I disabled WebGL the moment support was added in firefox too.
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 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.
Hey you’re right, we should gladly accept every decision the big corps make. They know best, after all. We should probably lick their boots too, in gratitude for their benevolence.
The application delivery thing was done as far back as Netscape threatening to relegate Windows to "a poorly debugged set of device drivers" so Web-whatever is simply another step in that direction. Like I said, if you purists want just document delivery, you can use links or w3m or maybe Gemini.
Some kind of market forces kept Netscape in check back then. Now they aren't.
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?
The point is that browsers have been made and funded by BigCo, and treated as app delivery platforms at least for the last 20 years. Netscape, Microsoft, Apple, Google (for Mozilla and then Chrome). The last non BigCo mainstream(?) browser was probably Opera.
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.
Yeah in the end I probably agree on WebGPU, I haven't really seen a single use of it, except for running shader code examples in browser, which might as well be replaced by a looping video.
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.
So, I kind of agree, but I don't know what a better solution looks like.
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.
>Is it really better for users to download and run straight up executables with no security model?
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?
> Unambiguously, a system where the only code that runs is code that you explicitly run is more secure.
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.
People don't want documents. Almost everything useful you do on the web is some form of interactive app from a simple forum with no JS to Figma or 3D games.
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.
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.
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.
Historically, for loops in shaders were limited in the number of iterations they could run for. Among other things this ensures that rasterizing a particular pixel completes in a known amount of time (and ideally that amount of time is fast enough to avoid triggering TDR on windows and making the machine bluescreen). You could of course nest loops so it's not a perfect measure. I'm not certain whether that limitation applies to WebGPU, but it should apply to WebGL.
Historically this was because GPUs didn't have control flow and the compiler had to fully unroll the loop. Once that was lifted, you could have any condition and were only limited by a timeout.
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 interactions going on I don't yet fully understand.
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
I guess so. I tried safe Mode, deleting chrome via terminal in recovery. Mac stops rendering as soon as I enter my disk password and it continues to load the system. Now in recovery trying to reinstall lol
After doing a system update and waiting a long time I got my mac back and a crash report.
"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"]},
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)
>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.
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
Is there no watchdog of sorts on macOS? I rememeber fiddling with GPU renderer settings in my CAD modeller that were throttling the GPU so as to keep the Windows GPU watchdog happy and avoid crashing the app.
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.
Jesus Christ! My mac reopen the windows when it restarts. And it opens the Deathray again! I had to quit safari immediately I saw the dot below its icon. And it took me yet another restart to fix the weird problems in other apps.
Could be a useful way to force user-interaction-gated flows. A "your computer is infected, click this button in 10 seconds or it will crash" type button which, at this point, most modestly-knowledgeable users would know not to click. However, after seeing their computer actually crash when the countdown hits 0, perhaps they would be more inclined to click "allow" on whatever prompt follows when they see it again.
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?
> Is denial of service not a security thing any more?
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.
what about when big companies drown the web with crawling activity, forcing webmasters to implement fingerprinting and thus massively delaying actual users from accessing webpages that would otherwise load instantly?
You could probably make a pretty believable virus page with this. First you freeze the screen, forcing the user to force reboot. Then, when the system boots again and reopens the website (at least Safari does), you go full-screen and show a "your computer froze because of a virus" screen.
Making the user force-reboot the computer would make the usual fake AV shtick a lot more believable.
This issue is older than the M chips: a formative OpenCL moment on my Intel MacBook involved locking it up in this way. By contrast, a similar CUDA kernel running on Linux was forcibly stopped after some short-ish time.
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.
> Do you understand the topic? Doesn't seem like it
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.)
Froze my Brave browser on Windows for about 10 seconds. Every page turned white.
then they refreshed and worked again, except the offending page.
As the author speculated that tab was frozen.
It kind of froze my Mac Studio M2 Ultra, but I was able to still move the mouse and force-quit Safari using Command+Q. Once I did, everything immediately went back to normal.
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?
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.
I know that if I don't use LLMs, the machine lasts much longer without getting slow. If I do however, it gets slow very quickly and does not recover until a reboot. Super annoying.
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)
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.
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...
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<u32>) 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
It freezes a Pixel 10 on Chrome, Webviews and Brave..!
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).
It's very easy to lock up your browser or machine with WebGPU, it happens on Windows too. You'll do this by accident constantly in a big WebGPU project, until the Chrome GPU trace/renderdoc/nsight shows some crazy deadlock bottleneck you have no hope of understanding at the browser level.
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.
Absolutely no effect on Firefox on Android 16, same with Vivaldi on W10. Everything works normal, not even higher CPU load, just shows some blank page.
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!
Yes, but it didn't kernel panic my computer, it just forced WindowServer to quit, but it "helpfully" reopens all of your windows/apps, so it reloads the tab that caused the deadlock to begin with, rinse and repeat.
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.
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 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.
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.
A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes. Guess I won't go there again"
> 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.
> A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes.
Not true, given any unknown link or button press can redirect/go to such a site.
I think a lot of HN commenters are way too disconnected from the average person. You're making a big assumption that a user will even connect the dots until the same thing happens multiple times, if even then. The average computer user is extremely bad at connecting cause and effect on their computer. Think of how many times you hear "my computer is broken!" when actually it's something like the printer was unplugged/turned off and they were just having trouble printing a document (or, if you are so disconnected from average users/people, the answer is _this happens a lot_). Even what we think of as simple stuff completely befuddles them.
> I think a lot of HN commenters are way too disconnected from the average person
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.
You sir, are very aware of how the average computer user thinks!
An average user will not know that the site caused the issue. The first time after force turning off the computer, it will restart and reopen all windows causing the computer to crash again. The next time, they might click on the button to prevent reopening all windows and everything will be fine until they opens safari which will cause the same issue. At that point, they'll call whoever is their computer expert user to help them out.
It's worse than that: a default macOS install with Safari will re-open Safari, complete with re-opening the tab that was open upon a hard power off and power back on.
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.
Not sure if it’s a setting but my mac definitely asks me if I want to reopen windows after a forced reboot.
This is hilarious, and what if an bad actor abuses this and makes a script or browser plugin which goes to this url every time a browser is launched?
What about url shorteners and redirects?
You seem to dismiss the issue based on a very narrow avoidable case.
They are addressing the fact that no bad actor will care to make it, not that they can't.
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.
Im arguing against the parent point that "Site freezes machine, user stops going to site." Its a gross oversimplification, and it doesnt hold water becasue there are lots of other vectors to a user coming across this than just "oh I recognise that web address as bad so I wont go there".
> but what had actor will want to pursue even one? They gain nothing
Ask that to anyone who has ever rickrolled somebody.
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.
My brain stuck on the inaccurate monkey comparison and caused unnecessary work to get past it and back onto the point you were making.
Sometimes you guys think too much..
A better analogy would have reduced required thought. But here we are.
Yes, it's disrespectful to monkeys. Monkeys have feelings too.
Well if one reads my comment I'll consider apologizing.
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.
> 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!
You could be blocking specific third-parties. I know I do. Site owner could load from other party, that you happen to have whitelisted for example. Or site owner could use first party scripts for that, feeling smug showing their anti-ad-block warning and then bombing you, if after some time you don't comply and deactivate your ad-blocking solution.
> It's a self correcting problem. You go to a site, it freezes your machine, you never visit the site again.
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.
It really ought to be something you can enable or disable per site. I was surprised to find its not.
Maybe a browser extension could inject JS in a tab to redefine all the WebGPU API into a noop.
I just remembered and checked. Noscript does allow blocking webgl on a per site basis.
I just don’t think people are doing malicious ads like that. Like I’m sure it exists but like what’s the point? If you are the malicious person you pay money for ads to freeze someone’s computer and that’s it? It’s not even like you would gain anything from it
Failure to imagine an incentive doesn't mean there isn't one. You can't rely on this type of thinking to reason about security. The thing you would have never thought of is what gets you.
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.
That’s why I said I’m sure it does exist but based on it only freezing the computer until you reboot it that’s not useful for hackers doing it to make money and doesn’t seem that useful for disruption unless of course you do hack a bigger ad network then I could see it legitimately being disruptive rather than a slight nuisance. It definitely should be fixed though, it’s crazy it’s gone so long with no fix
> All that happens is the perp loses any audience
You haven't heard about rickrolling, have you?
You can lose data though. Any open documents which aren't saved...
This take feels too cavalier.
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.
So you're saying it's a feature?
Back in the 90s when the web was non-commercial and fun, I added a "Don't Click Me" link that loaded a 'browser test' page (after a series of "are you really really sure?" dialogs) that exploited every historical browser bug I could find. Infinite popups, inescapable dialogs, ActiveX quirks, various hangs and crashes, the works.
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.
Were there multiple of these sites?
If not, I have fond memories of using yours!
I remember when `alert` would lock up the entire browser UI. So if you put it on an infinite loop, that was it. You had to kill the browser process to shut it off.
there was a common "shock site" called "last measure" that did this. it loaded all sorts of offensive images, blasted a loop of a guy yelling something offensive about pornography, and then proceded to lock up your machine.
Oh man I had forgotten about last measure. I remember multiple times scrambling for the power button.
And also the more innocent “You Are An Idiot, hahaha hahaha” page that would sing those words and spam pop up windows with white and black text blinking, that would float around the screen. Every time you click close on one window, two new ones pop up.
With that one, Ctrl+Alt+Delete, Task Manager, kill iexplore.exe was usually all you needed to do thankfully. No hard power off necessary.
I was just talking about that one with someone a few days ago! Amazing hahah XD I still remember the song and was singing it while laughing profusely at how obnoxious that site was!
I remember in the 2000s, Dattebayo fansubs had a custom 404 page (for anyone trying to download an episode before they published it I guess), that would do similar. Endless popups, a really bad full volume audio loop, and every other trick to make it impossible to close the page. Was quite the jumpscare.
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)
Huh, this completely crashed my Firefox on Linux, which I've never had happen before. At least the rest of the programs on my desktop seem to have been completely unaffected.
> 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.
It asks.
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.
On Firefox, when it reopens, it isn't actually running any tab other than the one you were looking at when it closed.
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.
Unplug your ethernet cable?
Just hope they don't add a service worker to remain functional offline
Most Macs don’t have ethernet anymore.
Can't websites install web workers for persistent full offline access these days?
This particular page succeeded at being cached.
I tested this on my Mac Studio M4 Max running Sequoia 15.7.9. The only browser I use other than Safari (which requires Tahoe for WebGPU) is Opera, so I tested it there.
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!
There are more of these hiding in WebGPU. Some work on iOS as well. I reported them to Apple but they were closed as not having security relevance.
that's because they don't hav any security relevance.
most bugs don't
DDoS-exploitable bugs generally do.
Your definition of security doesn't include availability, then?
DOS is security relevant.
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?
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!
I'm with you. WebGPU has been used to compromise and fingerprint systems. Firefox (and related forks) are usually able to disable this kind of insecure fluff but it'd be nice if other browsers did as well.
On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
True, but randomizing other data points will keep your fingerprint unique which should help prevent associating your activity across sites/sessions.
don't some of the adblock extensions randomly modify the fingerprinting you can get from this?
Hopefully, but it's good to have it disabled as well so that your system isn't screwed by the next zero day and to help cover you in case the fingerprinters manage to find a technique to get identifying data from WebGPU that your ad-blocker hasn't accounted for. It's a constant arms race after all. Hopefully the ad-blocker is still feeding them randomized data even with it disabled, but otherwise other randomized data points should keep your fingerprint unique even if a lack of WebGPU support stays consistent.
>On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
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.
WebGPU provides ZERO extra data that wasn't already available from WebGL in 2011. The world didn't end and it's been 15 years
> The world didn't end and it's been 15 years
Maybe it did and you're just hooked up to the Matrix thinking it didn't
WebGL is also a major security risk that has been used to compromise many machines. The world didn't end, but many people have been hurt because of it. I disabled WebGL the moment support was added in firefox too.
WebGL is still putting people at risk:
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 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.
The BigCos are the reason you have that browser in the first place. If you don't like it, you know where to download ... links or something.
Hey you’re right, we should gladly accept every decision the big corps make. They know best, after all. We should probably lick their boots too, in gratitude for their benevolence.
The application delivery thing was done as far back as Netscape threatening to relegate Windows to "a poorly debugged set of device drivers" so Web-whatever is simply another step in that direction. Like I said, if you purists want just document delivery, you can use links or w3m or maybe Gemini.
Some kind of market forces kept Netscape in check back then. Now they aren't.
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?
The point is that browsers have been made and funded by BigCo, and treated as app delivery platforms at least for the last 20 years. Netscape, Microsoft, Apple, Google (for Mozilla and then Chrome). The last non BigCo mainstream(?) browser was probably Opera.
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.
Yeah in the end I probably agree on WebGPU, I haven't really seen a single use of it, except for running shader code examples in browser, which might as well be replaced by a looping video.
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.
So, I kind of agree, but I don't know what a better solution looks like.
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?
>Is it really better for users to download and run straight up executables with no security model?
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?
> Unambiguously, a system where the only code that runs is code that you explicitly run is more secure.
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...
It's interesting because we learned this lesson with JVM applets, Flash and X controls in the browser, yet somehow insist on revisiting it...
People don't want documents. Almost everything useful you do on the web is some form of interactive app from a simple forum with no JS to Figma or 3D games.
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.
WebGPU/WebGL is another thing that only trusted sites should be allowed to use, just like JS in general.
> notice they have a dom.webgpu.blocked-domains with the sole entries being "easyeda.com,*.easyeda.com", I wonder what that's about?
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.
incredibly, the underlying issue seems to be lack of support for shadowing built-ins and reserved keywords
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
I want to click it so bad, but I can't bring myself to do it.
For me it just caused Safari to stop working until I quit and restarted it.
A Denial of Browsing attack.
I have two other web browsers open at any given time, so probably not really. I guess it would be if it truly did bring down the entire system.
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
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?"
honestly i bet it feels good as fuck to click on malware, just once
I tried it on macOS Sequoia and it froze everything except the cursor movement.
Call of the void is strong in this one
Remember when that unicode string nuked iOS 7 and you could set it as your SSID to get them stuck in a loop? good times.
Kinda reminds me of that wifi network with a funky name from Doctor Who that gets you uploaded to the cloud. (episode: The Bells of Saint John)
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?
Historically, for loops in shaders were limited in the number of iterations they could run for. Among other things this ensures that rasterizing a particular pixel completes in a known amount of time (and ideally that amount of time is fast enough to avoid triggering TDR on windows and making the machine bluescreen). You could of course nest loops so it's not a perfect measure. I'm not certain whether that limitation applies to WebGPU, but it should apply to WebGL.
Historically this was because GPUs didn't have control flow and the compiler had to fully unroll the loop. Once that was lifted, you could have any condition and were only limited by a timeout.
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 interactions going on I don't yet fully understand.
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
On a Windows 11 work machine - this is causing my Teams to blink black and come back randomly. Yes I used my work machine.
Tried it and now I cant boot even in safe mode. I love it
are you saying that it corrupted the OS install / bricked your Mac?
I guess so. I tried safe Mode, deleting chrome via terminal in recovery. Mac stops rendering as soon as I enter my disk password and it continues to load the system. Now in recovery trying to reinstall lol
After doing a system update and waiting a long time I got my mac back and a crash report.
I supposed you could just turn it off?
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)
>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.
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
Is there no watchdog of sorts on macOS? I rememeber fiddling with GPU renderer settings in my CAD modeller that were throttling the GPU so as to keep the Windows GPU watchdog happy and avoid crashing the app.
Amazing!
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...
Jesus Christ! My mac reopen the windows when it restarts. And it opens the Deathray again! I had to quit safari immediately I saw the dot below its icon. And it took me yet another restart to fix the weird problems in other apps.
Thank you. I was tempted to press but I was afraid of making a mess. I won't.
In general Web 3D is slower than native 3D APIs anyway, due to all the sandboxing and other restrictions.
A OpenGL ES 3.0 application without any issues, might be super slow when ported to run on WebGL 2.0.
Could be a useful way to force user-interaction-gated flows. A "your computer is infected, click this button in 10 seconds or it will crash" type button which, at this point, most modestly-knowledgeable users would know not to click. However, after seeing their computer actually crash when the countdown hits 0, perhaps they would be more inclined to click "allow" on whatever prompt follows when they see it again.
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?
> Is denial of service not a security thing any more?
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.
That’s not what denial of service is.
what about when big companies drown the web with crawling activity, forcing webmasters to implement fingerprinting and thus massively delaying actual users from accessing webpages that would otherwise load instantly?
denial of service is when service is denied
Then what is a butterfly?
when a fly is buttered
You could probably make a pretty believable virus page with this. First you freeze the screen, forcing the user to force reboot. Then, when the system boots again and reopens the website (at least Safari does), you go full-screen and show a "your computer froze because of a virus" screen.
Making the user force-reboot the computer would make the usual fake AV shtick a lot more believable.
The 'self-correcting' argument assumes users connect the freeze to the site. Most just restart, reopen the same tab, and hit it again.
Does a QR code for https://auberon.xyz/deathray freeze iPhones/iPads?
When the M1 chips came along you could freeze a Mac to the point of restart (kernel panic?) by having a page with 2,000 mp4 videos playing at once
This issue is older than the M chips: a formative OpenCL moment on my Intel MacBook involved locking it up in this way. By contrast, a similar CUDA kernel running on Linux was forcibly stopped after some short-ish time.
Worse and less defensible on the web of course.
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.
Shall we term this a Denial of Memory attack. Then in order to Contain it we have a ConDoM fix?
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
I think running it in the DevTools console is different from having a script on the page.
No actually. The only reason it crashes in dev tools is that it is rendering the printed console log.
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
> Do you understand the topic? Doesn't seem like it
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.)
Froze my Brave browser on Windows for about 10 seconds. Every page turned white. then they refreshed and worked again, except the offending page. As the author speculated that tab was frozen.
On Graphene OS, it froze Brave, but Vanadium was able to deal with it swiftly. Not sure if that has anything to do with JavaScript JIT.
Is this why Oregon Trail Deluxe freezes on Mac?
https://oregontrail.ws/games/the-oregon-trail-deluxe/play/
It kind of froze my Mac Studio M2 Ultra, but I was able to still move the mouse and force-quit Safari using Command+Q. Once I did, everything immediately went back to normal.
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?
Never.
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.
I know that if I don't use LLMs, the machine lasts much longer without getting slow. If I do however, it gets slow very quickly and does not recover until a reboot. Super annoying.
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)
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.
Does this reproduce with just the compute pass, or does WindowServer deadlock on the canvas drawable?
https://news.ycombinator.com/item?id=49653562
Sounds like CoreAnimation culls the offscreen layer from the transaction, so WindowServer never blocks waiting on presentDrawable.
It's at best denial of service. Except it's easily avoidable by never going back to that site again.
The funny thing is the page describing the problem stutters like crazy in firefox/mac while the rotating nuclear hazard wheel is displayed.
I was lucky, the website is down due a certificate error.
it crashes this hardware apparently:
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.
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...
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<u32>) 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
> I was surprised when it hung my computer and of course asked "Does it do that every time?"
A true scientist! (see https://xkcd.com/242/)
It freezes a Pixel 10 on Chrome, Webviews and Brave..!
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).
pixel 9 fold with Graphene, nothing significant in vanadium (after manually enabling JS)
Pixel 9 Pro with Brave, it just sort of freezes for a second or two before I can close the tab using the normal brave button.
Wonder what made the difference. I must've disabled some shady JS attack surface at some point.
Pixel 9s are very different from Pixel 10s, in any case
> recoverable data loss which we do not consider to be a security issue
How about the irrecoverable loss of data in RAM, though?
It's very easy to lock up your browser or machine with WebGPU, it happens on Windows too. You'll do this by accident constantly in a big WebGPU project, until the Chrome GPU trace/renderdoc/nsight shows some crazy deadlock bottleneck you have no hope of understanding at the browser level.
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.
Absolutely no effect on Firefox on Android 16, same with Vivaldi on W10. Everything works normal, not even higher CPU load, just shows some blank page.
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!
This froze my S26 Ultra on chrome
Zero impact on iOS 27.
Still impacts macOS 27 release candidate.
Yes, but it didn't kernel panic my computer, it just forced WindowServer to quit, but it "helpfully" reopens all of your windows/apps, so it reloads the tab that caused the deadlock to begin with, rinse and repeat.
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.
It’s not an iOS bug to begin with.
The title says "freeze a mac".
Tried it on my Blackberry too, also nothing. I say it's a nothingburger.
well that was incredibly annoying lol
[flagged]
It's helpful to let people know when links aren't working but can you please not be a jerk when doing so?
From https://news.ycombinator.com/newsguidelines.html:
"Don't be snarky."
"Edit out swipes."
I just haven't made those pages yet, which is why I don't link to them from anywhere on my site :)
Maybe that would be better than a meltdown . . .