Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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!

  • 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.
    by kg
  • 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.

  • 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)
  • I want to click it so bad, but I can't bring myself to do it.
  • honestly i bet it feels good as fuck to click on malware, just once
  • For me it just caused Safari to stop working until I quit and restarted it.
  • Call of the void is strong in this one
  • I tried it on macOS Sequoia and it froze everything except the cursor movement.
  • 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?"

  • 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.
  • 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?
    by xoa
  • 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.

  • 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.
  • > 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.

  • > 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.

  • Unplug your ethernet cable?
  • Chrome asks whether to reopen windows if it didn't exit normally. Safari appears to just YOLO it. Don't know about Firefox.
  • 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?
  • 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.
  • 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)
  • 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!

  • 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.