New Attack Shows Risks of Browsers Giving Websites Access to GPU | Hacker News Reader

New Attack Shows Risks of Browsers Giving Websites Access to GPU

securityweek.com

38 pointsBender20 comments

Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse though as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native application are quickly disappearing, while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser.

I don't necessarily have a problem with technologies like these, but it irks me that they're all being enabled without proper security prompts. Accessing GPUs/USB devices/MIDI devices should come with the same security boundaries downloading executables comes with, at least until sandboxes catch up.

WebUSB is pretty great when it's used for the right things (updating the Google Stadia controller, flashing ESPHome, that sort of thing) so I sort of see the value in that, but the risks of these technologies are being ignored, especially on the GPU side. GPUs are absolutely terrible at separating application code because they're designed for performance above all else.

Is a security warning for this stuff really that much to ask? Surely, clicking OK on the two or three websites that actually have a use case for WebGPU should be an acceptable trade-off?

You have to specifically give access to a device for WebUSB though, so they could update the text to say that giving the website access to the device means they can do bad stuff to it, but I think ESPhome users understand that and have to inherently trust that ESPhome hasn't been hacked to do bad things. Alert fatigue is a thing though, so I'm not sure if that'll be all that effective.

With how little these APIs are used (for acceptable purposes), I don't think alert fatigue is a huge risk here.

WebGPU is used (among other usage) for user browser fingerprinting. Which is very useful for ads personalizing. Which is the main profit source of Google who (effectively) owns the Chromium project.

> Surely, clicking OK on the two or three websites that actually have a use case for WebGPU should be an acceptable trade-off?

This would not be an acceptable tradeoff since the dialog will fire on _every web site_. Google et all will never allow it to be asked as it could hurt their main profit source.

Does anyone have a single shred of evidence that Google is doing any kind of fingerprinting?

It's the web. You can see what's happening, follow the code as it runs. Has anyone found a single shred of evidence that big bad hated evil Google is doing any of these casually cast about nasty vicious accusations?

Yes Google runs ads, and makes most of its money that way. But it needs to play a clean game & keep the web stable & trustable if that revenue stream is to survive. These conjectures that earning another 10% by setting fire to your house don't make sense. They never have. But it's what our underdog bias makes us want to believe.

> It's the web.

For most people it's Google's web. You can't see anything Chrome is doing if Google doesn't want you to see it.

Personally this reads like a descent into madness, a conspiratorial minded terror/Fear Uncertainty and Doubt stark-world outlook that actuvely seeks to erode away reality for it's preferred sense of what is.

There's just not evidence we really have much to fear here. Yes Chrome is closed source, but it seems to pretty closely resemble Chromium. Yes Chrome is closed source but there are people very good at Ghidra (& others softwares) would be be delighted to find sneaky scary shit happening.

These assertions feel baseless. It feels the opposite of the truth. Chrome is perhaps the most observable software development process on the planet. They follow their process, which involves - before any code gets written - writing explainers, bringing Early Design Reviews to W3C TAG, and then posting request-for-position review from everyone else. What software on the planet does more to pace a golden path, has a higher level of visibility, review, and regard than this? https://www.chromium.org/blink/launching-features/

> There's just not evidence we really have much to fear here.

Famous last words.

Google doesn't need to fingerprint your browser this way. I have permission prompts enabled for canvas access (the most common form of Javascript fingerprinting) and Google doesn't even use that.

Why would they? The vast majority of the internet is sending them unique identifiers along with every page load already.

> This would not be an acceptable tradeoff since the dialog will fire on _every web site_.

Sounds like a good reason to use the same approach as with notifications (disabled by default on most websites).

Google has little to gain and incredibly much to lose from doing anything as heavy-handed and transparently shady as actually doing that type of fingerprinting on the web.

And why would they? They control the majority of users' browsers and can push through things that expand their advantage in plain sight, like Privacy Sandbox, Manifest V3 etc.

I can't get over the fact that RSS is not an integral part of web browsers. Stripping its support was part of browsers digging their own (and the web's) grave.

> We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser.

lol i've been saying this for years to folks (i hate to say it but probably upwards of 10 years now sounds about right)

Personally, I don't trust websites with access to my computer at all. Sandboxing helps mitigate the risks, but isn't anywhere near sufficient.

That web browsers have become essentially an OS in their own right is one of the things that makes me increasingly hesitant to go to websites that I don't already have some sort of trust in, and so is helping to make the web a smaller place to me.

That's okay, they can still mine Bitcoin with JavaScript.

Wasm.

> New Attack Shows Risks of Browsers Giving Websites Access to GPU

Just don't tell them about USB, ok ? /s

Some people never learn.

WebUSB exists, but requires explicit permission to a specific device. I'm still not entirely comfortable with exposing that kind of API to people who have no idea what USB even is, but it's a lot safer than WebGPU.

WebUSB is actually a really OK API from a security point of view. Most high-security-impact USB classes (e.g. HID devices, allowing keyboard input logging; mass storage devices, allowing access to local files etc.) are marked as "protected" and only available to "isolated web apps" (which at the moment don't exist yet, as far as I know).

or midi, and god forbid exploit some bug in a local only 30yr old sound driver

Reply on news.ycombinator.com