Re: [w3ctag/design-reviews] WebHID API (Human Interface Device) (#370)

> If the permission dialog has three (allow shared, allow exclusive, deny) buttons instead of two (allow, deny) - this case might be coverable. (Whether or not current browser permission management lets you do that, that is another problem.)
>
> Would this be a possible option considering?

I'm concerned that it would be difficult to educate users on the difference between shared and exclusive access. 99% of the time either "allow" option would work. In the instances where one or the other doesn't work, the user will experience failures that can't be easily traced back to the permission choice.

Applications could mitigate this by guiding the user to select one or the other, but if the correct choice is already known by the application prior to requesting permission then perhaps it should just be an option for requestDevice instead of a choice presented to the user.

> Aside from first-party requests, there is the case of valid third party requests - for example from a security researcher. This is more of a policy problem than a technical problem, so I might want to bring it up with W3C to figure out how we want to deal with this.
>
> Do you have any thoughts on this?

That's a good point, I think we should be able to accept third party requests but with a higher bar for proof that the blocked functionality presents a credible risk to users. Even if we're convinced that some blocking is warranted, in most cases we will want to follow up with vendors to make sure the proposed blocklist rules have the correct scope.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/370#issuecomment-743372781