W3C home > Mailing lists > Public > public-device-apis-log@w3.org > November 2016

Re: [sensors] Should we request permission when sensor is not supported by the platform?

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
Message-ID: <issue_comment.created-260493774-1479164915-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:53 UTC