- macOS 14.7.3 (23H417)
- Chrome 152.0.7977.84
- Hardware: MacBookPro17,1 (Apple M1)Busted. My browser is configured to do just that.
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.
With that one, Ctrl+Alt+Delete, Task Manager, kill iexplore.exe was usually all you needed to do thankfully. No hard power off necessary.
If not, I have fond memories of using yours!
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.
I think this point of view is making it a bit too easy.
> 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.
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.
Not true, given any unknown link or button press can redirect/go to such a site.
A true scientist! (see https://xkcd.com/242/)
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.
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 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.
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?
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 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).
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)
Worse and less defensible on the web of course.
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.
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.
The funny thing is the page describing the problem stutters like crazy in firefox/mac while the rotating nuclear hazard wheel is displayed.
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.
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...
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.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
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.)
How about the irrecoverable loss of data in RAM, though?
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.
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.
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.
From https://news.ycombinator.com/newsguidelines.html:
"Don't be snarky."
"Edit out swipes."
It did do it to all tabs though.
"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.
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.