- From: Lukasz Olejnik via GitHub <sysbot+gh@w3.org>
- Date: Mon, 14 Nov 2016 23:08:36 +0000
- To: public-device-apis-log@w3.org
>How would that work precisely, though? Would you really ask the user for permission? Or instead just return permission "denied"? What if the developer then tells the user that they can't get functionality x because they've "denied access to the gyroscope." Bad UX, especially if the user has no idea what a gyroscope is. This needs to be researched more thoroughly. We're trading privacy for bad UX and this is not a decision that can be taken lightly. It might even be worth considering leaving the option up to implementors. That's precisely what I mean. We leave it to implementors, but require permissions. Implementors might e.g. not expose the object at all (if device not supported/detected), or make different "sensitivity levels", some requiring a prompt, others pre-chosen (but configurable). So: default, ask, but generally leave to implementors. You definitely don't want to return "denied" just like that in the spec. But if implementors decide otherwise, that's their (bad) choice, as it would be trivial to detect whether a sensor is supported (and the user is really asked for permission) or not (and a default answer "denied" is returned). > Web developers currently have standard ways of checking whether a feature is available: https://w3c.github.io/sensors/#feature-detection What I mean is: if I understand correctly, the systematic solution to this issue should be "solved" by feature detection mechanism? And if I get it right, that feature is left for later. -- GitHub Notification of comment by lknik Please view or discuss this issue at https://github.com/w3c/sensors/issues/145#issuecomment-260493774 using your GitHub account
Received on Monday, 14 November 2016 23:08:43 UTC