Browser activating the front-facing camera: Big Brother or just a bug?
Hi, everyone!
My name is Vadim, I am a tech consultant and a system administrator at RosKomSvoboda.
This post is about a disturbing (in terms of privacy) situation that we have recently encountered.
It could have been in a “A-a-a-a-a-a-a-a-a! Look, Big Brother (Google) is watching us” style, but I will rather try to do some analysis and make some assumptions about why this might have happened.
Here’s what happened: we were approached by one of our readers, who claimed that when he was reading our website (which, ironically, has the BanCam anti-facial recognition campaign banner on a main page), the front-facing camera was activated.
He owns a phone with a sliding front camera. So it slid out right after loading the page as shown on a video.
As you probably have guessed, at first I thought, that despite all the security measures I have taken for the website, we were hacked and “trojanized”.
However, the investigation has shown, that our site was fine.
After discussing the investigation’s findings with my colleagues from RosKomSvoboda, I remembered that I had came across several forum posts before, which were describing how “Trojan” apk-packages were distributed through the ad networks (when opening the forum from an Android phone) (The idea is that a user would install them, thinking that it is the official forum client).
I suggested checking the list of ad trackers which were allowed on that page (the reader uses Firefox and the uBlock addon with it).
A couple of hours of experiments have shown that the camera stops activating only when the google.com domain access in being blocked in the addon’s settings. Around this time the user told us, that the website “kod.ru” was also activating the camera (before that, we considered the problem to be only on our website).
After digging a little deeper, I found out, that requests to google.com are made not only by Google trackers (aka analytics), but even by the YouTube video iframe module on that page. Same thing occurring at kod.ru also fitted this theory. As it turned out, that page had also had an embedded YouTube video in it.
In order to once again check my theory, I Googled a random blog post with a built-in video in it. The camera opened again.
To sum up, what we have discovered: the presence of built-in YouTube video on a page triggers the loading of some scripts from google.com, and those, in turn, trigger the camera.
Okay, let’s keep digging.
Having gone through all the browser debugging tools, I found out, that a highly obfuscated script, which even has an obfuscated name, is loaded via www.google.com domain whenever a user accesses the page. None of the de-obfuscation tools I tried could deal with it.
Considering that it is Google, I can assume that soon this script will disappear, and will be replaced with a different (but equally unreadable) one. So, here’s it’s code, just in case.
A brief overview of the script didn’t show any camera mentions, but you can try to do it yourself.
Let’s now look at it this way:
My own phone has no sliding camera, so I could not see a camera sliding out, but I can connect it via USB and use “adb logcat | grep -i -C5 camer” (I’ve used grep because otherwise there is too much irrelevant info) command. So I did it…
First try: Loading the test sites and… nothing!
Starting to think that this issue is on a client’s side.
In the same time we are discussing the situation in the aforementioned RosKomSvoboda technical chat room. After a while, one of the participants said, that mobile browsers can sometimes be tricky: they don’t always ask for a global camera access permissions, because if they know there is none they may not ask for them!
I check the application’s settings and see, that Firefox has no camera permission. I turn it on, check once again, and see a bunch of camera related info popping up in the console like that:
Gotcha! A camera request!
Moreover, right after the “get device info” line there is an explicit opening of the camera device:
12–12 17:10:14.734 751 6924 I QCamera : <HAL><INFO> int qcamera::QCamera2Factory::cameraDeviceOpen(int, struct hw_device_t **): 405: Open camera id 0 API version 256
I check it once again with Chrome, and everything looks the same: if you take away the camera permission — nothing is in the log, and if you allow the app to access the camera — same logs appear.
Turns out that:
а) problem is not local
b) problem is not browser-specific.
What is interesting about that, is the fact that none of these browsers have ever requested a camera permission for any of the sites that participated in the test (and, however, for YouTube and google.com — too).
Taking all this discoveries into consideration I came up with two versions:
1) Either Big Brother is really watching us or
2) that oddly obfuscated script from Google triggers Camera API in browsers in order to fingerprint the user, but avoids accessing camera directly. That’s why there is no permission request popping up (however, if you look at the video at the beginning of the article closely, you can see how an LED blinks between opening and closing the camera, which raises certain concerns).
Browser’s logic here is simple: When initializing the Camera API, if there is no camera permission — do not do anything (do not even ask for it until there is a real necessity) and if there is one — initialize the cameras and check what kind of modules are there and what are they capable of (might be the reason why the camera slides out).
The user’s phone vendor, as it seems, programmed the camera software simply: whenever the camera is accessed — it slides out.
Afterall, turns out the issue is not as serious, as it seemed to be in the beginning and I’d like to believe that no photos are taken (anyway I’m not qualified enough neither to prove nor disprove that, maybe one of you, the readers, could do that).
However, the very fact that opening any webpage that has an embedded YouTube video iframe in it leads to a camera request (and even some communication with the module) is pretty sad and disturbing in terms of privacy and I think it’s worth the community’s attention.
What is your opinion?
Russian version: https://habr.com/ru/company/roskomsvoboda/blog/480056/
