ArsTechnica unfortunately again misleads people due to limited expertise.
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.
I'm not sure what you're comment is trying to say - TARGETING a new API doesn't meant you don't SUPPORT an older API. It just determines backwards compatiblity behaviour. We currently release a product that supports Android 4.1 while targeting Android 7.1.
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.
What it's trying to say is that this can be a big problem even if it doesn't affect Android 6 and up. Your own statistics say it can affect up to 45% of Android users.
I work on a large Android app and we do 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.
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.
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.
About the actual usage and activity of the devices in the wild. The network that does that is targeting western markets where the availability of devices that are vulnerable is dropping steeply - not fast enough, but still.
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.
Your comments here are arguing that this isn't a problem. You called the stats dashboard "hugely misleading" with the implication that the problem is not as bad as it would suggest, but actually it shows that the problem is worse than the average western based HN developer realises (based on their day to day experience).
I would love love love if my Android phone would occasionally provide me a summary of which apps are making use of the camera, the GPS, and the microphone and allow me to disable them.
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.
One thing that Google really should do is allow a feature to temporarily give permissions or fake giving permissions. For example, I want to send my location on Whatsapp then I would want it to ask for permissions every time. Similar to how certain websites cannot access my microphone just because I let them do it once, neither should apps.
If I understand you right, you're saying that this doesn't actually work most of the time - but not that people are not trying it.
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.
I've become totally superstitious (convinced, even) that phones are listening to more than just ultrasound. There have been too many uncanny situations where youtube or google have recommended results that were far too specific to the conversation happening moments before. For example, one time I was telling my girlfriend about fourier transformations, something she'd never heard of before. She typed "Fo" into her phone. "Fourier transormation" it suggested. Maybe this was due to the IP address we were connected through. That alone is creepy enough as it is. Sometimes I wonder if it isn't something more though.
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.
I agree that we should remain skeptical, however, one important distinction between this and ghost stories is this is already fully technically possible. All that's needed is the will, the raw processing power, and the battery life to support it. No one could ever create a proof of concept for ghosts.
This comment is an argument that it's possible, not a claim that it's happening.
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.
Replace ghost stories with the creepy house at the end of that old road having an old woman in who eats children if they try and get their ball back, and turns them into puppets making the next victim watch the show, then. And it's totally happening because I heard a crunch one time that must have been bones.
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)
I think that works based on location. A few years ago there were reports of people who shared a psychiatrist being recommended to each other, based on their frequent visits to the office.
I've had this with someone who I emailed (completely separate from Facebook) being recommended to me. The only logical conclusion I could come to is that Facebook was mining their emails for contacts.
Also experienced something like this. Had a discussion with a work colleague on a particular topic, and on getting home and going to youtube, the top recommended videos were all on that topic
I'd like to be able to find an Android utility that shows me apps/processes that are auto-launching in the background and kill them, but my last attempt yielded two that I tried and blacklisted (a feature it has) some apps, yet after booting I was still able to force stop them, implying they still had launched on their own.
Is there any app that actually works for this, or is it somehow not possible?
that's quite amusing suggestion considering Greenify is closed sourced Chinese root app which optionally (only?) report data back to mainland China and dev worked for some companies producing shady apps, before according his LinkedIn profile
there is option to send some statistics data back to developer, it's opt-in
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.
As a side note, many Chinese brands have started preventing applications from starting automatically without being whitelisted in settings (different for each vendor). Examples include Xiaomi (since MIUI 8.1 or 8.2), and some recent ASUS/Lenovo devices.
This is the work of a library used by certain apps, not of Google (although it wouldn't surprise me if Google turned out to be doing the same, discreetly).
I think Android should have way clearer notifications that your mic or camera are being used in the background, like iOS does, even if it may be cumbersome.
Yes there should be an icon when your mic is active. I tried to build a service in Android to do this but there's no API to get whether the mic is in use or not AFAIK. I ended up disabling mic access for almost all apps, but the Google App and Google Play Services complain when you do this.
I'd go even further and light the notification LED the entire time something is reading the camera/mic from the firmware (such that applications can't disable it via software). The indicator works well for the webcams on most laptops.
That's a great idea. Even better if there were tiny dedicated LEDs near the front facing camera and microphone to make it 100% clear what they mean.
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.
I'd go even even further and have a physical switch on the device. I want absolute certainty that my devices are incapable of spying on me when they are switched off.
Yeah, that's wishful thinking. Because even if there were such a switch, it would be deliberately perverted.
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.
you are correct, but this was mostly brought up for historical reasons: researchers discovered an osx malware that after disabling the camera LED on older macbooks could secretly record the owner.
Between this and the recent research paper I read about using the front-facing camera on mobile phones to track where I'm looking on web pages, I just want to unplug.
There's an app called D-Vasive (no affiliation) that alerts of mic and camera usage on your phone. I've been using it for years, but it's only alerted me in predictable situations so far. I don't download a whole lot of apps however. It’s nice to have as a bit of peace of mind.
Thanks for that, it seems to explain most of the problems security faces today. It's similar to how social engineering works, for example, even if someone was told that plugging in a dropped USB stick is dangerous, they may still do it because of the burning curiosity inside. ( I myself would take a peek, at least on a sandbox or VM )
Android does /not/ trust users. The enormous pile of crap I have to go through just to disable selinux and get write access to the sdcard and ext4 partitions is ridiculous.
Which I do use, if you mean iOS. I'm advocating for further development of android, which hopefully stimulates some more competition. Or maybe it's a good thing that Android is so broken in a privacy sense. It allows government + malicious entities to target it much easier instead of iOS devices, leaving me safer. /s
You're missing the fact that we're using Android because it's NOT locked down and just like malicious apps can use hardware in background... that actually lets useful apps use hardware in background as well.
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.
Nothing in iOS prevents an app from using the microphone in the background - I use apps that do it all the time. When I do however, there is a big, obvious, red bar at the top of my screen to remind me/let me know that it's happening.
Why dont the android designers want to do something like that?
Is it possible to damage human hearing with sufficiently loud pulses above 20Khz?
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.
Your eyes are also unable to see infrared, or ultra-violet, yet either with sufficient power will blind you. In fact it's often much more dangerous than visible light, because the light won't trigger your blink reflex.
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.
>> I would say that if the ear does not pick up the energy above 20khz, then it cannot be harmed either.
> 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?
Is there any legitimate need for a phone mic to pick up sounds way outside the range of human speech and hearing? If this sort of thing should not be allowed, why not just add a software low-pass filter in the front of the audio input chain? What would the side effects of this be?
I wonder what it would take to make an app that does this exact thing and listens in order to hook into whatever and prevent malicious apps from beaconing. Also seems useful in order to see if there are any such ads out in the wild yet.
I wouldn't be surprised if Google, Apple or Amazon are doing (or going to do) something similar. It doesn't create much traffic at all, a couple of bytes is enough and they can be tacked on to the data stream without anyone noticing.
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.
Apple's OS design philosophy makes this extremely difficult, even if someone wanted to sneak it in. The OS notifies of such activity (mic active) on a system level, and the permission model requires explicit permission at time of first access attempt, even for most of Apple's own apps.
My point is that they could if they wanted to. Granted, they don't need the money, but still... it's something you can easily hide and nobody would be able to tell without spending weeks looking at disassembly.
You're putting way too much trust on a company that constantly screws over it's customers to earn some more money by removing ports, putting functionality behind paywall (looking at you Safari extension costs), etc. They're better than Android phones in these matters but their financial position might change some day and they might do it.
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.