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

Chrome ships WebGPU

developer.chrome.com

Post reply on HN
Print view View original

271–280 of 405 posts

Re: Chrome ships WebGPU

#271

Post by toyg »

pid-1 wrote: post #182
toyg wrote: post #51

Earlier quoted context omitted.

They couldn't secure our OSes to run untrusted code safely, so they built a OS on top of a OS (yo-dawg meme here). It wouldn't even be so terrible, if it didn't tie us down to a crappy language (JS).

I think the real reason the web was built was because Google, etc... Decided they need a distribution platform that could not be locked by OS vendors, as that would be a theat to their business.

That's a cynical take. DHTML predates Google. Demand was already there before the giants appeared.

What really happened was that developers figured out that the deployment story via web was massively simpler and less burdensome. Producing good installers was hard, people in offices often couldn't install anything, and then you had to deal with DLL Hell... whereas the browser was always there already. So a series of unfortunate events was set in motion that ended up with what we have today.

Re: Chrome ships WebGPU

#272

Post by cyral »

topaz0 wrote: post #243

I'd rather not have websites soak up my compute resources, thanks. They are already doing that many times too much for my taste.

Ironically by hardware accelerating those resources, they will be less noticeable.

Re: Chrome ships WebGPU

#273

Post by beebeepka »

tgsovlerkhgsel wrote: post #248
merlish wrote: post #153

Earlier quoted context omitted.

For a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue. In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the p…

I think browsers should distinguish more aggressively between "web application", "web site", and "user hostile web site". Many APIs should be gated behind being a web application. This itself could be a permission dialog already, with a big warning that this enables tracking and "no reputable web site will ask for it unless it is clear why this permission is needed - in doubt, choose no". Collect opt-in telemetry. We…

Do you have something specific in mind with your opening paragraph?

Because defining what is a web site and what's an app, strikes me as particularly impractical idea. You correctly point out that yes, there are a number of powerful APIs that should be behind permissions. But there are a number of permissions already, so we need to start bundling them and also figure out how to present all this to the regular user.

Frankly, I wouldn't know where to begin with all this.

Re: Chrome ships WebGPU

#274

Post by fulafel »

kevingadd wrote: post #194
fulafel wrote: post #62

Earlier quoted context omitted.

It's possible to have the runtime execute the computations in fixed time across platforms.

No video driver is actually going to implement fixed-time rendering. So you'd have to implement it in user-space, and it would be even slower than WebGL. Nobody wants that. You're basically just saying the feature shouldn't ship in an indirect way (which is a valid opinion you should just express directly.)

I don't mean to prescribe the way to stop fingerprinting, just throwing out a trivial existence proof, and maybe a starting point of thinking, that it's not impossible like was suggested.

Also, WebGPU seems to conceptually support software rendering ("fallback adapter"), where fixed time rendering would seem to be possible even without getting cooperation from HW drivers. Being slower than WebGL might still be an acceptable tradeoff at least if the alternative WebGL API avenue of fingerprinting could be plugged.

Re: Chrome ships WebGPU

#275

Post by yamtaddle »

codedokode wrote: post #168
azangru wrote: post #162

Earlier quoted context omitted.

Who decides what's unnecessary?

Everything that can be used for fingerprinting should be behind a permission. Almost all sites I use (like Google, Hacker News or Youtube) need none of those technologies.

Main thing that ought to be behind a permission is letting Javascript initiate connections or modify anything that might be sent in a request. Should be possible, but ought to require asking first.

If the data can't be exfiltrated, who cares if they can fingerprint?

Letting JS communicate with servers without the user's explicit consent was the original sin of web dev, that ruined everything. Turned it from a user-controlled experience to one giant spyware service.

Re: Chrome ships WebGPU

#276

Post by samstave »

flohofwoe wrote: post #132
Ciantic wrote: post #120

This is a comment from Aras Pranckevičius [1]: > WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol) > As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd itera…

Aras is right, but the elephant in the room is still shitty mobile GPUs. Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and on…

