More Android phones than ever are covertly listening for inaudible sounds in ads(arstechnica.com)
arstechnica.com
More Android phones than ever are covertly listening for inaudible sounds in ads
https://arstechnica.com/security/2017/05/theres-a-spike-in-android-apps-that-covertly-listen-for-inaudible-sounds-in-ads/
106 comments
Yes, I agree, including gyroscopes. As well as a way of seeing which apps are using the sensors.
Nearly 2/3rds of Android phones that have accessed the Google Play store in the week leading up to May 2nd are not on Android 6 or later:
https://developer.android.com/about/dashboards/index.html
https://developer.android.com/about/dashboards/index.html
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.
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 completely agree. The Android upgrade situation is a huge and rather well known issue.
Not to Google, as they don't care.
Now with Android N reaching 7%,one year later, who do they think will even bother with Android O?
Now with Android N reaching 7%,one year later, who do they think will even bother with Android O?
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.
We also have some N features like shortcuts.
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.
How many customers do you feel will have devices with Android O, given Android N is around 7% after one year?
It goes further than that.
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.
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.
The landscape of people who actually download apps is very different though.
And he has a point : Google could easily ask that all new apps target the last version of the OS.
And he has a point : Google could easily ask that all new apps target the last version of the OS.
Just as they could "nicely" require OEMs to get their game straight.
Not sure how it could work out tbh.
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.
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.
Here in Germany all low budget phones are still 4.x, which are what everyone on pre-paid mostly buys.
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.
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.
Please don't use all caps on HN. Use an asterisk * at the beginning and end of the text you wish to emphasize to get italics.
Are you suggesting it's ok for non-western users to be tracked this way? Why would we ignore most of the world when discussing an issue like this?
I think you may have misread that comment. Op didn't imply anything of the sort.
I never said or claimed anything like that. Where did you get that idea?
Then what were you claiming? Because I posted the worldwide stats and you called them misleading. Misleading who about what?
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.
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.
anon1385 is a step ahead of you; s/he inferred it from your argument and is asking you to consider the implications thereof.
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).
do the opposite.
build your app for android 5 and push to the store.
done. target 100% of devices and get no dialog for android 6 users.
build your app for android 5 and push to the store.
done. target 100% of devices and get no dialog for android 6 users.
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.
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.
Settings -> Apps -> Gear icon in the top bar -> App permissions should do what you want (at least it does on 7.1.2 / Pixel).
Not obvious I know :/
Not obvious I know :/
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.
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.
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.
These are like modern day ghost stories.
Do you really think they're running constant speech recognition on all phones, apparently unnoticed so far, just to recommend YouTube videos?
Do you really think they're running constant speech recognition on all phones, apparently unnoticed so far, just to recommend YouTube videos?
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.
Here's a random anecdote about how much data FB messenger can use: https://www.reddit.com/r/androidapps/comments/49yhlh/faceboo...
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...
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)
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)
No common friends, but college girlfriend recommended as potential friend on Facebook is my creepiest data mining moment ever.
She might have been stalking you..
If she searched for you, it can make you show up in the recommended friends list
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.
What about friends who are two degrees of separation? I suspect your social graphs are closer than you might realize.
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?
Is there any app that actually works for this, or is it somehow not possible?
Not sure if it's exactly what you're looking for, but greenify might do the trick. You might need root.
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....
[1]https://forum.xda-developers.com/apps/greenify
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....
[1]https://forum.xda-developers.com/apps/greenify
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
Could you back this up / substantiate your claim, please?
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.
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.
Please decompile the APK - I'd read your writeup.
Autostarts - https://play.google.com/store/apps/details?id=com.elsdoerfer...
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.
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.
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.
SD Maid / App control tab, you will need root
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.
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.
The LED should be in series with e.g. the Vcc pin on the ADC. Enabling the recording hardware needs to depend on the LED being on.
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.
[1] https://en.wikipedia.org/wiki/Secure_Digital#Features
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.
[1] https://en.wikipedia.org/wiki/Secure_Digital#Features
Notification LED? A majority of phones(in the US) don't come with this and the ones that do need root permission to access 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.
[deleted]
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.
Why does android trust developers so much? Just lock down the apps already, and make microphone usage obvious.
[deleted]
Because we already have a locked-down platform and you're welcome to use it.
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.
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?
Why dont the android designers want to do something like that?
i think it is fair to say that android can do stuff ios does not allow.
for example you can add the behavior you just described to android using something like xprivacy.
for example you can add the behavior you just described to android using something like xprivacy.
[deleted]
Android doesn't trust developers. It trusts users - everything has to be disclosed and users have to agree. It is a open platform, not walled garden.
We have https://en.wikipedia.org/wiki/Dancing_pigs problem there.
We have https://en.wikipedia.org/wiki/Dancing_pigs problem there.
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.
Android trusts developers a hell of a lot more than users.
The real question is why does Android along with most other operating systems distrust the user so much.
If the user were regarded as important facilities would be provided to enable the user to control the applications.
If the user were regarded as important facilities would be provided to enable the user to control the applications.
Because as one FOSS dev put it to me once, "users are dumb".
This after he had witnessed the results of a usability test on one of the big name desktop environments...
This after he had witnessed the results of a usability test on one of the big name desktop environments...
Users would revoke permissions needed to show ads on apps that have no reason to access the Internet.
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.
Also, relevant: https://en.wikipedia.org/wiki/Cinavia
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
I don't know but 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. 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.
https://en.wikipedia.org/wiki/High-intensity_focused_ultraso...
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...
>> 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?
> 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?
Well you would be wrong.
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.
Found some more details on this technology.
https://github.com/MAVProxyUser/SilverPushUnmasked
https://github.com/MAVProxyUser/SilverPushUnmasked
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
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
If you're interested in exploring ultrasound in your environment, SpectrumView Plus is a great tool for the job.
http://www.oxfordwaveresearch.com/products/spectrumviewapp/
http://www.oxfordwaveresearch.com/products/spectrumviewapp/
Nice tool, thanks for the link!
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.
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 would never do something like this. It's totally against their MO.
Apple is made of people. People who change, people who come and go. Maybe Apple today wouldn't, but tomorrow Apple will be a different company.
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.
How could you know this though? There's no source code to audit or anything.
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.
Oh, but they do need the money. The goal of the company is to maximize profit for the shareholders.
The "maximizing shareholder value" idea is a recent and inaccurate belief.
https://www.fastcompany.com/1680174/maximize-shareholder-val...
https://www.fastcompany.com/1680174/maximize-shareholder-val...
Corporations are beholden to their shareholders. This is an obvious and undisputed fact, rather than a belief.
The article you linked questioned the legal and ethical justification for this fact, not its accuracy.
The article you linked questioned the legal and ethical justification for this fact, not its accuracy.
I don't think the word "fact" means what you think it means.
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.
Hmm, did't people report that their Amazon devices fire up when Amazon ads are playing on TV?
When the ad uses the trigger phrase, or when it doesn't?
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.
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.
Link, anyone?
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.