- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Nov 2016 18:00:13 +0000
- To: public-device-apis-log@w3.org
> I agree with @lknik : permissions are the fence around API whatever sensors are actually present on the system. Just to clarify here, what would the algorithm called on `.start()` do? I see three options: ### Option 1 1. Check to see if the sensor exists. 1. If it doesn't, then throw a `NotAllowedError` and abort these steps (i.e. pretend the user rejected access to the sensor) 1. Prompt the user for permission to access the sensor. 1. If the user grants access, then update readings. 1. Otherwise, throw a `NotAllowedError`. >From a fingerprinting perspective, this is better, but it prevents the developer from making distinctions between missing HW and denied access. ### Option 2 1. Prompt the user for permission to access the sensor. 1. If the user grants access, then: 1. Check to see if the sensor exists. 1. If the sensor exists go ahead and provide data. 1. Otherwise, throw a `NotReadableError`. 1. Otherwise, throw a `NotAllowedError`. This option is still good from a fingerprinting perspective, provides the developer with more accurate information, but prompts users with weird questions if they don't have the requested sensor. ### Option 3 1. Check to see if the sensor exists. 1. If it doesn't, then throw a `NotReadableError` and abort these steps 1. Prompt the user for permission to access the sensor. 1. If the user grants access, then update readings. 1. Otherwise, throw a `NotAllowedError`. This option is bad from a fingerprinting perspective. Great from UX and devX perspective. -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/145#issuecomment-260716989 using your GitHub account
Received on Tuesday, 15 November 2016 18:00:20 UTC