-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combined permission request is problematic #183
Comments
This text is adapted from a similar note in [MEDIACAPTURE-STREAMS]. |
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) |
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. |
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. |
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:
Or something like that. |
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. |
In
requestPermission(absolute)
, the spec notes: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.
The text was updated successfully, but these errors were encountered: