Closed Bug 1578073 Opened 1 year ago Closed 8 months ago

Camera being accessed even though website doesn't have permission to do so

Categories

(Core :: WebRTC, defect, P2)

All
Android
defect

Tracking

()

RESOLVED FIXED
mozilla75
Tracking Status
firefox-esr68 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- fixed

People

(Reporter: gardar, Assigned: dminor)

References

(Regression)

Details

(Keywords: regression)

Attachments

(14 files)

5.59 KB, text/plain
Details
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Android 9; Mobile; rv:69.0) Gecko/69.0 Firefox/69.0

Steps to reproduce:

When accessing certain websites that I haven't opened before the front facing pop-up camera on my OnePlus 7 pro pops up for a brief moment and then down again. Visiting said websites again does not seem to trigger the event, but after clearing cache it does.
I'm assuming perhaps the website is trying to access my camera and Firefox allows it for a brief moment but then figeres I haven't given the website permission to do so and closes the camera again.
I'm not sure if a actual picture is being taken but this is quite worrisome as if I'd have a front facing camera that's not motorized I probably would not have noticed this.

I'm on Firefox Preview
1.3.1 (Build #12341950)
📦: 8.0.0, 78354bc12
🦎: 69.0-20190812090043

but I see reports on Reddit from other users as well that seem to be using the regular Firefox on Android.

Actual results:

Front facing camera is launched without user permission

Expected results:

The camera should not be launched without the users consent.

OS: Unspecified → Android
Product: Firefox for Android → GeckoView
Hardware: Unspecified → All

This looks like a problem in our MediaDevices.enumerateDevices() not recognizing this device's pop-up cam. This bug might be a regression from MediaDevices.enumerateDevices() bug 1450762, which stopped prompting users for device permissions when enumerating devices.

Moving this bug from GeckoView's Bugzilla component to Core::WebRTC since this is related to gUM.

Blocks: 1450762
Component: General → WebRTC
Product: GeckoView → Core

Hi, Snorp,
According to comment2, do you mind to take a look for this bug?

Flags: needinfo?(snorp)
Priority: -- → P2

This utility page [1] can help to investigate if the MediaDevices.enumerateDevices() is the culprit. Can anyone on a OnePlus 7 try it?

For testing purposes, please revoke the camera permission, and use "Enumerate Devices" button. In that case, no permission should be requested and you should have one input device. Then provide the camera permission, in android level, for Nightly, and use the "Enumerate Devices" button again. You should see listed all your camera and audio input devices (3 devices in my case, front cam, back cam, and the mic). Please let us know what you see in every case, with and without the camera permission. Does the cam device pop up similar to the report from above?

[1] https://achronop.github.io/samples/enumerateDevices.html

Reporter, can you try the instructions in comment #4 and let us know how it goes?

Flags: needinfo?(snorp) → needinfo?(gardar)

(In reply to Alex Chronopoulos [:achronop] from comment #4)

This utility page [1] can help to investigate if the MediaDevices.enumerateDevices() is the culprit. Can anyone on a OnePlus 7 try it?

For testing purposes, please revoke the camera permission, and use "Enumerate Devices" button. In that case, no permission should be requested and you should have one input device. Then provide the camera permission, in android level, for Nightly, and use the "Enumerate Devices" button again. You should see listed all your camera and audio input devices (3 devices in my case, front cam, back cam, and the mic). Please let us know what you see in every case, with and without the camera permission. Does the cam device pop up similar to the report from above?

[1] https://achronop.github.io/samples/enumerateDevices.html

Seems to behave the same in both cases in Firefox preview, both in a private tab and a 'regular' one, the camera doesn't pop up but it does detect three devices..
It isn't until I revoke the permissions from the application itself on the Android level that I just get one device

settings > site permissions > camera = blocked
Camera won't pop up
3 devices.
videoinput: id=QwVwry/Y7q4Lb1Z6/2LyfwiLljMQnAkM9NaSg6Sjypw= group=D9dMf4FaR5Pemckn24CHYtixH1rdJ3EHyEBzPOu4B/I=
videoinput: id=9o1nTAOKw3xKTbk25VvAjPq0jCKBdNne5GCsBWbtIeo= group=kDWv5Cw+2LPb20LcZIwD1JINsN2NGxE2T6s4ur3DyvA=
audioinput: id=UTG15zLBWnhavJAmosBL9iHVHK2J5oDo82oPdR5qxxs= group=7W9hZz83amQsAt2deQTxyjI90w/vZiFmxX0ZGv9Ctgk=

settings > site permissions > camera > ask to allow
Camera won't pop up
3 devices.
videoinput: id=QwVwry/Y7q4Lb1Z6/2LyfwiLljMQnAkM9NaSg6Sjypw= group=YVTuos1t5CeeqwYgC4vYuh0tGhthgLhxm1uerYCqPNg=
videoinput: id=9o1nTAOKw3xKTbk25VvAjPq0jCKBdNne5GCsBWbtIeo= group=2eHcBn4FD2/fXBoa+CzS04nnwQLgqhyDlpJe1Fw0gqM=
audioinput: id=UTG15zLBWnhavJAmosBL9iHVHK2J5oDo82oPdR5qxxs= group=N3Juq6zgmroJcpVGXac+L1wNitIoLT3YkbSSnRckj1c=

Flags: needinfo?(gardar)
Duplicate of this bug: 1588280
Duplicate of this bug: 1588689

Same here with a Mi 9T, MIUI 11 (Android 9) an firefox updated.
Steps to reproduce:

  • Finalize firefox process.
  • Start firefox
  • Access elpais.com page (a very popular news page in spain)

Front camera works fine witch WebRTC in videoconferencing pages but that pages doesn't uses camera as far as I know and doesn't asks for permission. It's very disturbing because you don't know if it's an unauthorized use.

See Also: → 1598954

i have found out, with auditd, on debian 10 (current stable), that whenever youtube is opened, video capture is accessed by firefox. i will attach part of auditd log. here is no site listed in firefox's list of sites permitted to access camera. firefox version 68.2.0esr (32-bit).

Attached file part of auditd log

and camera led has flashed 1 time, nearly half an hour ago, while youtube is opened, in debian 10 installed yesterday. auditd was not installed yet. this happened not in the first opening of youtube. (but i opened 16 youtube urls, as i see in firefox history, since new installation). (only 1 other tab was opened, when camera led flased, where local html was opened).

also camera led flashed in previous installation of debian 10 while i was browsing, and apt upgrade was running (according to logs; but, as i remember, it flashed after apt upgrade finished). for that, i investigated this with auditd (and have reported here what i have found). and reinstalled os (yesterday). (and now it again flashed once).

then, after several hours, led flashed again, and youtube was open. but now i have seen that led flashes when waking laptop up from sleep, while youtube was not open. (but ff was open). (that led flashing may not be related with youtube, and even nor with firefox.) i again installed auditd, put /dev/video0 and /dev/video1 to log, then put laptop to sleep and woke it up, led flashed, but i see nothing related to camera nor to firefox in auditd logs. (so, this method of using auditd is not perfect).

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

i have just now tried https://achronop.github.io/samples/enumerateDevices.html , and first pressing "Enumerate Devices!" caused led flash, but subsequent presses did not. output message of all presses are same. (4 devices. videoinput: id=oKP/wwi..... etc). i did not press any other button. but i tried that page several days ago, and in that time i did not led flash. debian 10, xfce.

edit: and in that time i did not see led flash

Duplicate of this bug: 1598954

I've verified both youtube and https://www.androidauthority.com/best-reddit-apps-android-734043/ call enumerateDevices() (and not getUserMedia) so I think that's the culprit call. Comment 15 also matches this. - Gardar, if you could try comment 6 again but from a clean profile and in a private window I'd appreciate it.

We know it's become common for trackers to call enumerateDevices() to better fingerprint people (YouTube may have non-tracking reasons. see bug 1598954 comment 3).

A couple of notes when reproing:

  1. If you're in nightly, turn off dom.security.featurePolicy.enabled first since I found calls coming in iframes, and we block those by default in nightly.
  2. A fresh launch and opening and using a new private window increases the chance the site will make the call.
  3. getUserMedia similarly enumerates devices right before it prompts the user, which explains the repro steps on reddit from comment 1:

Interesting. Can you try visiting this page: https://webrtc.github.io/samples/src/content/getusermedia/gum/

Hey there! When I click open camera, the tray does slide open and closes right away, then I can select which camera I wish to use, and once I select front facing camera, there is does open completely

Based on the Firefox 66 fix to remove the android OS prompt on enumeration in bug 1450762, I see we simply skip prompting and proceed with enumeration. Also, as I recall, our Android backend for camera is a bit outdated. Dan, what's the chance this is a flaw in the upstream code?

If someone who is able to reliably reproduce this could test if the problem exists in Firefox 65 that might be helpful, thanks!

Flags: needinfo?(dminor)

James, thoughts on what could be going wrong? Also, do we know anyone at Mozilla who might have a OnePlus 7 pro?

Flags: needinfo?(snorp)

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #19)

James, thoughts on what could be going wrong? Also, do we know anyone at Mozilla who might have a OnePlus 7 pro?

Not sure which mobile phone Maja has exactly, but she also noticed that problem.

Flags: needinfo?(mjzffr)

Yep, I have a OnePlus 7 pro. Pressing 'enumerate devices' at https://achronop.github.io/samples/enumerateDevices.html causes the camera to pop up and down. This is on Nightly 191212 06:01 (Build # 13460608, gecko 73) and on Firefox Preview 2.3.0 (Build #13031728, gecko 70)

Is there a convenient way to get an apk of 65?

Flags: needinfo?(mjzffr)

Maja, have you granted the Android camera permission to the app before hitting the button? If so, do you get different behavior if you revoke that permission?

Flags: needinfo?(snorp) → needinfo?(mjzffr)

Yes, before hitting the button in Comment 21, I had granted camera permission to Firefox Preview. When I revoke the permission, the behaviour goes away (the camera no longer pops up).

Flags: needinfo?(mjzffr)

When I've seen this on other websites, the Android camera permission was granted and Firefox was set to "Ask to Allow". However, I never received a prompt from Firefox, the camera just popped up and down on some sites.

OK so clearly something in the device enumeration stuff is causing this. I don't think I even know where the Android camera enumeration stuff lives? Does that come from upstream WebRTC? Nils I think we know enough here that a WebRTC engineer should be able to figure it out, or at least propose a speculative fix.

Flags: needinfo?(drno)

The device enumeration code lives here (media/webrtc/trunk/webrtc/modules/video_capture/android). It does originally come from upstream, but they removed their version of the code in 2015 [1]. Looking at the code it was replaced by (also subsequently removed upstream), they're also opening the camera as part of enumeration [2] which I assume is causing the problem.

Poking around some more, it looks like the camera2 api allows getting the camera characteristics without opening it [3] which is presumably what we want to do. Both [2] and [3] are from 2015 as well, it will take some more digging to find the latest versions of that code from before its removal.

As disturbing as this is from a user perspective, we just open and close the camera immediately, no video capture takes place during enumeration.

I'm probably the person most familiar with this code, so I'll have a look.

[1] https://chromium.googlesource.com/external/webrtc/+/35d1767cc3ae1fd48e8fd01b0b8ed9061734538e
[2] https://chromium.googlesource.com/external/webrtc/+/35d1767cc3ae1fd48e8fd01b0b8ed9061734538e/talk/app/webrtc/java/android/org/webrtc/CameraEnumerator.java#66
[3] https://chromium.googlesource.com/external/webrtc/+/35d1767cc3ae1fd48e8fd01b0b8ed9061734538e/talk/app/webrtc/java/android/org/webrtc/Camera2Enumerator.java

Assignee: nobody → dminor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(drno)
Flags: needinfo?(dminor)
Duplicate of this bug: 1604700

FWIW, I got this message from Android on a Galaxy S9 today. I thought I was only reading a W3C spec, and that was my only tab at that point, so it seems surprising that it would even call enumerateDevices, but hey, who knows.

See Also: → 1592630
Duplicate of this bug: 1609212

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=287641842&revision=ad5e792ea66032df8c074505643fd38eb798fd7a
The pixel tests just seem broken, try run without my changes here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ee7789e16f60833a6d6f4c050b97ed491f2d95b0&selectedJob=287727855. I'll dig some more and see if there a way to run more android testing through try.

From Bug 1613690, it sounds like our test coverage on Android is not the best at the moment. I have run the mochitests on a local emulator.

This is an import of the Android camera code as of upstream revision
26762d0425ffd15af9ddc3ae669373668827ea00 (Dec 20, 2019). This takes just the
files required to build the camera related classes.

Although originally part of webrtc.org, this code has subsequently been
removed by upstream. Moving it to under dom/media should make it clearer that
this is code that we are maintaining and simplify future upstream merges.

Depends on D61849

Depends on D61852

Depends on D61854

Getting the JNI calls here to work requires a good amount of webrtc.org
machinery. It might be worth setting that up the next time we do an upstream
merge, but for now, it is a lot simpler to just comment out the affected code,
given that we are not interested in collecting this data anyway.

Depends on D61858

Depends on D61860

Must have been an infrastructure problem, android-hw mochitest media tests look fine today: https://treeherder.mozilla.org/#/jobs?repo=try&revision=20a9fb3503133b8f12f6cbd18c1c5d435e03ecca

Pushed by dminor@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/27b45ca46f24
Add newer webrtc.org android camera code; r=ng
https://hg.mozilla.org/integration/autoland/rev/55e2a4c5cab9
Move android video capture code to dom/media/systemservices; r=jib
https://hg.mozilla.org/integration/autoland/rev/2a8e1c02cede
Update build.gradle for new android camera code; r=snorp
https://hg.mozilla.org/integration/autoland/rev/39a853c82a71
Fix warning: [cast] redundant cast to int; r=ng
https://hg.mozilla.org/integration/autoland/rev/2126f6d9bffc
Add android_video_capture to moz.build; r=ng
https://hg.mozilla.org/integration/autoland/rev/8533a03e36ca
Remove android video capture from BUILD.gn; r=ng
https://hg.mozilla.org/integration/autoland/rev/b91603fdd9de
Update gn generated json files; r=ng
https://hg.mozilla.org/integration/autoland/rev/0c214e8034bb
Update generated video capture moz.build file; r=ng
https://hg.mozilla.org/integration/autoland/rev/381836e3bad0
Fix include paths for android video capture; r=ng
https://hg.mozilla.org/integration/autoland/rev/8aae0721f09c
Use CameraEnumerator in createDeviceList; r=ng
https://hg.mozilla.org/integration/autoland/rev/e361b04a8502
Remove native calls in Histogram.java; r=ng
https://hg.mozilla.org/integration/autoland/rev/20e979be216b
Use updated camera capture code; r=ng

Unfortunately, the lint job didn't run on my most recent try push, or I would have caught this earlier: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7e603e551e39903e01bb1ca95c30983fa6d05016

As far as I know, android.permission.CAMERA is required for the current code to work, so I'm not sure why the newly added code is tripping this up. James, do you have any suggestions for me? Thanks!

Flags: needinfo?(dminor) → needinfo?(snorp)
Flags: needinfo?(snorp)

Yeah, I think suppressing the lint should be fine.

Pushed by dminor@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/57c916d83d28
Add newer webrtc.org android camera code; r=ng
https://hg.mozilla.org/integration/autoland/rev/46c21affcbc1
Move android video capture code to dom/media/systemservices; r=jib
https://hg.mozilla.org/integration/autoland/rev/84e6f3eacce7
Update build.gradle for new android camera code; r=snorp
https://hg.mozilla.org/integration/autoland/rev/82877c8a8640
Fix warning: [cast] redundant cast to int; r=ng
https://hg.mozilla.org/integration/autoland/rev/739b9ea4a298
Add android_video_capture to moz.build; r=ng
https://hg.mozilla.org/integration/autoland/rev/d10239f2caab
Remove android video capture from BUILD.gn; r=ng
https://hg.mozilla.org/integration/autoland/rev/70a0f916f11a
Update gn generated json files; r=ng
https://hg.mozilla.org/integration/autoland/rev/7d9c51a90036
Update generated video capture moz.build file; r=ng
https://hg.mozilla.org/integration/autoland/rev/2796c6521f19
Fix include paths for android video capture; r=ng
https://hg.mozilla.org/integration/autoland/rev/8231314b45da
Use CameraEnumerator in createDeviceList; r=ng
https://hg.mozilla.org/integration/autoland/rev/7a9b07dec9f9
Remove native calls in Histogram.java; r=ng
https://hg.mozilla.org/integration/autoland/rev/9a2171028b31
Use updated camera capture code; r=ng
https://hg.mozilla.org/integration/autoland/rev/722c4a6d1dad
Suppress MissingPermission lint in Camera2Session; r=snorp

Hi Maja,

Now that this has landed, I was wondering if you could retest this on your phone to see if it fixes the problem?

The updated camera code should avoid opening the phone during device enumeration, but without an affected device, I can't be certain if it will fix the problem we're seeing. With Fenix, I'm not sure when this will hit a Nightly build, you might have to grab an apk for geckoview_example from Autoland (https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=288728336&revision=722c4a6d1dad867f9ce47fe96d71b5dedb4cbaa8) and test that.

Thanks!

Flags: needinfo?(mjzffr)

(In reply to Maja Frydrychowicz :maja_zf (UTC-4) (maja@mozilla.com) from comment #23)

Yes, before hitting the button in Comment 21, I had granted camera permission to Firefox Preview. When I revoke the permission, the behaviour goes away (the camera no longer pops up).

In Nightly 200310 06:01, this seems to work as expected: no camera pops up with device enumeration even when the Fenix app has camera permission.

Flags: needinfo?(mjzffr)

(In reply to Maja Frydrychowicz :maja_zf (UTC-4) (maja@mozilla.com) from comment #54)

(In reply to Maja Frydrychowicz :maja_zf (UTC-4) (maja@mozilla.com) from comment #23)

Yes, before hitting the button in Comment 21, I had granted camera permission to Firefox Preview. When I revoke the permission, the behaviour goes away (the camera no longer pops up).

In Nightly 200310 06:01, this seems to work as expected: no camera pops up with device enumeration even when the Fenix app has camera permission.

Thank you for taking the time to test this!

Regressions: 1619709
No longer blocks: 1450762
Regressed by: 1450762
No longer depends on: 1646904
You need to log in before you can comment on or make changes to this bug.