Android's capabilities system is much better with Android 6.0. Apps targeting the latest SDK require users to accept permissions at runtime, and those built with previous SDKs can have capabilities disabled through settings:
That's not really going to fix these things - if you can open a mic in the background without any UI to indicate it's happening, it will be abused. If I write an app with a legitimate need for the mic and get permission to use it, I can abuse it.
Yes, in hindsight (and I say this as a full-time app developer) Apple had exactly the right amount of trust for app developers - almost none. In the few instances where things didn't require approval (for example querying a URL scheme to allow for for crude inter-app communication), they were abused by even reputable developers like Twitter. Glad to see Google finally catching up with Android 6.
The J2ME/MIDP platform also had runtime permissions; for example, when I used Opera Mini on my Nokia S60, it would ask for permissions to write to the Downloads directory.
The MIDP security system probably had its flaws, but it seems weird that Android simply ignored it and went with an exclusive ask-on-install model.
Agreed, but Android's made some pretty good strides on that front with Android 6.0. Just got it yesterday and, while a few apps were confusingly broken until I went digging (my audiobook app looking in a no-longer-extant path for the SD card, as apps get their own virtual storage path in 6.0), I'm pretty happy with the changes.
IIRC, there was US legislation in the 1990s that required phones to have an indicator to be wired in that lit up when a microphone was enabled.
Either this was relaxed, or reinterpreted (or I'm mis-remembering), and it was deemed okay to activate the LED with firmware. Clearly a mistake. And it probably only applied to land-line phones.
iOS really ought to put a "currently recording audio" icon in the menu bar, in addition to the existing one-time permission request. Sophisticated hacks could bypass it, but it would at least help in more pedestrian scenarios like this one.
I think it already does that if an app requests to run in the background while recording. Spotify and the Voice Memos app leave a red bar at the top of the screen (like the green one while on the phone) if you background them while recording.
It already does! The menu bar turns red, with the name of the app using the microphone, as shown in this example[0] where Shazam is backgrounded but listening for songs.
Except for system software like Siri. I didn't realize I had the 'Allow "Hey Siri"' option (which constantly listens for the trigger word) turned on until I happened to check the settings, which was a little unnerving.
You're right, I hadn't considered Siri. But, I don't think it would be much use as I'd assume if the system software was about to do something nefarious it would just disable the notifications.
Best assume if you have Hey Siri enabled, it is always listening.
At least Hey Siri is an offline feature, it won't send anything over the network unless it actually detects that phrase. This can be easily verified by turning on Airplane Mode and trying it, it still works.
Yeah, I know about that. But that doesn't really help if the app only listens while foregrounded. (In that case the red bar does usually show up briefly before the app responds to the backgrounding event, but that's not very noticeable and basically a bug.)
Location Services is a model here: like sound recording it asks for permission first, like sound recording it flashes the menu bar if an app is using precise location in the background, but there's also a small icon that shows up in the menu bar whenever it's being used, even by the foreground app.
Consumption of TV has moved almost entirely to platforms that can track that data themselves (for example through a set top box or directly on the web), without requiring someone to have a smartphone turned on, running spyware, in the room.
I think this data is still useful because there isn't a one-to-one correspondence between those devices and the viewers. A box might be left on with nobody around, or it might be the center of a viewing party with twenty people. They also want to know who is watching, since demographics count for a lot.
Agreed. There's an indicator for when the mic is activated in the background, but not when the use utilizing app is in the foreground. Nothing at all for camera activation.
I think it's illegal in all states if no subject of the recording provides consent, the split is between states with a one-party consent rule and an all-parties consent rule.
A lot of ToS are null and void in many countries. The paragraphs that are null and void then usually are just void, but the rest of the contract still holds.
Seems like you could distinguish between "recording" and "listening" in that case. Then "recording" is only initiated upon the activation of a trigger which confirms two-party consent.
Though I wouldn't be surprised if Apple intermittently recorded background noise for ex. training purposes in violation of that, anyways.
You can argue it isn't wiretapping/recording. Like Shazam, they are fingerprinting the audio and sending the fingerprints back to a server. In the same way, something like Moves fingerprints the gyroscope on your phone and identifies if you are running/walking/taking a car -- but this isn't surveillance.
It would be cool to have an app that could alert you to the production of these sounds. Then you could complain to the station/channel, and to the FTC. Complaint to the FTC, with recorded evidence, could be included in the app.
It would be cooler still if the FTC made this app available.
There are benign use-cases for this technology, though. For example, any TV/Radio ads containing the phrases "Hey Siri", "OK Google", or "Alexa" definitely should contain an audio beacon so that your iPhone/Android/Amazon Echo knows that a TV or Radio ad is playing, and not a human legitimately asking for a command.
That's a really bad way to solve that problem, it relies on other systems following a protocol that they have no reason to even know exists.
A much better way to solve it, which is already being done (to some degree of success) is to calibrate the phrase detection to the owner's unique voice.
Based on the letter, it looks like a weak statement by the FTC:
if your application enabled third parties to monitor television-viewing habits of U.S. consumers and your statements or user interface stated or implied otherwise, this could constitute a violation of the Federal Trade Commission Act. We would encourage you to disclose this fact to potential customers, empowering them to make an informed decision about what information to disclose in exchange for using your application.
Note that there's a violation only if the developer's statements or user interface stated or implied otherwise. By my reading, if the dev says nothing and collects the data then they are not in violation; the violation occurs if they lie about it. Also, the FTC doesn't require the dev to disclose anything, they merely encourage it.
However, I have no experience with these issues. Does anyone know more about it?
Yeah from the letter it doesn't appear like it's illegal, otherwise the FTC would have taken that route. Having said that, the letter is a strong indication that it is on the FTC's radar insomuch as they will find a way to make it illegal if it keeps coming up as a privacy issue.
47 comments
[ 2.9 ms ] story [ 108 ms ] threadAndroid's capabilities system is much better with Android 6.0. Apps targeting the latest SDK require users to accept permissions at runtime, and those built with previous SDKs can have capabilities disabled through settings:
http://inthecheesefactory.com/blog/things-you-need-to-know-a...
https://public.addonsdetector.com/silverpush-android-apps/
https://web.archive.org/web/20160320170615/https://public.ad...
The MIDP security system probably had its flaws, but it seems weird that Android simply ignored it and went with an exclusive ask-on-install model.
Either this was relaxed, or reinterpreted (or I'm mis-remembering), and it was deemed okay to activate the LED with firmware. Clearly a mistake. And it probably only applied to land-line phones.
[0]https://imgur.com/a/OzS4Z
Best assume if you have Hey Siri enabled, it is always listening.
Location Services is a model here: like sound recording it asks for permission first, like sound recording it flashes the menu bar if an app is using precise location in the background, but there's also a small icon that shows up in the menu bar whenever it's being used, even by the foreground app.
http://www.wired.co.uk/news/archive/2012-11/07/microsoft-pat...
* By reading this post you give me the right to steal all your underwear
Though I wouldn't be surprised if Apple intermittently recorded background noise for ex. training purposes in violation of that, anyways.
It would be cooler still if the FTC made this app available.
A much better way to solve it, which is already being done (to some degree of success) is to calibrate the phrase detection to the owner's unique voice.
The same as I would complain about someone peering in my window from outside my house or through a long lense, which also doesn't physically hurt me.
if your application enabled third parties to monitor television-viewing habits of U.S. consumers and your statements or user interface stated or implied otherwise, this could constitute a violation of the Federal Trade Commission Act. We would encourage you to disclose this fact to potential customers, empowering them to make an informed decision about what information to disclose in exchange for using your application.
Note that there's a violation only if the developer's statements or user interface stated or implied otherwise. By my reading, if the dev says nothing and collects the data then they are not in violation; the violation occurs if they lie about it. Also, the FTC doesn't require the dev to disclose anything, they merely encourage it.
However, I have no experience with these issues. Does anyone know more about it?