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

171–180 of 198 posts

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

#171

Post by alt227 »

socalgal2 wrote: post #93
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.

A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes. Guess I won't go there again" > 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 no…

This is hilarious, and what if an bad actor abuses this and makes a script or browser plugin which goes to this url every time a browser is launched?

What about url shorteners and redirects?

You seem to dismiss the issue based on a very narrow avoidable case.

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

#174

Post by KomoD »

ktm5j wrote: post #167
andyferris wrote: post #133

Earlier quoted context omitted.

Nitpick: monkeys have enough brains for "oh, I shouldn't do that again".

Is that really an important detail? I think what I said got my point across.

Yes, it's disrespectful to monkeys. Monkeys have feelings too.

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

#175

Post by trollbridge »

sersi wrote: post #111
socalgal2 wrote: post #93

Earlier quoted context omitted.

A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes. Guess I won't go there again" > 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 no…

An average user will not know that the site caused the issue. The first time after force turning off the computer, it will restart and reopen all windows causing the computer to crash again. The next time, they might click on the button to prevent reopening all windows and everything will be fine until they opens safari which will cause the same issue. At that point, they'll call whoever is their computer expert user…

It's worse than that: a default macOS install with Safari will re-open Safari, complete with re-opening the tab that was open upon a hard power off and power back on.

So to get it to stop doing this on restart, I had to be very quick to force-quit Safari as the machine rebooted. You don't get a chance to tell it "Don't reopen all windows" when you hold the power button down.

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

#176

Post by inventor7777 »

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!

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

#177

Post by ktm5j »

CrompyBlompers wrote: post #169
ktm5j wrote: post #167

Earlier quoted context omitted.

Is that really an important detail? I think what I said got my point across.

My brain stuck on the inaccurate monkey comparison and caused unnecessary work to get past it and back onto the point you were making.

Sometimes you guys think too much..

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

#178

Post by ktm5j »

KomoD wrote: post #174
ktm5j wrote: post #167

Earlier quoted context omitted.

Is that really an important detail? I think what I said got my point across.

Yes, it's disrespectful to monkeys. Monkeys have feelings too.

Well if one reads my comment I'll consider apologizing.

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

#179

Post by tancop »

stackghost wrote: post #47
xoa wrote: post #33

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…

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…

People don't want documents. Almost everything useful you do on the web is some form of interactive app from a simple forum with no JS to Figma or 3D games.

I think we need to go the other way, all in on apps. The browser only has to expose permission based I/O, WebGPU and a way to build a11y semantic trees. Globally cached libraries can handle everything else. That would reduce the attack surface and core complexity while making the platform more flexible. HTML can run as a legacy layer on top.

Post reply on HN