4 ms·

We need more of those “do you want to allow....” confirmations. They are trivial to accept in the rare cases when webgl is actually required (online game or som

by theamk 6y ago

We need more of those “do you want to allow....” confirmations. They are trivial to accept in the rare cases when webgl is actually required (online game or something), but will introduce enough friction and “default off” behavior that sites should stop using them by default. This will probably help with security as well, there has been a fair share of webgl exploits as well.

mdtusz 6y ago
Yes, but also no. More granular browser API permissions would be fantastic, but the current interface for grant/deny in all the major browsers is annoying enough as is. The prompts need to be moved to a less in-your-face place, or at least have the option to be. I almost always find myself clicking "deny" because no, I don't want to give your recipe site permission to show notifications. Somewhat related is the new "sign in with Google" prompt I've been seeing on lots of websites. I accidentally clicked it when visiting the Seattle Times website and have been working inundated with spam emails even after clicking unsubscribe.
keyringlight 6y ago
The issue with this and all similar permission dialogs is that they often go the other way, you're training the user to just hit "allow" and swat the dialog away so they can get at the task/site they wanted. It's one thing to give the user options and ask for everything, but you've got to consider whether they've got the knowledge/context behind it to make a decision and whether it's presented in a way where they won't swat it away.
- pitaj 6y ago
  I think this can be solved via UX. When the browser wants WebGL, notification privs, etc: 1. Pend the request 2. Notify the user "This site wants access to the WebGL graphics API to display complex graphics. This is disabled by default to prevent browser fingerprinting. If the site fails to work properly, click the lock icon and allow it." 3. Deny access until the user explicitly enables it on a temporary or permanent basis
- johnyzee 6y ago
  It should simply be disabled until the user performs an action that requires it. I believe web audio works the same way.
- theamk 6y ago
  Remember those things are non-blocking.. for users who do not care, it is just another bar at the top they can ignore and proceed with their life. Also from a "user privacy" point of view, this is still OK. Right now, disabling webgl is so rare it makes the user stand out a lot, and can be used as a tracking signal. Also, websites do not expect this to be disabled, and can break. But if a non-trivial fraction of the users (say 10%) start refusing WebGL, then websites have to keep working without it; and the fact that it is disabled can no longer be used as tracking indicator.

by theamk 6y ago

mdtusz 6y ago

Yes, but also no. More granular browser API permissions would be fantastic, but the current interface for grant/deny in all the major browsers is annoying enough as is. The prompts need to be moved to a less in-your-face place, or at least have the option to be. I almost always find myself clicking "deny" because no, I don't want to give your recipe site permission to show notifications. Somewhat related is the new "sign in with Google" prompt I've been seeing on lots of websites. I accidentally clicked it when visiting the Seattle Times website and have been working inundated with spam emails even after clicking unsubscribe.

keyringlight 6y ago

The issue with this and all similar permission dialogs is that they often go the other way, you're training the user to just hit "allow" and swat the dialog away so they can get at the task/site they wanted. It's one thing to give the user options and ask for everything, but you've got to consider whether they've got the knowledge/context behind it to make a decision and whether it's presented in a way where they won't swat it away.

pitaj 6y ago
I think this can be solved via UX. When the browser wants WebGL, notification privs, etc: 1. Pend the request 2. Notify the user "This site wants access to the WebGL graphics API to display complex graphics. This is disabled by default to prevent browser fingerprinting. If the site fails to work properly, click the lock icon and allow it." 3. Deny access until the user explicitly enables it on a temporary or permanent basis
johnyzee 6y ago
It should simply be disabled until the user performs an action that requires it. I believe web audio works the same way.
theamk 6y ago
Remember those things are non-blocking.. for users who do not care, it is just another bar at the top they can ignore and proceed with their life. Also from a "user privacy" point of view, this is still OK. Right now, disabling webgl is so rare it makes the user stand out a lot, and can be used as a tracking signal. Also, websites do not expect this to be disabled, and can break. But if a non-trivial fraction of the users (say 10%) start refusing WebGL, then websites have to keep working without it; and the fact that it is disabled can no longer be used as tracking indicator.