Hacker News Reader

Comment by fidotron | Hacker News Reader

I am torn about WebGPU - on the one hand it is a necessary improvement, but it does radically increase the attack surface area in ways that just a few years ago would have been complained about by the browser security teams. (The spectre countermeasures around high resolution timing can still bite you).

This makes me suspicious that something has changed to push the balance here, and it must be something to do with trying to offload the execution of LLMs and related neural networks on to clients to reduce the cost of doing it server side.

View on HN

I think browsers should require sites to request access to WebGPU like they do location and camera.

If a random webpage is asking to use my GPU (especially if it's a sketchy-looking site I just got redirected to), that would raise flags and I'd deny access. If a game or visualization requests access, especially if it's something I've heard others praise, I'd take the risk.

Sure, someone could embed a vulnerability in some decent app which uses the GPU for actual rendering, but it's a lot harder.

Unfortunately it would be pretty hard to explain "GPU access" to a regular person in a little dialog blurb

”The application is requesting access to accelerated graphics, do you allow this?”

"Accelerated graphics? I like my computer to be faster, why wouldn't I want that"

”The application is requesting access to accelerated graphics and drastically increase it's battery usage, do you allow this?”

Even w/o a vulnerability a GPU is a great way to burn battery on a mobile phone fast thanks to some stupid effect on a web page or in an ad.

I like the permission idea.

> it does radically increase the attack surface area

I've seen this argument being made quite often. However, I have yet to any evidence given. Can you provide concrete examples of how WebGPU is less secure than WebGL or other web APIs?

These days you can ask chatGPT to Google it for you ;-).

Sure, but we are still off a scientific breakthru before we will receive meaningful replies.

I did, actually, before posting here. It couldn't tell me anything except a vague "it's a broader and more low-level API so it has a wider attack surface". Except in about 2000 words.

By the way, it was tiresome when people told me to go Google answers. It's just as tiresome when people tell me to go ask an AI. I'm here to talk with real people, not computers.

Besides, HN is a place where there's often an expert who will know far more than what's widely available on the web about even the most obscure of technical knowledge.

> but it does radically increase the attack surface area in ways that just a few years ago would have been complained about by the browser security teams.

Source? "GPUs feel low-level like C and C is unsafe" is a vibes argument.

> (The spectre countermeasures around high resolution timing can still bite you).

The fact this is a problem at the highest of levels provides further damning evidence that this isn't a large change to the status quo.

Current LLMs have vram and power requirements that mean it’s unlikely we’ll see a decent LLM running on phones without a step change in technology.

I currently have mistral 7b running on my phone through the MLCChat app. The performance isn’t too bad for something running on phone hardware. I’d consider that decent, if not world beating.

Reply on news.ycombinator.com