Cisco's Webex app phoned home audio telemetry even when muted Boffins at two US universities have found that muting popular native video-conferencing apps fails to disable device microphones – and that these apps have the ability to access audio data when muted, or actually do so. The research is described in a paper titled, "Are You Really Muted?: A Privacy Analysis of Mute Buttons in …
Camera & microphone built in to your device? Assume it's always on, always broadcasting, & never ever ever do/say anything you don't want used against you in court.
However, if you buy separate, individual webcam & microphone, connect them to a USB hub, then the hub to your device, you can make absolutely sure it's no longer able to listen/watch/record you by the simple act of unplugging the connecting cable.
But hey, what do I know, I'm just the resident Paranoid that "likes to be difficult". =-j
-> Cisco told The Register that it altered Webex after the researchers got in touch so that it no longer transmits microphone telemetry data.
Caught in the act. It's a bit like a burglar who says he will burgle no more when he has been caught burgling. Hmmm. Not very convincing.
I've never trusted cameras on computers. The physical block is the only way to stop it for sure. In my case I use a slither of opaque paper. The microphone is a different matter with no obvious non-intrusive (to men) means of stopping it.
On MacOS you can install Oversight which gives you an extra alert over and above the screen dot that all Apple devices now share when audio and/or video is live (which, of course, then relies on Apple to make that happen). It's how I discovered that Boom 3D's audio handling sucks - I now use SoundSource which is so much better that it ought to be a standard install on any Mac.
I have been using WebRTC based video conferencing for quite some time. We set up our own server, and that's so much more universal (and massively cheaper) that anything else just seems a waste of money. As for the free stuff, the way Teams works on Windows is terrible. Apart from the fact that it loads by default (reminder to myself: find the registry switch that kills that off) its UI is flat out terrible. And it's MS, so no doubt it's leaking telemetry from there too.
This post has been deleted by its author
A BIOS is a piece of binary-only firmware designed from first principles to defeat any attempt to observe or understand what it does and how it works. They are also notoriously buggy even if not malicious. If you don't trust a soft physical switch or a software button or configuration setting (and you shouldn't), there is absolutely no reason for you to trust a BIOS.
For normal people and most purposes, unplugging a power+data cable and turning off audio/video using an open source OS tool is an acceptable combination, reasonably secure against casual and opportunistic threats. Opaque tape or a lens cap is still a good solution for cameras. A mechanical disconnect switch (sliders or toggles, never a momentary switch of any kind) is a reasonable alternative if disconnecting the device is impossible, but they are rarely offered on recent gear. A determined and knowledgeable attacker can defeat these measures with ease, especially if physical security is poor, so high-value and high-visibility targets need to mitigate several additional risks. Requirements for protecting "state secrets" or "classified information" are much stricter still. Relying on software, including soft switches built into devices, offers little to no security unless you have carefully audited the entire body of work and verified its proper installation. In general, BIOSes, proprietary OSs, and proprietary device firmware cannot provide any meaningful security; they are at best tertiary defense in depth options. I generally assume they are malicious; it's often true and in any event nearly impossible to disprove.
And that is a useful feature, which you must give up if you want to have the app disconnect from the microphone completely while you're muted.
Perhaps a good compromise would be an in between setting where the microphone only collects information on volume levels at one second intervals. When you mute it puts it into that mode, so it can tell when you're trying to talk while muted and can put up a notice on the screen but it only knows how noisy you are being while remaining unable to determine what you are saying or doing.
Do it the way my uni did their radiation center. A big green light on the roof was clearly-visible in all directions. If the the security alarm was triggered, the light went out, foot patrolmen would see this, and call HQ, which would scramble a squad to investigate. False alarms due to the bulb burning out were minimized by changing the bulb well in advance of its maximum rated life.
As far as the LED burning out, PCs and laptops ought to have a test switch (or BIOS routine) which lights up every LED and slowly blinks them on and off a couple times.
For "A" turning the microphone on and off is the easy and effective way to test the LED so the "risk" is pretty much limited to the gap between the very unlikely event of a not over driven LED failing and using the microphone, and only then if the microphone was turned on for this period.
With "B" that is a case of the manufacturer going from a good design to a bad one. Proper design is still the solution.
I was wondering the mic is still active, its because it can flash up your muted. Which is fine if the app does not send out any data when muted. It seems all but cisco behave that way only cisco send out data when muted.
I can understand why an app/program does not switch of the mic like the OS does. Because if it did it is switch it off for everything running on the computer.
If did that when you mute you mute every app and when you unmute you unmute every app
I'm so sure that Cisco is glad someone figured out that they were spying on them. Odds are they were selling this data back to customers or even third parties. Unless it was being sent to /dev/null or an equivalent, it's kind of hard not to notice that you're collecting probably terabytes of info on everyone who has WebEx open during the day. It wouldn't take long before some admin had to deal with a full drive, or a routine storage audit came up with massive amounts of data being stored in one place. It's just not plausible to me that they didn't have any clue about this. So while I can accept that it may have started out as a debugging feature, I can't get to accepting that it wasn't co-opted by some sleazy manager.
Aliens because they are always spying on people.
While it's possible they are doing that (I don't trust them either, and I wouldn't say you are wrong), it would not be my first guess. There is something in between sending bits straight to /dev/null and storing trillions of them on persistent media: acting on them while the communication channel is in use. The most likely reason for something like this would be part of a feedback system to adjust levels. The data wouldn't be stored at all other than in the server's memory while it's being used for that purpose. It's possible that whoever implemented this simply never bothered to gate it on whether the participant is muted.
That said, trust must be earned and Cisco certainly haven't. If you needed one more reason not to use Webex (did you really?!), hopefully this was it. Really it's their disinterested mealy-mouthed corporatespeak response that's infuriating; this is easy to understand and accept as a bug -- which I believe it very likely is -- so own up to it, add the 2 lines of code needed to stop sending these packets from muted participants, and get on with life. Insisting that it's not a problem when it clearly is SIMPLY MUST STOP.
As someone who cares about privacy and security more than most. The outraged response to this article is nonsense, and the article itself is overly sensationalist. This is not scary, and nobody has been caught with their pants down. Here are some facts from the mouth of a seasoned software engineer who has worked separately on audio/video platforms, and on securing systems.
Firstly, software controls are weak and they probably always will be, hardware controls are hard to do right and customers generally won't notice or appreciate them - but certainly care about differences in cost. On that basis telling the OS "pretty please stop the webcam/microphone" is akin to closing your eyes and hoping for the best, it can be a fairly sensible thing to do when you no longer need the audio/video stream but frankly it does little for the users privacy. So on that point, whether or not the software uses the OS controls or not is fairly immaterial, especially if customers can't or don't check whether the OS thinks the hardware is in use or not. It really isn't a meaningful security or privacy control. The OS shills will say "we put X privacy controls in our product, use us" but the impact is minimal, they primarily serve as virtue signalling and only swat away the most basic and unsophisticated of attacks - the kind of attack you wouldn't see pushed through a VCA unless executed by an actor with far greater skill who could easily do something more sophisticated. These OS-level software controls are there to make you feel good and safe. You should not be relying on them for anything serious.
Secondly, and this is most important, it is entirely normal for a VCA to be listening for audio while you're muted. Most VCAs these days need your audio feed to be able to inform you when you're trying to talk while muted. Everyone's been in those meetings where Dave is on video chatting away with his mic disabled. We all know this is a problem, and the VCAs have a solution. They need to listen for increases in amplitude, and they may use local ML models to attempt voice detection to avoid false-positives. This is a feature, by design, for your benefit. Whether VCAs should give an option to disable it for power users is an open question but let's not pretend this is some revelation justifying whistle-blowing. It isn't.
Lastly lets touch on that issue about the Cisco telemetry. This is also blown out of proportion. Telemetry exists to help business analytics teams understand how customers are using their products. Telemetry can be anything from "I still have access to the mic, it hasn't been physically disconnected" right through to "the user shouts a lot, and appears to have problems with 2 dogs barking which might make it harder to understand him when un-muted". Telemetry is NOT "we are recording your audio and sending it to the bad guys". Unless you've opted out of the telemetry or we actually know that there is something excess in there (Google has been known to fall foul of this, for example) there's not much use getting upset about it. Not all telemetry is bad, it's merely another tool in the standard software engineering arsenal.
**mic drop** I'm out
"the user shouts a lot, and appears to have problems with 2 dogs barking which might make it harder to understand him when un-muted".
And:
Telemetry is NOT "we are recording your audio and sending it to the bad guys".
That Mitchell and Webb Look - Are we the baddies?.mp4
Holding recordings of conferences to find out if it's picking up dogs barking is a no no. Servers can be owned, recordings can be downloaded by blackhats and security agencies. Cisco are just going to do it the old fashioned way and eat their own dogfood, and that way they'll have more control over recording conditions anyway (who knows why it's picking up dogs barking in the background in random stored recordings, perhaps the caller works in an animal sanctuary and it's working as expected).
Enjoyed the mitchell and webb reference :D so you get a +1 from me, even though I don't fully agree with your stance. Regarding your quotes, my point stands as the two parts you quoted aren't mutually exclusive. From "holding" I assume you're implying the data is going to Cisco servers and then being analysed. I suspect that is a big part of your concern there. Certainly possible, but actually really expensive when you can get end-users to pay for that processing power, bandwidth, and storage (probably in-memory, so let's assume I'm talking memory). There's a big push towards edge processing to avoid the need for cloud compute. Having ML run on the customer hardware and send a summary of the findings to the cloud significantly reduces operational costs. So on that note, the question then becomes: is it a big no-no for Cisco (or whoever) to be collecting that telemetry? Without any further details, I think it's fair to say: Perhaps. To answer that question we need to know what the telemetry actually contains. You can certainly be opposed to telemetry in general on privacy grounds, that's entirely reasonable, I don't like it much either - but it's also pervasive and standard practice, so difficult to get overly offended about specific instances of this when collecting and sending basic usage logs (which is all telemetry means) is essentially ubiquitous.
To make sure I wasn't barking up the wrong tree with my rather opinionated post I had a look at the actual paper. You can look at the PDF yourself, they believe the telemetry contained the min, mean, and max audio levels collected over a 1 minute period, which is related to the automatic gain control (the way the VCA automatically adjusts it's volume). For an analogy, this is like taking an entire month of rainfall forecast and giving the min, mean, and max rainfall across the entire period. There simply isn't enough data to say how much it rained on a given day, and equivalently there isn't enough data in that telemetry to reconstruct a conversation or tell what is there in the room. From that you can basically determine roughly how loud the environment is, perhaps identify if there is something loud in the room from one moment to the next (which is potentially correlated with when the user is there), and tell if you might be in an anechoic chamber. So if we think about this again from a privacy perspective, what we have is audio-derived data which is insufficient to reconstruct any dialogue or to determine what is in the environment. The adversary (Cisco, or someone breaking into their systems) could basically determine that you are being very quiet, very loud, or very normal volume. I might care about that if I was worried someone might be able to tell if I'm home or out of the house, but who connects to a video conference and then leaves the house? If you're connected to the conference, THAT is the signal that you're home, trying to infer something from coarse-grained audio levels is nonsense.
TL;DR: they aren't sending your conversation, they are sending a value on a scale from "it was very quite in the last minute" to "something was loud in the last minute". If there was enough data in that to reconstruct a conversation think how many MP3s we'd have been able to fit on a floppy disk! Unfortunately it isn't so.
Happy to discuss further.
Very sweet of you to reply. I've never worked on anything as boring as a VCA but it's nice that you read what I wrote even if you think I work for Mr Bad. Frankly the Cisco webex software is shite compared to the rest of the market anyway. You're better off with Skype for Business or whatever they are calling it these days. Anyway, rather than assuming the worst just ask some software engineer friends of yours if collecting logs and sending them to a server is normal. Then ask how they would solve the problem of "Dave you're muted!" without .. checking if he's trying to talk while muted, and then warning him. This isn't rocket surgery.
To make sure I wasn't barking up the wrong tree with my rather opinionated post I had a look at the actual paper. You can look at the PDF yourself, they believe the telemetry contained the min, mean, and max audio levels collected over a 1 minute period, which is related to the automatic gain control (the way the VCA automatically adjusts it's volume). For an analogy, this is like taking an entire month of rainfall forecast and giving the min, mean, and max rainfall across the entire period. There simply isn't enough data to say how much it rained on a given day, and equivalently there isn't enough data in that telemetry to reconstruct a conversation or tell what is there in the room. From that you can basically determine roughly how loud the environment is, perhaps identify if there is something loud in the room from one moment to the next (which is potentially correlated with when the user is there), and tell if you might be in an anechoic chamber. So if we think about this again from a privacy perspective, what we have is audio-derived data which is insufficient to reconstruct any dialogue or to determine what is in the environment. The adversary (Cisco, or someone breaking into their systems) could basically determine that you are being very quiet, very loud, or very normal volume. I might care about that if I was worried someone might be able to tell if I'm home or out of the house, but who connects to a video conference and then leaves the house? If you're connected to the conference, THAT is the signal that you're home, trying to infer something from coarse-grained audio levels is nonsense.
I assume you still aren't convinced but I'll die on this hill. You can ask me anything non-personal about this topic. Bring it.
For my working from home, I have a Laptop (which is now rarely used) and a PC. The laptop is a Mac and does have a webcam and Mike, but is now rarely powered up in the day.
The Pc does not have a webcam (and I’ve told my boss I will not have one as the pc is in my bedroom). I do have a plug in headset for it which is not plugged in unless needed.
I should make clear that both the PC and Mac are my own devices. While I am happy to follow any requirement required for remote access to work machines, I have the final say as to what hardware and software is installed.
Are we looking at this the wrong way?
Where is the firewall in all this?
Does the audio telemetry just go over a standard port?
I’m still working with my windows 7 PC which I hand built for Windows 2000 (laughing emoji here) . So I’m sure it doesn’t have a microphone or Webcam. And NIST recommendation hardening, behind two firewalls. (Smug emoji here.)
And all to no avail because I’m writing this on an iPhone (doh! emoji here).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
