Should we request permission when sensor is not supported by the platform?

[alexshalamov]

It would be nice if specification could provide guideline for the order of "get default sensor" and "request permission" steps.

If we request permission first, end user would get notification like "page would like to use sensor X" if user grants permission and then we figure out that it is not supported by HW, it would be annoying for the user / web developer.

If we check whether sensor is supported before the permission request, user experience might be better, but then information about platform is exposed before permission is granted.

[raymeskhoury]

(Chrome Security UX engineer chiming in) +1 to @owencm. I think that prompting prior to knowing whether a device is available will be a bad user experience (users already have many problems with prompts).

As a precedent, webrtc doesn't do this, for example if you go to https://webrtc.github.io/samples/src/content/getusermedia/gum/ without a device plugged in, you will see getUserMedia error: DevicesNotFoundError and there won't be a permission prompt. If you plug in a webcam and refresh the page, you will see a prompt.

[lknik]

Thanks @owencm for your reply.

I'm happy you forwarded us details from Chrome Security team. It sounds like the quoted message is referring to the current situation (i.e. 2016). Also, what about the issue of profiling? If I understand correctly, you asked them for fingerprinting. I'm interested in viewing it more generally.

What if the use cases (hardware, software) will be subject to change. Change/break the API then? In that case, we'll hear that we can't break the Web just like that.

I agree with @raymeskhoury that WebRTC isn't asking for permissions. Accidentally, it can also disclose your local IP address.

[tobie]

Thanks for the feedback, @raymeskhoury and @owencm. This matches my thoughts wrt to UX.

@lknik: if this did end-up causing fingerprinting/profiling issues down the road, we could always carve out the ability for the implementor to lie about the error type and pretend the user had denied access instead of the device missing such a sensor.

[lknik]

@tobie - how can we specify an option for doing so? Still, the discussion from above applies. Can we offer an optional way of fencing all API calls behind permissions?

[tobie]

how can we specify an option for doing so?

In the future, we could do something like this instead:

1. Check to see if the sensor exists.
2. If it doesn't, then throw a NotReadableError and abort these steps. Note User Agents may decide to throw a NotAllowedError here instead (after random but bounded delay) in order to hide the absence of the sensor on the device.
3. Prompt the user for permission to access the sensor.
4. If the user grants access, then update readings.
5. Otherwise, throw a NotAllowedError.

Still, the discussion from above applies. Can we offer an optional way of fencing all API calls behind permissions?

Not sure what you mean. What are you suggesting we do? What are you intending to accomplish by it?