Asks for separate permission for microphone and camera

[Matthew Paul Thomas]

0. Flash the phone.
1. In the Browser, go to a page that asks both to record video and use the microphone, such as <https://appear.in/test-drive>.
2. Accept the browser’s own prompt(s) for whether to give this site video and microphone access.

What happens:
* A trust-prompt appears asking to record audio.
* Another trust-store prompt appears, asking to use the camera.
<https://launchpadlibrarian.net/247901674/1554149-trust-store-prompts.png>

What should happen:
* Only one prompt appears, asking to record video, which includes the ability to use the microphone.
<https://wiki.ubuntu.com/SecurityPermissions#permissions>

This might not be fixable, if the Web APIs for recording video and audio are separate.

If it is fixable, it might first require implementing the combined permission in trust-store.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Peter Bittner (peter-bittner)]

This works for me already on vegeta (OTA-9.1), i.e. only a single dialog pops up asking for access to both camera and microphone. At least for the German translation the dialog says it like this (see bug 1553482).

[Olivier Tilloy (osomon)]

@Peter: the prompt you’re seeing is the one to grant access to the web API (MediaDevices.getUserMedia()). The trust store / apparmor operate at an entirely different level, by intercepting direct access to the hardware. You’re probably not seeing the trust store prompts because you have already granted those permissions for the browser.

Note that the web API prompt is per domain (and permissions are not remembered across browsing sessions, that’s a missing feature in oxide, https://blueprints.launchpad.net/oxide/+spec/site-settings), whereas the trust store permissions are per app, so they are going to be prompted only once for the browser the first time a site requests those permissions).

[Olivier Tilloy (osomon)]

> This might not be fixable, if the Web APIs for recording
> video and audio are separate.

Not sure about that, this will require some investigation in oxide.

[Chris Coulson (chrisccoulson)]

Oxide already only requests permission once if a single call is made to getUserMedia requesting both audio and video streams. If a site is requesting them separately, there's not much we can do about that

[Olivier Tilloy (osomon)]

@Chris: I think the problem here is not the browser prompt, but the two separate trust-store prompts.

[Matthew Paul Thomas (mpt)]

Is the request asynchronous? If so, when a site requests one, maybe you could wait two seconds to see if it requests the other. If it does, then request the combined permission.

[Chris Coulson (chrisccoulson)]

Ah, the trust-store prompts. We don't have any control over when they display though, do we?

[Olivier Tilloy (osomon)]

@Chris: no we don’t indeed.

@mpt: can you confirm that the two prompts you’re seeing are issued by the trust store? If so, it might be possible to implement the 2 seconds delay you’re suggesting in comment #7 in trust-store itself.

[Olivier Tilloy (osomon)]

Re-targetting the bug to trust-store, as there is nothing oxide can do there.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthew Paul Thomas (mpt)]

It would be bad for trust-store to aggregate arbitrary permission requests into a single prompt, because that would make it easier for apps to get away with asking for permissions that they shouldn’t have. For example, a maps app that asks for access to your contacts at exactly the same time as it asks for access to your location. As long as the prompts are separate, people are much less likely to allow access to something the app shouldn’t need.

Now, with video and microphone, we’ve made a policy decision that if an app asks for the first it automatically gets the second. I guess trust-store *could* implement this policy just by aggregating just those two prompts itself. That seems a bit brittle, though: it would mean whether you got one prompt or two would depend on how fast the device was running, and whether the requests happened on different threads. More importantly, it would mean native (non-Web) apps would still need two permissions for recording video+audio, when really they should need only one.

So the reason I’m asking whether the Web APIs are asynchronous is that if they are, Oxide could handle this itself. Excuse my comically incorrect pseudocode, but something like:

siteAsksForVideo() {
    if(browserHasEitherPermissionYet) {
         startRecordingVideo(); // zero or one trust-store prompt immediately
    } else {
        try {
            wait(2 seconds);
        } catch (SiteAsksForMicrophone) {
            startRecordingVideoAndMicrophone(); // triggers the combined prompt
        } finally {
            startRecordingVideo(); // triggers the microphone-only prompt
        }
    }
}

siteAsksForMicrophone() {
    if(browserHasEitherPermissionYet) {
         startRecordingMicrophone(); // zero or one trust-store prompt immediately
    } else {
        try {
            wait(2 seconds);
        } catch (SiteAsksForVideo) {
            startRecordingVideoAndMicrophone(); // triggers the combined prompt
        } finally {
            startRecordingMicrophone(); // triggers the microphone-only prompt
        }
    }
}

So the first time you ever used the browser with a site that used video/microphone, it would block for two seconds waiting to see if the site asked for the other one too. Every subsequent time, it would try to access the camera/microphone immediately as normal.

[Olivier Tilloy (osomon)]

Although this makes sense from a UX point of view, this sounds highly impractical to implement: oxide merely implements interfaces exposed by chromium for access to camera/microphone (actually not even for microphone, where it talks to pulseaudio directly, no oxide-specific code there). So it doesn’t actually catch events that request video/mic access.

Additionally, what if the two permissions are being asked with a 3 seconds delay (for any possible reason, including network lag)? We’d be back to the original situation. So where do we draw the line for this kind of situation?

Let’s remember that this bug will affect users only the very first time they use the browser to access a webRTC service (or even possibly never if they used the browser to access microphone and camera separately in the past). It’s a perfectly valid bug, but its importance is probably low.

[Matthew Paul Thomas (mpt)]

If Oxide implements the video part but not the microphone part, and that’s not going to change, I guess this whole discussion is moot. (That seems like odd architecture, though.)

I suggested 2 seconds because that was a reasonable limit to wait. If the two permissions are asked with a 3-second delay, well, you’ll still get two consecutive prompts. But at least we tried.

This is lower-importance because it’s something you’ll only see once, but higher-importance to the extent that it may be part of your first impression of using the browser.

[Olivier Tilloy (osomon)]

The way oxide is architected is for the most part dictated by the chromium content API.

I get your point about trying to gracefully handle the situation, however I don’t see how we can reasonably implement it given the existing constraints.

I don’t want to downplay the importance of the bug, I agree that getting two prompts is an annoyance, and if we can easily avoid it, we should.