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.

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?

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?

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 want to click it so bad, but I can't bring myself to do it.

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?

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/

    while (true) console.log('this will freeze/crash dev tools') 

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.

Maybe that would be better than a meltdown . . .

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.