"When a user of Shazam’s Mac app turns the app “OFF,” the app actually keeps the microphone on in the background. For the security researcher who discovered that the mic is always on, it's a bug that users should know about."
That's not a bug. It's intentionally deceptive software.
It's a feature. While its song matching is set "off", microphone stays on to pre-buffer. This means faster response when activating Shazam to identify the current song.
"If the mic wasn’t left on, it would take the app longer to both initialize the mic and then start buffering audio"
Leaving aside any privacy concerns, it's reasonable that everybody with this installed loses some battery life leaving the audio hardware powered up all day on the off-chance they might want to tag a song at the very last moment at some point?
It's not like the latency to start an audio stream on the Mac is huge to start with.
This is my problem with this behavior. The reality is that if Shazam is malicious, it can grab data at any time without always grabbing data. Having them turn this off doesn't block them from being evil and grabbing audio when it suits them to do so. It would make it harder to mask the behavior, I guess, but that's a pretty weak guarantee.
On the other hand, this kind of behavior steals real resources from the system. In aggregate, apps that do this can waste noticeable battery and slow the system considerably. I don't want random apps deciding they're "important enough" to always run. It's user hostile even if it's not intended to be.
If that's true, then I don't personally care whether they are constantly capturing audio and discarding it. While that isn't as ideal as, you know, not doing always capturing audio, if it saves half a second when the user decides to capture audio and stops when the app is closed, I can understand that tradeoff.
I don't have Shazam installed on my laptop and honestly can't imagine I ever will, so this is academic for me.
Exactly. The sole purpose of the app is to capture background audio and analyse it. Don't want that? Don't run it. This seems to be a storm in a teacup. We're not talking a Dropbox-like system hijacking here.
Add to that, they're saying they don't send the recordings out except they do send only “digital fingerprint summaries of the audio.” We all know they mean "hashes" which can be reversed, given the correct set of circumstances.
Adding nVidia and AMD GPUs would require us to have nonfree drivers or firmwares so that would be against our philosophy. Also adding proprietary stuff is against our goal of creating secure yet convenient OS (we try to free or create things that people need, not close them down even more).
But honestly, most people won't audit the wiring of their device. I wonder if a more low tech solution is the answer...a cover for cameras and some sort of sound blocking cover/plug for microphone holes.
That's the same argument that's been applied against open source software for decades now.
The reality is you don't need everyone to audit their devices, you only need there to be credible auditors. Better: standards mandates that require isolation of any ambient capture devices.
In the alternative, the ability to flood and overload such circuits might be of interest.
Nope [1] is one pretty slick after-maket hardware 'switch' you can add to your webcam. Of course, some gaffer's tape works just as well, and costs a lot less (but doesn't look as slick). I don't have any such solution for the microphone, though.
[...] some gaffer's tape works just as well, and costs a lot less (but doesn't look as slick). I don't have any such solution for the microphone, though.
The microphone is a hard one. Even if you cover the holes in the casing where the mic is located the sound still travels just fine via the keyboard.
IIRC when a photo came out of Mark Zuckerberg covering his webcam I noticed he covered his mic port with tape as well. He should have checked the volume levels from his mic - it would still pick up everything just fine. In fact I think the tiny mic holes are mostly vestigial.
Or put a dummy plug in the headphone plug ? Such that it would activate the headphone mic without supplying audio. Cutting of all wires from an old plug would do.
Or a mic with its own volume control. This probably works but it could require writing code to test in on a phone, this is why:
My PC doesn't have a mic plug and the headphone one is only out, no in. With two mics (internal and USB) I can switch among them by software. I'm pretty sure I could do that with an analogue mic.
I wonder if an app could do the same on a phone, switching from the outside dummy mic to the internal one. You'll definitely notice that if you're calling somebody, but if the app only listens when no other app is using the mic, then it's easy to record audio most of the time.
I once was videocalling with my macbook on my lap, suddenly I couldn't be heard by the other party: I moved and my leg was covering the microphone hole. Problem is that the mic is still picking up sounds, just very attenuated.
Maybe a solution would be no integrated microphone, a small low profile microphone in the laptop box to be connected through the laptop mic jack.
Is there ever a need for a laptop microphone? I always have a headset or BT if I'm doing FaceTime or a confirm call... Why not just disable the hardware or at the OS level?
Depends on the make/model of computer - current MacBooks use a lot of glue to hold components together, making minor hardware tweaks a bit of a gamble. It's not impossible, just not as hassle-free as it used to be.
> or at the OS level
If your computer has a rootkit then doing it in software is no good.
Actually, we need more modern OSs that allow isolation of priviledges from apps and alike (similar to what iOS does, but desktop), and manually activating things like cameras/mics per-app.
POSIX (and the upper, newer, layers of API) is really starting to show it's age, since it's from a time when "untrusted software" was not that much of a thing.
In part yes, but there are people (me included) who are past the point of trusting the companies that are making most of the software and the hardware we use, OS included. That's why verifiable hardware switches are important.
We also need hardware write-protect in storage media such as USB flash drives. Otherwise any system the USB is inserted into can compromise the USB. You usually think of USB compromising a computer, e.g. Stuxnet, but it can also work in the other direction.
Back in the old days of 1/2" mag tape reels, the rule was "no ring, no write". There was a physical ring that needed to be present before a tape drive would write to a mag tape. This was also relatively failsafe. If the ring fell out or was removed, for any reason at all, the data was guaranteed to be safe.
This same mentality carried over to floppy disks. It was possible to protect media in hardware.
But in the interests of saving money, hardware write protect circuitry is quite passe these days. As are hardware switches of all sorts.
Fun fact about old floppy drives, the write lock didn't actually prevent writes from happening. It was just an indicator. Write prevention was handled by the disk drive which could choose to ignore the write lock.
> And we should be able to check that they really work.
How? Seriously, if you don't trust a hardware switch to work as advertised, then you probably don't trust software correctly to report the state of the hardware; so what would you trust? (I wish that I could say that I think you're being paranoid, but I don't; I just wonder what a zero- or minimal-trust proof of disconnected hardware would look like—short, presumably, of something like a visible air gap that could only be implemented at considerable expense to the portability of modern electronics.)
Do what Edward Snowden does: physically remove the microphone circuitry from your phone, then plug in earbuds if you ever need a microphone to talk on the phone, etc.
I'm guessing he probably didn't buy the new iPhone 7...
Now there's an interesting thought. How much access do the new headphones have to the rest of the device - they're not just a simple analog connection any more. Do they have DMA?
Physics. Their not being an unnoticed second camera/microphones/etc.
If you main concern is that your computer will be used to spy on your physical life, then having verified switches can give you confidence from first principles that it it has no way of observing you (modulo secondary sensors that you did not notice.)
> having verified switches can give you confidence from first principles that it it has no way of observing you
Right, but this is what I meant to ask: how does one verify a switch that has been manufactured by someone else? I suppose that an electrical engineer could check the schematics, but how do you verify that the actual hardware in your device matches the schematics?
Switches are very simple devices. If the switch mechanism is not enclosed, it is easy to look one and see that the input leads are separated by the output leads by an air gap. Of course, a sufficiently motivated attacker could still work around this (by eg, by finding a side channel, or having the plastic of the switch be somewhat conductive). However, these attacks are far more difficult, and far less plausibly deniable.
> Switches are very simple devices. If the switch mechanism is not enclosed, ...
Sarcasm, I hope? I spent an hour this weekend replacing some micro switches in some decrepit robots. These are about 5mm^3, which is pretty tiny, but huge on the scale of a modern phone. They are basically hunks of plastic with a button on one side and six or so leads coming out the other side. No, you can't open them up and see the air gap without destroying them. And yes, they are small enough to easily contain a full CPU, some flash memory, and a few sensors, even though they only really need a few sliding metal and plastic bits.
Sorry if I wasn't being clear. My point is that it is possibly to have switches that are easily verifiable. Most switches that exists are not because there is no motivation to make them so.
Shazam keeping the microphone on at all times on the Mac shouldn't be a surprise considering that it is already well known that Shazam has been keeping the microphone on at all times on the iOS platform.
On the radio today I heard a commercial instruct listeners to "Shazam this ad" to learn more about whatever it was they were selling. That commercial angle for Shazam is fine, but it makes the fact they keep your microphone on feel a little more creepy.
I've seen similar logos pop up during commercials - this seems directly related to that marketing effort. Still, I wonder who would rush to get out their phone and open up Shazam, just to learn more about this product/service? It's not any easier than a Google search. It's basically an audio version of the famous tech flameout "CueCat."
Yeah given the recent spate of ultrasonic trackers, this revelation is not a welcome one. I believe Shazam when they say they're not using the data, but all it takes is one (silent) update to their privacy policy and TOC...
It seems to me that Shazam turns the microphone on as soon as the app in launched on iOS.
Yesterday I wanted to Shazam the second song of an Instagram video playing on my computer. The app was open while the first song was playing and I pressed the record button as soon as the second one started playing. I was really surprised to notice that the song found by Shazam was the first one and not the second.
Why is Pearson so arrogant about this? Shazam doesn't control my device, I do. What's to stop any other software vendor from ignoring the configuration with whatever justification they want to use?
I'm not sure how you can be confident in stating that as fact. I'm not at all. In the US there are many issues with switching carriers, for one example.
You state that you're in control of the device but then say "What's to stop any other software vendor from ignoring the configuration". Ignoring what seems like a contradiction there, I think we would have different definitions for what it means to control your own device.
Shazam doesn't "override configuration". Just quit Shazam and hey presto, no more listening. The on/off setting is the one within Shazam itseld. It's really a "process audio" setting not a "microphone"
setting.
At first I thought, this Oversight app sounds like it could be useful. And then I thought, how do I know this Oversight app isn't spying on me? Ex-NSA author unfortunately isn't something that makes me more confident in the tool. Why am I even worried that someone is spying on me? Oh how I miss blissful ignorance some times.
> And then I thought, how do I know this Oversight app isn't spying on me?
While I agree that you don't know that this app isn't spying on you, surely it doesn't decrease the trustworthiness of your computer? In some sense, it seems to me like centralising all your distrust in a single person: you now have only to trust the author of this piece of software, rather than of every piece of software you use.
My point wasn't so much whether this app spies on me or not, but that this is now a question that has to be asked for all apps – no matter who you are really. It's a sad state of affairs.
I use the iOS Shazam app rather often and always wonder why it takes it so long to launch. Even after it launches, I cannot immediately press the "Shazam" button (this is rather infuriating sometimes). Could initialising the mic really take that long, even on an iPhone?
Try asking Siri what song is playing...she uses Shazam technology to answer and does so in a lot less time than it takes to launch the Shazam app, wait for it to be ready, tap the button, and get a response. (You can switch to the Shazam app from Siri's response if you want.)
initializing any hardware takes some time. Be it the microphone, the speaker, the taptic engine (or the making the phone vibrate at the exact moment), access to location (gps can probably be the longest initialization time), all need some initialization time before they can be used as expected.
> If the mic wasn’t left on, it would take the app longer to both initialize the mic and then start buffering audio
> the mic is kept on “for technical reasons” but “no audio is processed
Beg your pardon? That's two, contradictory statements. You are either buffering the audio or not. If yes, then the "no audio is processed" is very thin truth. If not, then the only time you win it takes for the Mac to switch the mic on, surely that takes a very small fraction of a second...?
Do other "on-demand" voice-activated apps use this same technique?
I know that Google Now, Siri, Amazon Echo, and others respond to commands like "Ok Google [...]". Those devices must necessarily be listening if they're to catch those voice commands, right? Or is there a more clever solution for recognizing predetermined phrases?
Phones usually have fixed-function low-power hardware dedicated to listening ambiently for phrases like "Ok Google." So yes, it is technically always on, but no, it's not understanding what you're saying or uploading it to the cloud.
And this is why hardware devices must not have onboard microphones, but rather rely on jacked-in devices which can be isolated through physical separation.
Note that Bluetooth is not an acceptable substitute.
this is a very deep question, if you record audio and only a computer listens to it, does anyone hear it? it's totally the tree falling in the forest with no one around does it make a sound.
If you're on a mac, go to Sound in System Preferences. Click Input. Do you see activity in the input monitor? That means your microphone has been on the entire time you've used your computer and has heard everything you said. I HIGHLY recommend disabling your internal mic. So does Apple.
Using one of the other tools mentioned here (Oversight) it looks like Microphone starts when you open Input and closes when you close Input tab. Which makes sense as you do want to see Input feedback instantly. Mac 10.11
The point is that your mic is 'hot' if you don't turn the volume all the way down. You don't need root access to run 'sox' or other audio capturing scripts. Very easy to eavesdrop, as this Shazam example illustrates.
That's not a bug. It's intentionally deceptive software.