3 ms·
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 awa
by keyringlight 5y 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 5y agoI 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 5y agoIt should simply be disabled until the user performs an action that requires it. I believe web audio works the same way.
- theamk 5y agoRemember 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.