More Android phones than ever are covertly listening for inaudible sounds in ads
arstechnica.com
arstechnica.com
On modern Androids (6.0+) accessing the microphone requires an explicit permission granted by user (just like on iOS). Furthermore, due to Doze mode implemented in 6.0 and expanded in 7.0 running these kind of services without notifying the user cleary (with permanent notification) has become pretty much impossible and unreliable. To run in background when the phone isn't in active use the service needs to be marked "Foreground" which demands a permanent notification.
Having said that - Google is failing here in several ways. First, they STILL let apps be published that don't target Android 6.0. Apps that target older Androids get permissions granted at install time (those can be revoked, but user needs to go to settings for that). There's no reason to let people publish new apps that don't adhere to new permission model, but Google just doesn't care.
They also need to clearly mark use of system resources in the background - just like we have the GPS icon, we need a clear indication of active microphone, speaker and other hardware modules while running in the backgorund.
Also this dashboard is hugely misleading for the HN audience - in western audiences (USA, Canada, EU, etc. - countries HN users are from) we're tracking ~10% devices that are running Android 4.x and more than 40% devices running on Android 6.0 with additional 15% on 7.x - meaning more than half of active western users are running decently modern Android.
Now with Android N reaching 7%,one year later, who do they think will even bother with Android O?
As soon as the sdk will be final we will think about compiling against it and targeting it.
We are not in a huge hurry, it can skip a release or 2 (we release every 3 weeks). There are no big breaking changes though (unlike let's say Marshmallow) so as long as the support lib is stable (it needs to match with compile version) we are going to support it ASAP.
We also have some N features like shortcuts.
First, that 7% figure is the whole Android (with play services) user base, numbers are pretty different on the dashboard of our general public app.
Secondly, we will start by compiling for O : the supports libraries are only tested for their corresponding compile version. That way we will be able to use new support lib features on all Android versions.
Then, we will target O (probably in the same release of the app). It should be pretty trivial : this is not marshmallow with the new permission system, system level changes in O are manageable.
For clarification, the build script of an android app separates compile version (= binary compatibility) and target version (= you handle the new behaviors of the system like granular permission in M)
By targeting O ASAP we :
- are potentially able to ship some features based on this release, like shortcuts for N. Sure, we are not going to spend a lot of dev time on an O-only feature right now but there are some easy wins. And of course the install base does not stay small for very long.
-are able to detect potential problems before OEMs start launching flagships with that Android version and we get millions of crashes / day.
There is really no good reason to stay behind.
And he has a point : Google could easily ask that all new apps target the last version of the OS.
Ok I am not a lawyer or a part of the negotiations between Google and OEMs but I don't think Google can force OEMs to keep phones up to date for a given amount of time.
First, it is not just up to the OEMs, they need new drivers for new platform versions.
Secondly, what leverage does Google have here ? Preventing OEMs from releasing phones with Play Services looks like a really sharp double edged sword. Even triple edged actually since consumers would also suffer from this kind of deal.
Same applies to the southern countries, which I visit regularly.
Most people on 6.0+ are on contracts, which are the minority, even though many of them might be using your app.
I've yet to also see a single worldwide USAGE statistic that would reflect that dashboard. Whatever Google is counting is not the users that actually download and use apps (and are thus vulnerable) - pretty much all stats I've ever seen (even on apps with millions of worldwide downloads) have significantly higher update rates. Hence - misleading.
build your app for android 5 and push to the store.
done. target 100% of devices and get no dialog for android 6 users.
Sure, I can hunt for this on my own. That's not the point here. If I'm walking around with a supercomputer in my pocket, I'd like it to do this sort of stuff for me automagically.
Not obvious I know :/
Myself, I don't care about the fact that Google is 'failing' on this, because even if they fix all the problems you identify, the people exploit such approaches will find some other loophole to exploit or work around. The inevitable result: another arms race that doesn't create value for consumers.
What I care about is the recurring social problem of which this is just the latest instance: marketing/advertising folk deceiving consumers. If your business model relies on deception then you are a Bad Person, and this applies equally to those who dream up such schemes and those who implement them at the technical level.
The legal system does not move at the speed of software development, and so there are strong economic incentives to engage in such unethical behavior and move on before people catch on and organize themselves to litigate the issue or effectively regulate the behavior. It is time, therefore, to punish bad actors by more direct methods of retaliation, which necessarily involves inhibiting their ability to buy their way out of trouble by renting legal mercenaries.
Facebook messenger and google voice search are my number one suspects. But moreso, all it takes is a single person in a room full of phones to have installed an app that's using the microphone unethically, and suddenly everyone's conversation is being turned into marketing/spy data. Anybody who's connected somehow to that location is going to be statistically associated ("implicated") with this data.
Do you really think they're running constant speech recognition on all phones, apparently unnoticed so far, just to recommend YouTube videos?
It'd be much, much easier for apps like FB messenger to transmit sparse samples of low bitrate audio to a server for processing there. 1 hr/day @ 8kbps ~ 110 MB/month. As a matter of fact, with "deep learning" and whatall, it doesn't seem like the audio would even need to be intelligible to human ears for it to still be useful in some marketing algorithms or to generate guesses of interests correlating to the audio. Those interests might be presented as an ad, search suggestion, etc. Why would google use something like this for search recommendations? Because it's training data, that's why!
What I'm arguing is that even though conventional "speech recognition" is processor intensive and unlikely happening on a mobile client side, it's just not that far-fetched that small snips of low bitrate conversation data might be used to tune marketing prediction models on the server-side.
In training general purpose models, huge amounts of data could be generated by only a little bit of data/user. Where would this sort of thing cross a privacy line? I'm not sure. Personally, it kinda creeps me out regardless.
Seriously, listen to these 8kbps opus samples: http://www.opus-codec.org/examples/ . If they're intelligible to human ears, I can't imagine what some clever learning algorithms could do with that and much much less.
Here's a random anecdote about how much data FB messenger can use: https://www.reddit.com/r/androidapps/comments/49yhlh/faceboo...
The fact that it's possible to eat a child or make a puppet does little to make this kind of thing much more realistic.
The much simpler answer is that you are more predictable than you think, and likely more influenced by things Google can watch (clicks, ads) than you think. You also don't spot when it doesn't recommend something so accurate so it could even just be chance (or at least doesn't mean they're good at it)
Is there any app that actually works for this, or is it somehow not possible?
Also Android now has the doze feature that should hibernate apps by default when not used.
[0]https://play.google.com/store/apps/details?id=com.oasisfeng....
I am not saying he is actualy sending some other data without permission of user, but being closed sourced Chinese ROOT app is more than enough to stay away from it in days of Nougat/Marshmallow making this app pretty much useless anyway.
The apps might be started using misc broadcasted events, not only on boot. If you want to prevent them to start, you will need root.
Communication privacy laws also need to be updated for modern times. It's a federal offense to steal someone's junk mail yet widespread electronic surveillance is somehow a business model.
E.g. some SD cards have a "write-protect notch" the status of which can be changed by physically moving a sliding tab. Very reminiscent of write protect on floppy disks.
Here's the gotcha[1]:
The presence of a notch, and the presence and position of a tab, have no effect on the SD card's operation. A host device that supports write protection should refuse to write to an SD card that is designated read-only in this way. Some host devices do not support write protection, which is an optional feature of the SD specification. Drivers and devices that do obey a read-only indication may give the user a way to override it.
If the user were regarded as important facilities would be provided to enable the user to control the applications.
This after he had witnessed the results of a usability test on one of the big name desktop environments...
We have https://en.wikipedia.org/wiki/Dancing_pigs problem there.
Free market at its best - if you want a corporation to babysit you, you have a platform. If you don't (and want to accept consequences) you can use another one. Great for all of us.
Why dont the android designers want to do something like that?
for example you can add the behavior you just described to android using something like xprivacy.
Most search results point to a miniscule wattage delivered by typical ultrasonic noises, but controlling for wattage, I feel like it might be possible to overdrive a high-frequency pulse to deliver more wattage in the same range.
Also, relevant: https://en.wikipedia.org/wiki/Cinavia
Sound is just vibration in the air, and if the pressure is high enough, you're going to suffer. High frequency ultrasound is used for various medical treatments, most of which involve localised killing of cells.
https://en.wikipedia.org/wiki/High-intensity_focused_ultraso...
> Your eyes are also unable to see infrared, or ultra-violet, yet either with sufficient power will blind you.
Sufficient power delivered by IR radiation can easily set you on fire, regardless of whether the part of you that's burning was sensitive to light or not. And UV can do much nastier things.
But it's hard for them to have any effect without depositing energy. It's absolutely correct that if an ear, or anything else, doesn't pick up energy from whatever you're throwing at it, it cannot be harmed.
Why worry about hearing specifically as a target for ultrasonic damage? As you yourself point out, sound can deposit energy regardless of the particular physical structure it's hitting. Delivering enough IR to the ear will destroy your hearing, but not because of any property of your hearing or your ears. Is there reason to believe that ears or hearing are more sensitive to ultrasound than, say, your nose is?
Someone should build an ultrasonic detector that can recognize these kind of packets and have a look how wide spread this technique already is. We could also need an ultrasonic jammer and ways to add low pass filters to our mics, like some special tape we can place over it to absorb the high frequencies... maybe normal duct tape is already enough.. hmmm
However, we need someone to build an app that can detect ultrasonic FSK signals and log them / pop up a notification. I assume they use short bursts which makes looking at the spectrum constantly unfeasible.
https://www.fastcompany.com/1680174/maximize-shareholder-val...
The article you linked questioned the legal and ethical justification for this fact, not its accuracy.
Hidden signals are actually a good way to make the device not fire up in the former case. Signals that don't need to be tracked or stored, of course.