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.
The code is just an infinite loop counter. You can cause all kinds of Safari issues with an infinite loop in JavaScript too, which is sure annoying when trying to figure out large codebases. There was a student in Japan who showed that you could do this trivially and they were arrested.
Usually you can't freeze the whole system UI with an infinite counter though. I'm pretty sure normal JS browser processes are not supposed to be able to do that.
Because kernel panics are a wildly different class of bug than breaking one browser tab. An "Oh Snap" is the designed outcome of a JavaScript infinite loop. Crashing the whole computer is not.
Hate does seem to be on the rise across the board, even for fairly trivial things. About all one person can do is try to set a non-hate example.
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.
There's more to it than just a loop. If it was just a loop, it would peg a CPU core and be done with it. But you'll have to reread TFA to find out how it takes out the window server, thus freezing the rest of the system.
Blowing up a browser tab with bad JavaScript is not considered to be a problem. But kernel panicking the computer is different--this brings us back to the bad old days of MacOS where a buggy program could force a freeze/restart at any time.
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.
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.
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.
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)
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 work unless you log two different messages, because 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
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 them to be combined and show a counter instead of crashing. Logging two different messages causes the log to explode pretty instantly and hang fairly quickly.
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?
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 was also a major security risk that was used to compromise many machines. The world didn't end, but many people were 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.
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").
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!
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 seems that easyeda.com use of WebGPU is broken in Firefox in particular. So I think they added it to the webgpu blocked domains so that easyeda.com would just treat the user as if their browser didn't support WebGPU and fallback to something else.
>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
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)
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!
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.
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)
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.
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.
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.
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.
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.
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.
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.
179 comments
[ 0.25 ms ] story [ 58.7 ms ] threadI 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...
It did it to all tabs though.
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.
https://oregontrail.ws/games/the-oregon-trail-deluxe/play/
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?
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.
Making the user force-reboot the computer would make the usual fake AV shtick a lot more believable.
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?"
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)
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
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 them to be combined and show a counter instead of crashing. Logging two different messages causes the log to explode pretty instantly and hang fairly quickly.
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.
Maybe it did and you're just hooked up to the Matrix thinking it didn't
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.
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.
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?
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?
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").
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!
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.
I found this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1980392
It seems that easyeda.com use of WebGPU is broken in Firefox in particular. So I think they added it to the webgpu blocked domains so that easyeda.com would just treat the user as if their browser didn't support WebGPU and fallback to something else.
Why does this spill over? Unlike CPU which is multiplexed by the kernel's scheduler (so infinite loops can't lock out other programs), is the GPU not multiplexed in the same fashion?
Often there's shared resources that are statically allocated to shaders (register space, local memory etc.) that means you often can't "just" add a new task if those shared resources are already in use. But not using those resources to their full would cause performance issues.
And the internal state of a GPU is often very large, much larger than a CPU, so suspending the current tasks, saving out their state and replace it with a "higher priotity" one can be very expensive - so often an afterthought of support at best.
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
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.
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!
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)
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.
If not, I have fond memories of using yours!
And what happens in WebGL?
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.
- is that another 404 https://auberon.xyz/blog/
- do you guys ever load your website from an anonymous tab before going public?
From https://news.ycombinator.com/newsguidelines.html:
"Don't be snarky."
"Edit out swipes."
Worse and less defensible on the web of course.