Access to microphone is allowed even when user denies access to "video and microphone"

[Peter Bittner]

The plain web browser can access the microphone when you deny the permission to access camera and microphone.

Tested / discovered with bq Aquaris E5 Ubuntu Edition, OTA-9.1 (vegeta, latest stable as of today).

How to Reproduce
----------------

1.) Go to e.g. https://appear.in/test-drive on your Ubuntu phone (default web browser app)
2.) When prompted for "Allow this domain access the camera and microphone" choose "No"
3.) Click away the chat window (touch the down-arrow at right lower corner)
4.) Touch the screen to dismiss the "help text" ("Video off" is shown prominently)
5.) Touch the screen again to show the video controls, touch on the "microphone" icon; "Audio only" is shown on the screen
6.) Log in to the same URL from a PC (or another phone) to verify audio works

Other Details
-------------

Discussion on the mailing list:
https://lists.launchpad.net/ubuntu-phone/msg18659.html

[Jamie Strandboge (jdstrand)]

From the ubuntu-phone mailing list (Subject: [Ubuntu-phone] Adjusting camera settings in a Web app):

"On Sat, 2016-03-05 at 11:54 +0100, Peter Bittner wrote:
>
> Side note: Interestingly, access to the microphone has always been
> possible, even without the "microphone" policy_group (I noticed this
> in version 0.1 of my web app [4]). Not sure whether this is a bug or
> a
> feature.

This is possibly a bug. pulseaudio is supposed to have trust-store integration these days, however, I'm not sure if camera is granted if that implies microphone. I see you filed the bug here:

https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1553482

I'll add a comment to that bug."

[Jamie Strandboge (jdstrand)]

Olivier and/or Chris-- if it isn't happening already, we need to make sure that access to the camera and/or microphone is happening out-of-process with the browser, which I believe should just happen automatically when connecting to media-hub and pulseaudio. If we are doing something else, that may be the cause of this bug.

[Olivier Tilloy (osomon)]

The dialog that Peter mentions at step 2 of the bug description is oxide asking for permission to access the camera/microphone, it’s not an apparmor/trust-store thing. If the user denies access, oxide shouldn’t even try to access the camera/microphone (regardless of trust-store permissions), so that sounds like a bug in oxide. Maybe something that changed recently in chromium?

[Matthew Paul Thomas (mpt)]

If I go to https://appear.in/test-drive and tap “Allow”, I then get two trust-store dialogs: one saying that “Browser wants to record audio”, and then a few seconds later, one *on top* saying “Browser wants to access CameraService”.

An index to these bugs:
(A) the oxide prompt seems confusingly/redundantly similar to the trust-store one: bug 1553713
(B) the browser can somehow use the microphone without trust-store granting it permission: this bug report, apparently (but then why doesn’t it belong to trust-store or pulseaudio?)
(C) either trust-store does not provide the combined “record video” permission yet, bug 1554142, or the browser does not use it when it should, bug 1554149
(D) the camera permission is called “access CameraService” rather than something in English: bug 1554138
(E) when an app asks for multiple permissions at once, trust-store stacks them: not reported yet

[Peter Bittner (peter-bittner)]

MPT, please state which channel you are using. On vegeta OTA-9.1 there is only a single dialog that pops up.

[Peter Bittner (peter-bittner)]

MPT, apart from bug (A) I also cannot confirm bug (D), at least for the German translation. On my device the dialog says:

"Dieser Domain den Zugriff
 zur Kamera und Mikrofo...

      https://appear.in/

    [ Ja ] [ Nein ]"

Note the ellipsis, which truncates the lengthy German translation. (Missing part of the text is "Mikrofon geben?")
This is both fine for me though, works perfectly fine in the web-browser app (not in the webapp-container though, which does not show any dialog, even with "camera" in .apparmour).

[Peter Bittner (peter-bittner)]

Same small glitch with the ellipsis (long text) in the dialog with English, btw:

"Allow this domain to
 access your camera an...

    https://appear.in/

 [ Yes ] [ No ]"

Missing text is obviously "and microphone?"

[Olivier Tilloy (osomon)]

> (B) the browser can somehow use the microphone without trust-store
> granting it permission: this bug report, apparently (but then why
> doesn’t it belong to trust-store or pulseaudio?)

Regardless of apparmor policies, if the user denied access to audio/video, oxide shouldn’t even try to access the hardware. Obviously if it does and succeeds in doing so, there’s also a bug lower down the stack. Both issues need to be investigated and fixed (can be done separately).

[Olivier Tilloy (osomon)]

> Same small glitch with the ellipsis (long text) in the dialog with
> English, btw:

That’s because they are not the same prompts. One is the browser prompt (the one with truncated text), the other one is from the trust store.

As mpt pointed out in bug #1553713, the mere fact that the browser uses a dialog to prompt for permissions is confusing and not optimal, a non-modal ribbon at the top/bottom of the webview would be more suited.

In any case, thanks for pointing out this truncation issue, I’ve filed bug #1554220 to track it separately.

[Chris Coulson (chrisccoulson)]

I'm not reproducing the issue described in the description here. When I dismiss the permission request in the browser, microphone access is blocked and I can't hear audio via another machine.

We have unit tests to verify that denying permission requests causes getUserMedia to fail, and those continue to work too.

[Peter Bittner (peter-bittner)]

@chrisccoulson can you please specify which channel you are testing, describe the environment and test device.

I'm on a bq Aquaris E5 Ubuntu Edition with OS build details:
- OTA-9.1
- 20160217.1
- Ubuntu 15.04 - armhf (20160217--111536)
- 20160108-efc96d8
- VEGETA01A-S23A_BQ_L100EN_2010_160217
- 20160111-926-36--vivid

If you're testing a newer build and features are covered by unit test, awesome!
Then we can fully focus on bug 1554202.

[Olivier Tilloy (osomon)]

Mmm, I tested further, and I think Chris is right. I was initially fooled by the fact that I was hearing some echo in my phone when connecting to the same chat room with my laptop, but it appears that echo came from the laptop’s microphone. When I walked into another room and closed the door, talking in front of the phone’s microphone didn’t produce any echo. Looks like the microphone is not being accessed after all.

I’m tentatively closing that issue now, Peter feel free to re-open if you can bring further evidence that the microphone is being accessed.