In general Web 3D is slower than native 3D APIs anyway, due to all the sandboxing and other restrictions.
A OpenGL ES 3.0 application without any issues, might be super slow when ported to run on WebGL 2.0.
The Deathray: A simple way for an untrusted site to freeze a Mac
151–160 of 198 posts
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#152Earlier quoted context omitted.
> It's a self correcting problem. You go to a site, it freezes your machine, you never visit the site again. What do regular users do about a malicious ad that runs on thousands of different sites? > Turning off WebGL = no more Figma, no more Canva, no more Google Maps Which is why you should probably rather turn off the actual vulnerable API, i.e. WebGPU, not WebGL.
It really ought to be something you can enable or disable per site. I was surprised to find its not.
Maybe a browser extension could inject JS in a tab to redefine all the WebGPU API into a noop.
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#153While 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…
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…
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.
I dunno, maybe I'm missing an option?
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#154Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#155Earlier quoted context omitted.
Chrome asks whether to reopen windows if it didn't exit normally. Safari appears to just YOLO it. Don't know about Firefox.
What if you needed all of your other tabs? It enrages me that how the browsers all decided that my state and my history were worthless to me. You know what happens when your business is a browser and you gradually deprecate different functions of a browser, rather than refining and expanding on them?
You're enraged by a popup that asks if you want to restore your tabs, given that it just crashed?
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#156Does a QR code for https://auberon.xyz/deathray freeze iPhones/iPads?
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#157Could 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…
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.
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#158It freezes a Pixel 10 on Chrome, Webviews and Brave..! 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 Chrom…
Pixel 9 Pro with Brave, it just sort of freezes for a second or two before I can close the tab using the normal brave button.
Wonder what made the difference. I must've disabled some shady JS attack surface at some point.
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#159When the M1 chips came along you could freeze a Mac to the point of restart (kernel panic?) by having a page with 2,000 mp4 videos playing at once
Re: The Deathray: A simple way for an untrusted site to freeze a Mac
#160This has been around since 2011 when WebGL shipped. It's documented in the spec. It's a self correcting problem. You go to a site, it freezes your machine, you never visit the site again. 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…
This take feels too cavalier.
Since the machine is actually frozen, it enables many plausible social engineering scams ("We have detected a virus that froze your machine. Call this number for help..."), and I bet it has been used that way.
Not to mention possible data loss, interruption of work at a critical time, and so on.