>>"shitty mobile GPUs."

Uh, no ; it power and heat management so battery and fire risk that limits SFF -- It would be good for mobile devices to have external GPU/battery attachments via a universal connector... this will boost efficacy of devices... but you may not always need the boost provided by the umbilical - but when you do need it - just put it outside the machine, and connect it when needed...

Re: Chrome ships WebGPU

#277

Post by justinclift »

maigret wrote: post #187
justinclift wrote: post #180

Earlier quoted context omitted.

> why highly paid Google ... developers "Completely co-incidentally", it's in Google's best interest to be able to fingerprint everyone. So, changing it to actually be privacy friendly while they have the lion's share of the market doesn't seem like it's going to happen without some major external intervention. :/

It's running on Chrome. Google doesn't need fingerprinting. By making it harder for others to fingerprint it actually cements Google position in the ad market.

> It's running on Chrome. Google doesn't need fingerprinting.

Are you saying that because you reckon everyone using a Chromium based browser logs into a Google account?

Re: Chrome ships WebGPU

#278

Post by illiarian »

rockdoe wrote: post #244
illiarian wrote: post #178

Earlier quoted context omitted.

Just put WebGL/WebGPU behind permission and the problem is solved. Just put WebUSB behind permission and the problem is solved. Just put WebHID behind permission and the problem is solved. Just put WebMIDI behind permission and the problem is solved. Just put Filesystem Access behind permission and the problem is solved. Just put Sensors behind permission and the problem is solved. Just put Location behind permission…

I can't tell whether you're kidding or not, but this is exactly the path Firefox was advocating: https://blog.karimratib.me/2022/04/23/firefox-webmidi.html The page implies it no longer requires permissions, but I just tested and you definitely get a permissions popup, just a different one. WebHID, WebUSB and Filesystem Access are IIRC, "considered harmful" so they won't get implemented. And Sensor support was remove…

> I can't tell whether you're kidding or not,

I'm not. It's a bit of a sarcasm (?) listing a subset of APIs that browsers implement (or push forward against objections like hardware APIs) and that all require some sort of permission.

> but this is exactly the path Firefox was advocating

Originally? Perhaps. Since then Firefox's stance is very much "we can't just pile on more and more permissions for every API because we can't properly explain to the user what the hell is going on, and permission fatigue is a thing"

Re: Chrome ships WebGPU

#279

Post by tourgen »

flohofwoe wrote: post #132
Ciantic wrote: post #120

This is a comment from Aras Pranckevičius [1]: > WebGL was getting really old by now. I do wonder whether WebGPU is a bit late too though (e.g. right now Vulkan decides that PSOs maybe are not a great idea lol) > As in, WebGPU is very much a "modern graphics API design" as it was 8 years ago by now. Better late than never, but... What's "modern" now seems to be moving towards like: bindless everything (like 3rd itera…

Aras is right, but the elephant in the room is still shitty mobile GPUs. Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and on…

[dead]

Re: Chrome ships WebGPU

#280

Post by illiarian »

foldr wrote: post #228
illiarian wrote: post #183

Earlier quoted context omitted.

Chrome has to walk a fine line between what it does for privacy and what is says it does. So you have the protection against fingerprinting and at the same time you have the FLoC fiasco

The simplest explanation is that the Chrome developers genuinely want to protect privacy and also genuinely want to add features. Every browser has to make that trade off. There are plenty of fingerprinting vulnerabilities in Firefox and Safari too. The reasoning here seems to be something like "Google is evil; X is an evil reason for doing Y; therefore Google must have done Y because of X". It's not a great argument…

I can only quote Johnathan Nightingale, former executive of Mozilla, from his thread on how Google was sabotaging Firefox [1]:

"The question is not whether individual sidewalk labs people have pure motives. I know some of them, just like I know plenty on the Chrome team. They’re great people. But focus on the behaviour of the organism as a whole. At the macro level, google/alphabet is very intentional."

[1] Thread: https://twitter.com/johnath/status/1116871231792455686

Post reply on HN