Just put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.
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 problem.
Maybe "it can be used to display 3D graphics and to track you", but I expect that most people will shrug and go on.
"Fingerprinting" is a better approach to the messaging, but is also going to be confusing since if you take that approach, almost all modern permissions are fingerprinting permissions, so now you have the problem of "okay, this website requires fingerprinting class A but not fingerprinting class B" and we expect an ordinary user to understand that somehow?
Counterpoint: if webpage with latest news (for example) immediately asks me to allow notification, access to webcamera and location I definitely know what is correct answer to these dialogs.
Permission prompts are a HUGE user education issue and also a fatigue issue. Rendering is widely used on websites so if users get the prompt constantly they're going to tune it out.
> Especially because they would still have access to canvas and WebGL.
Those should also be behind a (or the same) permission prompt.
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. Web sites that claim to be a web application but keep getting denied can then be reclassified as hostile web sites, at which point they not only lose the ability to annoy users with web app permission prompts, but also other privileges that web sites don't need.
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.
Distinguishing between site and app, e.g. via an installation process, is equivalent to a permissions dialog, except that you're now advocating for one giant permission dialog instead of fine-grained ones, which seems like a step backwards.
The new permission dialog wouldn't grant all of the finer-grained permissions - it would be a prerequisite to requesting them in the first place.
Curating known good would equate to some sort of app store. There are probably initiatives to make one for web apps, but it kind of makes me sad to think of applying that to the web, which is supposed to be a free and open commons (although I suppose Google already de facto controls enough of it to be considered a bit of a gatekeeper).
Making the user the arbiter of "known good", ie reliance on permissions dialogs, is not perfect but it's what we have. Yet I fail to see how your proposal of "just add ANOTHER dialog" improves the situation.
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 and the problem is solved.
Just put Camera behind permission and the problem is solved.
Just put ...
I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.
Users already expect browsers to change screen contents. That's why WebGPU / WebGL aren't behind a permission block (any moreso than "show images" should be... Hey, remember back in the day when that was a thing?).
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 removed after sites started abusing battery APIs.
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"
For example, toolbar could look like:
Enable: [ location ] [ camera ] [ fingerprinting via canvas ] ...
But more frankly, fingerprinting is a whack a mole issue and if it were a real security problem, it would slow feature advancements.
And fingerprinting is too unreliable for any real world use.
Think about it this way: Which is more tedious: going into the settings and enabling and disabling webGPU every time you need it or a popup? Which way would see you keeping it enabled?
Its tyranny of the default with an extra twist :)
"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. :/
Are you saying that because you reckon everyone using a Chromium based browser logs into a Google account?
HN Guidelines