Shhh! Shazam is always listening – even when it's been switched 'off' A security researcher has discovered that when the Mac version of Shazam is switched off, it simply stops processing recorded data. The recording itself continues. The music identification service admits the behaviour but says it only keeps recording purely for technical reasons. Patrick Wardle, a former NSA staffer who heads …
What gets me about this article is Wardle complains of incorrect use of terminology, off is not (fully) off. Yet Wardle is equally guilty of incorrect use of terminology, El Reg too. Wardle found that the sound is not committed to any storage media, processed nor transmitted to the mothership yet the word 'recorded' is repeatedly used.
Recorded: to set down in writing or the like, as for the purpose of preserving evidence.
Sure the mic is on but the data is just going to /dev/nul.
I agree with xeroks, Shazam should call this state paused, give a proper off option too and explain the difference.
Not only MacOS. If you have an Android device, Google is always listening and the microphone cannot be switched off. See the comments here:
http://www.ghacks.net/2014/03/07/mute-microphone-android-device/
Other devices too.
http://www.usatoday.com/story/tech/columnist/komando/2015/10/02/3-gadgets-always-listening-and-how-stop-them/73191644/
Who would have thought that the population would not only invite mass surveillance devices into their homes but pay for then too!
Google always listening is why most of their captured audio from me is likely to be forceful farts and the phrase that follows, "That's for you Google".
Downside is they can probably identify me at any rest room on the planet.
In this particular case I suspect what the developer is saying is true.
By the time you ask an app "WTF is this on the radio" the horse has bolted. It is quite likely not to have enough data for an answer. So having two levels of "OFF" - processing and listening is a natural technical decision.
Now, why did the developers communicate it so poorly is a different story. I suspect it is a case of Hanlon's razor.
"Now, why did the developers communicate it so poorly is a different story. I suspect it is a case of Hanlon's razor."
Well, people who write stuff like "the user's decision not to leverage our app's functionality is fully respected" obviously have poor communication skills.
I'd say the exact opposite. They are very highly skilled and very highly trained.
It's the difference between being skilled in communication and understanding the people you are communicating with and their needs/expectations.
"No need for Big Brother to bug your house when you buy and install this shit for them!"
Someone would STILL have to code a 'back door' zero-day, or pay them (Shazam devs) under the table for it.
A speaker is a mic. Just as a mic is a speaker.
That is one of those things that strike me as having been seen on Doctor Who, MacGyver or whatever with no real idea of the practicalities. Seriously, you are not going to get any useable signal out of a moving coil speaker used as a mic even if the surrounding circuitry could theoretically read it. And as for getting any sound at all from a condenser mic, forget it completely.
Not at all - a speaker and a microphone are essentially the same device, though optimised in two different directions - making a standard speaker vibrate will cause the driver coil to excite, and exciting a mic will make it vibrate.
Try explaining how that works with a CONDENSER mike.
Yes, a moving coil speaker and a DYNAMIC microphone as theoretically interchangable, but there are practical limits. Using a mike as an earpiece can be practical in a pinch (if generally very tinny) but a speaker as a mike is generally a non-starter. Optimised mics generate signals in the 100mV or less region. A speaker in the same role may be lucky to generate 1µV - that's well into the realm of ultra sensitve amplifiers, yes, it can be done, but even then the audio is generally swamped by the effects of imperceptible air currents and temperature changes. In circuit it isn't connected to such a sensitive pre-amp: it goes to a power amp OUTPUT instead
It's one of those things that asserting blindly is nothing more than intellectual knob waving. In practice it will not work just as the refined chap stated. Claiming otherwise simply shows ignorance.
As much as the series if full of hyperbole, the authors were clearly up to date about what was possible even several years ago..
Big Brother is not just watching he is Geo-positioning, Recording, Tracking, Establishing, Analyzing ( Anal being the operative word here) everything and anything wherever possible... Even though the majority of this information is just being used for eventual advertising(spam) it really doesn't require the need for owning a tin-foil hat in order to be paranoid...
True. It has to be a foolproof circuit, where the LED voltage also switches on the mic's signal path. And the switch (transistor, relay, whatever) needs a bit more voltage than the LED.
Like everything else down to the logic gates, you can't truly begin to trust it until the day we have fully auditable open-spec hardware.
I know privacy is serious business but I don't think the devs have done anything wrong here.
To say "the recording continues" is not true, as the sound is not been recorded (it never is) nor is it being processed. Yes sound waves are entering the microphone, yes those sound waves are compressing/bending something and yes there's a change in resistance in the mic. But is the computer 'listening'?
If I put a current across the mic to produce voltage changes is it now listening? What if an IC is converting those analog voltage changes into a digital representation somewhere? Now is it listening?
This seems a bit like a philosophical question, but as long as the sound is not being actively saved or transmitted somewhere it's a bit like the proverbial falling tree in the forest.
If you want to be cross with the devs then attack them for wasted CPU cycles but please, not privacy....
and yes (i would imagine) there's a current across it so some changes in voltage occur
To say "the recording continues" is not true, as the sound is not been recorded (it never is) nor is it being processed. Yes sound waves are entering the microphone, yes those sound waves are compressing/bending something and yes there's a change in resistance in the mic. But is the computer 'listening'?
The author takes care to point out that it's up for debate if keeping the mic online is a bad thing, but from my perspective I don't want an application grabbing data it has no business accessing until explicitly permitted, I don't like those "foot in the door" strategies.
What worries me more is that the macOS and iOS versions share the same SDK, so presumably the same "convenient" behaviour. I think I'll uninstall Shazam from my phone - just to be sure. I use it at best once every month so it won't be missed much (never installed the desktop version - one copy is was enough).
"The author takes care to point out that it's up for debate if keeping the mic online is a bad thing, but from my perspective I don't want an application grabbing data it has no business accessing until explicitly permitted, I don't like those "foot in the door" strategies."
But what happens when the sound you want to search happened five seconds ago? Or in this case, it takes several seconds to go from completely off to listening and recording, by which time the song's ending and there's not enough left to ID it. I for one have had any number of those, "Damn, just missed!" moments to think sometimes it would be nice for it to anticipate when I want a song identified before I realize I wanted it identified but am too late to do it now.
This is sounding a whole lot like a case of, "You can't please everyone." If you try to appease privacy concerns, people complain because the mic triggers too late. What can you do?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
