Combined permission request is problematic

[marcoscaceres]

In requestPermission(absolute), the spec notes:

There is no algorithm for requesting multiple permissions at once. However, user agents are encouraged to bundle concurrent requests for different kinds of media into a single user-facing permission prompt.

Which is indicative that the permission model is not correct. This also sets a bad precedent for mixing multiple permissions policies.

We should fix this.

[reillyeon]

This text is adapted from a similar note in [MEDIACAPTURE-STREAMS].

[marcoscaceres]

Right, but there the request permission to use is single permission descriptor? Or am I misreading? (not seeing the note... maybe it got changed since this spec got changed)

[reillyeon]

I'm referring to the "User Agents are encouraged to bundle concurrent requests for different kinds of media into a single user-facing permission prompt" note under the step "For each media type kind in requestedMediaTypes, run the following sub steps, preferably at the same time". The effect of that step is that the site may request both "camera" and "microphone" permission at the same time if the device supports both audio and video.

[marcoscaceres]

Right, cool. I still think that the camera and microphone is a somewhat unique situation in the platform (those are some of the most privacy sensitive APIs on the Web).

I'm wonder if you agree that perhaps we could consider simplifying what is done here? At the same time, there is a little bit of pressure on "this ship has somewhat sailed" (like, we support this in WebKit somewhat... even if we require all there permissions).

Just seems that we are tying things that could be done more cleanly and extensibly, particularly as we continue to evolve this API.

[marcoscaceres]

Put differently, can we come up with what might be the ideal?... we don't need to commit to changing anything in the spec, but it's more conceptually... like, for me, it would be:

• one permission policy: like "orientation-motion" (we can no doubt do better even)
• and the then have .requestPermission({absolute: true})

Or something like that.

[reillyeon]

I think this ship has sailed but I think an ideal design which limited itself to only the sensors required to implement the current capabilities this specification (i.e. just sensors for determining device orientation and motion) would require only a single permission. I don't think it is necessary to communicate the difference between absolute and non-absolute through browser UX. It's only useful internally because it allows developers to inform the browser that they don't care about compass heading and can therefore avoid activating an additional unnecessary sensor.

[tomvangoethem]

I'm revisiting this after 2 years, and might be missing some context... Could you elaborate why this ship has sailed? Given the current implementation status and general approach, I don't think it makes a whole lot of sense to have separate permission names. I think if we could instead have a single policy - e.g. motion-sensors - this would simplify a lot of things (at a minimal cost in terms of control for privacy)

@reillyeon WDYT?