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: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Tue, 15 Nov 2016 18:00:13 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-260716989-1479232809-sysbot+gh@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

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