Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Deathray: A simple way for an untrusted site to freeze a Mac

auberon.xyz

Post reply on HN
Print view View original

191–198 of 198 posts

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#191

Post by mrguyorama »

jonahx wrote: post #162
concinds wrote: post #155

Earlier quoted context omitted.

You're enraged by a popup that asks if you want to restore your tabs, given that it just crashed?

I'd guess GP id enraged that you can't selectively choose, or that there is no option to have the tabs restored without auto-loading, so you can keep your list of open work without being forced to reload a freezing tab.

On Firefox, when it reopens, it isn't actually running any tab other than the one you were looking at when it closed.

When you switch to one of the other tabs, that's the first time they are actually instantiated and run. So if you had this tab in the background, your machine crashed, and Firefox reopened on boot, it would not crash again.

Often, it will report "We are having trouble restoring your session", seemingly without reason, and that dialog has a very simple system for choosing which windows and tabs to recreate vs which to discard. I think you can change a setting to always use this dialog.

I can't recall if chrome has the same interface.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#192

Post by zelphirkalt »

phoghed wrote: post #165
zelphirkalt wrote: post #92

Earlier quoted context omitted.

Do you think a regular user knows how to block a specific website or never click a link leading to it again? And what about the ads people, adding such a thing if you don't load their ads? I think this point of view is making it a bit too easy.

> And what about the ads people, adding such a thing if you don't load their ads? Through what mechanism? You don’t load their code, so then they presumably load this malicious code? If they could do that they would have just loaded the ad!

You could be blocking specific third-parties. I know I do. Site owner could load from other party, that you happen to have whitelisted for example. Or site owner could use first party scripts for that, feeling smug showing their anti-ad-block warning and then bombing you, if after some time you don't comply and deactivate your ad-blocking solution.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#193

Post by mrguyorama »

coldpie wrote: post #153
stackghost wrote: post #47

Earlier quoted context omitted.

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 propriet…

>Is it really better for users to download and run straight up executables with no security model?

Yes. Unambiguously, a system where the only code that runs is code that you explicitly run is more secure. Social engineering and basic tricks of telling someone an app does A while it really does B are not solved on the web, because social engineering cannot be solved. In the supposed safe gardens of app stores, apps do exactly that all the time and are not well moderated. Apple's supposed moderation approved a "Lastpass" password manager app that was not made by the actual Lastpass company. If that can get through, then anything can get through.

Meanwhile, the webapp solution is for any site you visit to be able to download and execute whatever they want, rather than whatever you want, and most sites also set a third party to have the ability to download and run whatever they want, and Google wants that system to have as much control over your local hardware as the OS does, so how is this better at all? It's strictly worse. The web security model is worthless. It depends on random third parties you have no affiliation with to not get hacked themselves, and not make stupid choices.

It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.

What is the "Security Model" of the web, that every random person willing to pay a few cents for an advertisement should be able to run code on your machine without your authorization? That anyone should be able to target individuals for RCE through advertising infrastructure?

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#194

Post by coldpie »

mrguyorama wrote: post #193
coldpie wrote: post #153

Earlier quoted context omitted.

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 propriet…

>Is it really better for users to download and run straight up executables with no security model? Yes. Unambiguously, a system where the only code that runs is code that you explicitly run is more secure. Social engineering and basic tricks of telling someone an app does A while it really does B are not solved on the web, because social engineering cannot be solved. In the supposed safe gardens of app stores, apps d…

> Unambiguously, a system where the only code that runs is code that you explicitly run is more secure.

I don't think so? If I want to run a 3D modeling program and I download their executable and run it, it has access to everything on my system. All my local files, open access to my network connection, whatever's going on with my internal network, etc. If they want to read all my files and upload them, they can just do that. This is not true for web applications.

Programs that run in a browser are sandboxed and only have access to what web standards say they have access to. They can open a file select dialog to get a file from my machine with my permission, but they don't just have access to all of my files like a local program does. Web standards developers put a lot of effort into finding a balance between security and capabilities for new web APIs.

> What is the "Security Model" of the web

Unlike locally running programs, web applications don't have access to everything on the system by default. Interactions with the local system are intermediated by the browser. Usually the user has to approve access, or there are limitations on what types of access a web app can have.

If you head into your Firefox settings and select "Permissions and data", you can see what kinds of things given websites are allowed to access. Usually when they first try to use one of those APIs, the browser will pop up some kind of browser-level dialog asking the user for permission to perform that type of action (eg "access local devices" or "show notifications"). These are all examples of the web app security model (and there's a whole lot more that is not as user-facing).

Local applications on the other hand, do not have any kind of security model. The 3D modeling program I downloaded can just package up all of my files and upload them to their server, completely silently. That's way worse than what web applications can do!

> It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.

In fact, they don't have access to that unless you give it to them. Bluetooth access is gated by a permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#195

Post by g-b-r »

jeroenhd wrote: post #158
g-b-r wrote: post #118

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

Pixel 9s are very different from Pixel 10s, in any case

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#196

Post by lmz »

mitxela wrote: post #69
lmz wrote: post #58

Earlier quoted context omitted.

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.

Some kind of market forces kept Netscape in check back then. Now they aren't. 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?

The point is that browsers have been made and funded by BigCo, and treated as app delivery platforms at least for the last 20 years. Netscape, Microsoft, Apple, Google (for Mozilla and then Chrome). The last non BigCo mainstream(?) browser was probably Opera.

It's silly to complain now about BigCo, WebGPU, and ignore the past 20 years of history. The WWW has not been about document delivery only for the last 20 years. Instead of tiring themselves out complaining about the Web and modern browsers, they can use something else.

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#197

Post by LoganDark »

abecedarius wrote: post #163
LoganDark wrote: post #116

Earlier quoted context omitted.

I don't think I had the issue before macOS 26, but honestly I have no way to tell. I did run into one other HN commenter that suffers from the same slowness problem, but they didn't connect it to workloads, only uptime. I think it was the same issue though.

fwiw I also observed a persisting slowdown soon after upgrading my Studio to OSX 26. Since I haven't been using it very much I'm short on data bearing on the cause -- maybe it was GPU use though I don't recall doing anything like that.

I know that if I don't use LLMs, the machine lasts much longer without getting slow. If I do however, it gets slow very quickly and does not recover until a reboot. Super annoying.

My Intel Mac from 2015 could be up for months without interruption or slowdown. (mostly because I stopped updating after Mojave, but my point is it never needed a reboot)

Re: The Deathray: A simple way for an untrusted site to freeze a Mac

#198

Post by sans_souse »

socalgal2 wrote: post #86

This 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…

So you're saying it's a feature?
Post reply on HN