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?
It looks like per-domain WebGPU blocking functionality was added just for this site!
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 known versions of Firefox.
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.
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.
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.
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.
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)
>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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"It's just" dismissals are annoying when they're blatantly wrong. An infinite-loop counter in Orion.app shouldn't cause my entire machine to freeze, down to being unable to force quit.
An infinite loop in JavaScript causes a different issue. It doesn't cause the rest of your tabs to stop working too. Or allegedly the entire rest of the OS though I can't reproduce that.
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)
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?
> 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 functionality was added just for this site!
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 known versions of Firefox.
WebGPU/WebGL is another thing that only trusted sites should be allowed to use, just like JS in general.
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.
>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.
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.
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.
On a Windows 11 work machine - this is causing my Teams to blink black and come back randomly. Yes I used my work machine.
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)
>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.
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?
I want to click it so bad, but I can't bring myself to do it.
After a long day at work I saw the page, saw the warning to not click it, and I proceeded to click it lol.
Locked up my entire M1 Macbook Pro, held power button and I was back into chrome in <20s but I did kinda go "why did I just do that?"
I tried it on macOS Sequoia and it froze everything except the cursor movement.
For me it just caused Safari to stop working until I quit and restarted it.
On my M1 MacBook Air with MacOS 12 it hangs. The mouse pointer still moves, but I can't bring up the force quit dialogue, and couldn't get anything else to work either. A youtube video in another tab kept playing until I held the power button to force a shutdown.
I'm using macOS 27.0 RC on M4 Max
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.
honestly i bet it feels good as fuck to click on malware, just once
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.
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...
Is this why Oregon Trail Deluxe freezes on Mac?
https://oregontrail.ws/games/the-oregon-trail-deluxe/play/
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.
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.
This froze my S26 Ultra on chrome
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.
Zero impact on iOS 27.
The title says "freeze a mac".
It’s not an iOS bug to begin with.
Tried it on my Blackberry too, also nothing. I say it's a nothingburger.
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.
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.
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.
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.
It only froze Safari tabs for me. Not even Safari's own UI except for the web pages themselves.
It did do it to all tabs though.
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.
Why does everyone hate this comment? Attitude? I can’t figure out the wavelength here. I’m just commenting.
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.
> Why does everyone hate this comment?
"It's just" dismissals are annoying when they're blatantly wrong. An infinite-loop counter in Orion.app shouldn't cause my entire machine to freeze, down to being unable to force quit.
"It's just" is usually an annoying way to start a comment.
An infinite loop in JavaScript causes a different issue. It doesn't cause the rest of your tabs to stop working too. Or allegedly the entire rest of the OS though I can't reproduce that.
Maybe that would be better than a meltdown . . .