- 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