Some Android apps are using ultrasonic beacons to track users | Hacker News Reader

Some Android apps are using ultrasonic beacons to track users

bleepingcomputer.com

159 pointsvezycash90 comments

062115 - How to Manage Android App Permissions to Protect Your Privacy http://thehackernews.com/2015/06/android-permission-manager....

beacon-blocking Chrome extension and sample Android (research prototype) patch: http://ubeacsec.org/#Downloads

Silverdog Chrome Extension http://www.thewindowsclub.com/silverdog-chrome-extension-mit...

Disable Beacon monitoring on a condition in Application http://stackoverflow.com/questions/34486930/disable-beacon-m...

050217 - https://www.wired.com/2017/05/hundreds-apps-can-listen-beaco...

110316 - https://www.wired.com/2016/11/block-ultrasonic-signals-didnt...

Beacon: Phone Tracker https://www.aptoide.com/app/com.fibercode.beacon/beacon-phon...

Don't think permissions don't really protect you from this.

AFAIK you don't need permission to _play_ sounds at least for foreground apps. So that means in a public space, it doesn't matter if your mic is disabled - if anyone _else_ gave permission for an app to use the mic, their phone hear your phone transmitting ultrasound, allowing you to be tracked.

PS that first sentence was supposed to read...

"Don't think permissions really protect you from this."

You have posted a number of links, but what's your opinion on the topic?

Given the link-dump, I'm assuming it's "Technologically savvy people can solve this for themselves, and that's sufficient."

Can you clarify?

I think a large part of Hacker News' culture is finding facts more interesting than opinions. We call this MYOO (Make Your Own Opinion), a branch of the DIY movement.

The problem with the "We report, you decide." model is that the reporter chooses what to report.

The messenger and the message always have a relationship. It may be irrelevant, but it always exists.

> The only good news found in this research was that after searching TV streams from seven different countries, researchers failed to discover any ultrasonic beacons

Would that even work? I'm pretty sure modern digital TV audio compression totally removes sound that is vaguely close to 'ultrasound'. I guess maybe smart TV apps could add the signal though, but why would they when they already know what you are watching?

It reminds me of a website for one of those annoying 'Mosquito' anti-loitering devices. The sound was provided as an MP3, which was of course totally filtered out by the compression resulting in a totally empty file.

Sky in the UK have trialed ultrasonic beacons in adverts, so it is definitely possible

They'd do it to connect profiles between the TV (which knows what you're watching) and any mobile devices within ultrasound reach (i.e. line of sight) of the TV. Do this a few times and it quickly becomes clear which phone is usually within range of the TV, and with that the profiles can be merged, giving a broader view of the user behind these devices.

The solution is simple: don't get a 'smart' television. Better still is to forego on television altogether but if you insist on having canned 'entertainment' (panem et circensis) beamed into your domicile make sure to use as dumb a device as possible. Any smarts you require can be added separately, the thing does have external inputs after all. As an added benefit you won't be stuck with a 'smart' TV running yesteryears OS on under-powered hardware while the display and sound system are still good for many years.

> don't get a 'smart' television

Will that prevent ultrasonic beacons? I assumed the speakers were the same on smart and 'dumb' TVs.

The smart televisions are far more likely to have code (or be updated with code) that can be used to emit unique tracking signals of some sort.

Sorry if I'm missing something, but television programming usually doesn't require code in the TV in order to emit audio. Is audio in ultrasonic frequencies a special case?

Although I can't confirm this myself, a few people here have mentioned that its likely that a digital TV signal's audio track would be compressed to remove inaudible ranges. This would require that any ultrasonic data be added by the TV.

From what I can tell, HDTV audio is typically sampled at 48kHz and compressed with AAC using spectral band replication (SBR) techniques. I'd definitely say it's plausible that signal could contain stuff outside a normal adult's hearing range.

AFAICT Yatenfou is saying that the ultrasonic tracking beacon is done by software on the smart TV and not actually part of the television signal.

The risk with smart TVs is (as an example) CBS approaches Samsung and asks them to push code that makes the TV do a particular hard-to-notice sound when it detects the logo of a specific show being sent to the screen.

I'm with you on not getting a 'smart' TV, but this comment reeks of elitism: "Better still is to forego on television altogether but if you insist on having canned 'entertainment' (panem et circensis) beamed into your domicile"

What if I want to play games, watch movies, or just sit down and otherwise enjoy myself? Is everything that comes on a screen an unnecessary diversion or is it just a screen of a certain size?

Your games and movies can be ultrasound beacons too..a board game cannot.

In what way is it 'elitist' to dislike the pablum ditched out by television channels? Strange, the way things go. It used to be that those who did not have a television set were seen as backwards but now it seems to be the opposite.

I never liked television programming, not as a child, not as an adult. There is nothing elitist about it, I just like doing things myself.

BTW, the mere fact that you're replying to a message I submitted to this forum should tell you it I do not consider everything that comes on a screen an unnecessary diversion, given the fact that the probability of me using a screen to read and enter text here is rather high. Television is quite well-defined as being a medium designed for mostly passive consumption of entertainment and information. It is the combination of hardware and a whole industry to provide programming to animate those screens. It is the latter, the industry and its products, which I dislike. The hardware can be quite useful.

Hell, I'd be happy if I could buy a dumb stove.

After a recent experience: that's simply not possible. Every damned kitchen stove on the market has electronics in it (failure-on-delivery of which in multiple instances spurred on the search), and increasingly: Bluetooth or Wifi capabilities.

Ironically, one thing the new stove improves on over its predecessor is that there's far less electronics hum coming from it. Though several appliances still emite some high-pitched, and ultrasonic (I'm sensitive to that) noise.

My stove is a dumb as it gets. It burns wood and produces heat. More wood and/or more air -> more heat. Living in the countryside has its advantages, I guess it will be hard to cook on a wood-burning stove when you live in a city or suburban environment - not to mention the problem of getting wood to feed the thing, even though it is really quite effective - the equivalent of about 1 m of 2x4 of wood is enough for a 2-course meal for 4 people (not that I feed it 2x4's of course). As an added benefit it heats up the kitchen sufficiently to be used as the only source of heat in spring and early fall here in the Swedish countryside.

The point remains that it is not possible to find, within a typical appliance store, a gas or electric oven/range which has no electronic componentry. I suspect your stove is not currently in production?

It's been suggested that if I were serious about a fully analogue stove I might consider a restaurant model. I'll keep that in mind, though these tend not to be sized to typical home dimensions.

And I suspect many of these are also increasingly being electronified.

While my specific cook stove is not produced anymore, others are, eg [1]

While my specific cook stove is not produced anymore, others are, eg [1], [2], [3]. The stove used for heating the house is available at any Jøtul dealer, as are plenty others.

Natural-gas burning cook stoves can be had at the likes of IKEA [4], not a bit or byte in sight on these things. Maybe things are different on this (European) side of the ocean? I do find a few in the US-version of IKEA as well [5] so there seems to be some choice left.

[1] http://www.amishcookstoves.com/

[2] https://www.agamarvel.com/heartland/products/woodburning-coo...

[3] https://www.google.com/search?q=new+wood+cook+stove

[4] http://www.ikea.com/nl/nl/search/?query=+Gaskookplaat

[5] http://www.ikea.com/us/en/search/?query=+4+burner+gas+cookto...

Good info, thank you.

Apologies for the late follow-up.

The plural is "circenses".

It's never going to be easier than it is today to buy a non-"smart" TV. It is going to get harder. In a decade, they'll probably be as niche and expensive, new-old-stock or refurb, as CRTs are relative to LCD panels now.

Its most likely not ultrasound, but just on the high end of what's supported by these codecs. mp3 and other codecs are biased towards human hearing ranges but support up to 30000hz I believe. Most people can't hear above 15000hz. Load up any 'dog whistle' app if you want to see this in action.

I imagine these apps use somewhere about 15k where some of us can hear it but really won't notice it too much during the 'empty' spaces between music, commercials, etc.

The middle aged and over execs and managers who approve of these schemes certainly can't hear it.

Does anyone have the link to the actual list? Neither the article nor the original paper seem to list the tracking apps, they just mention McDonald’s and Krispy Kreme.

Here's the top apps using silverpush: http://mixrank.com/playstore/namespaces/com.silverpush.sdk.a...

Lisnr: http://mixrank.com/playstore/namespaces/com.lisnr.sdk/instal...

And shopkick doesn't appear to be for Android. If someone has a link to the docs I can double check.

I just saw an ad for Shopkick yesterday on my Android. And this site says it's in Android.

http://app.shopkick.com/wr2/6Z48W52-6Z6LIDX

Unless it's something else with the same name.

This is why apps that shouldn't need the mic or speaker but still require it should not be installed.

Permissions on an app should be checked carefully by a user, and users should be educated in this!

That model is backwards. If there is one thing iOS got right, it's the permission prompt. Nobody reads those lists and it's hard to know what the intent is without context in the app.

Having the app ask on first use makes much more sense. It's much less likely to get away with this. Even better, you can still use the app if you say no. It will just get dummy values back.

On the flip side, this means you have already installed and committed to having this app on your phone. Lots of people might just press "accept" at that point out of being lazy, instead of uninstalling it and going back to the app store to look for an alternative.

If you ask me, both should be in place. When I install an app a list of permissions (and a short text next to each from the developer explaining why they need this permission), along with manual prompting once the app is installed and the thing in question (like the mic) is to be used.

Asking for mic permission with no apparent reason is scary, many people will not allow it. Also you can easily change it from the settings.

Apps on Apple App Store can't stop functioning just because of a permission is not given. If the app can't perform it's function without a specific permission the developer needs to explain it to the users and ask them to go into the settings and lift the ban.

So if an app that does not have a really good reason for asking for the mic, the use can just deny that permission and continue using the app.

No need for fishing in the sewage until you find the gold among the sh*t and it's my main reason to use IOS over Android(Though I hear its getting better).

I think Android 7 does now ask on first use rather than at time of installation.

1. build you app targeting earlier versions 2. No dialogs in any android version

This works the same since Android 6 (2015)

Only on apps that target Android 6 however. They couldn't retroactively apply it. Just build your app targeting Lollipop and you get all the permissions you want. Plus their app store isn't as strongly vetted, so apps can refuse to work if you don't grant a bullshit tracking permission.

This I never understood. Couldn't they just supply the app with empty lists and black pixels for restricted APIs until the user approved the permission? iOS managed to do this retroactively just fine.

I don't think iOS did it retroactively. It's just that, since so many more people actually update (because they're not at the mercy of their carrier), devs update their apps more often.

I believe you are incorrect. iOS have introduced more and more permissions (most recently, for iOS10 a permission prompt appears for apps trying to access the built-in media library, whereas this was a silent free-for-all in earlier versions), and existing apps are not grandfathered in. According to at least https://www.macrumors.com/2012/06/14/apple-requires-user-per... apps will just receive empty/dummy data until the permission is granted. From my personal experience, camera APIs return black pixels until the permission has been granted, even for apps that were released when iOS 5.0.0 was the latest version and never updated since.

I believe they do, but you have to specifically go into your settings and explicitly block the permission for the app and click thru a warning that the app might break, rather than ever being asked.

I don't remember when iOS did this retroactively, do you have an example? When have they even added a new permission that wasn't a new API entirely?

It's still broken.

First, there is no sane way to grant permissions "just for a few minutes" rather than forever (unless revoked). E.g. a banking app that has a screen with nearest ATM locations doesn't need GPS access granted all the time - only when I ask for the directions.

Then, there are apps that ask for just about everything (a long sequence of "grant AppName access to something") at startup. It's a subjective opinion but I believe this sort of "fix" to deal with the new permission model on SDK update was quite popular, as I saw it relatively a lot.

And it's good if denying access is an option and you just aren't asked the same thing again until you either give up or kill the app. It's probably not an issue if that's some flashlight app you can uninstall without even thinking about it, but isn't so much when it's an app from your mobile network, allowing you to manage your plan, or something unique enough to be considered valuable.

I see only two options how to fix this for real. First is more and more regulations. Second is improved app isolation and permission spoofing (silent mic input, empty contact list and filesystem, no persistent identifiers across reinstalls, etc), and activity indicators "app is trying to access the camera right now", "app had accessed your contact list recently" that would both raise alarm or allow to grant access, depending on the end-user decision.

Google doesn't even apply the permissions very tightly. App makers are happy to ignore recommendations(I don't think they're requirements) to work, even if not granted the permission. They just do things like prompt over and over or completely stop working if they detect they're given the fake, default data from not being given permission to things like your Contacts or Location. There's no user agency in Android 6.0+ permissions really, the apps can just hold their functionality over the users' head until they accede.

Also, Android permissions are strange. Like, why does an app need access to Contacts to use my Google Account to sign in? An account is not a contact and just because I want to let you unify my logins, that doesn't mean I want you to have access to my contacts.

Obviously the first problem is most users (almost 2/3) aren't using M+. However, that being said I do want to clear up some of your points about user agency.

It is true app makers are happy to ignore recommendations, but users with M+ are much more empowered. So, for example, if the app makes permission requests repeatedly, on the 2nd ask Android will provide the "Never ask again" check to auto deny permission requests. So if an app is being annoying about a permission you (the Android user) don't want to give you can silence the app.

Also, you can always deny individual permissions after you've granted them, which also includes apps that don't target M+. So if you don't think an app should require the Contacts permission then you can deny only that permission. You can argue that this is a "power user" feature, but if you're interested in app permissions I think M+ gives you the appropriate levers. And surprisingly, I've seen the developers who fix their app if enough users uninstall it and leaving a review citing poor permissions.

I forgot about the "Never ask again" functionality, that is definitely good for user agency but it would be much better if Google required apps on the Play store to function with real data or fake data. This includes having an alternate auth method if the user doesn't grant access to their account, especially in light of the following paragraph.

However, you don't really address my concern that Contacts is grouped up with Accounts when it shouldn't be. I cannot deny an app access to my contacts while allowing it to use my account to sign in. Android app permissions need to become much more granular and fully backwards compatible.

Ironically, I'm sitting here not upgrading my phone to Nougat because I really dislike the material design aesthetic of the UI. It's ugly, blinding white and turns every icon into boring circles. It also apparently breaks a lot of stuff that I use everyday.

cough youtube cough

Youtube has a video recording function, that doesn't work so well without the camera and mic

Clearly, that is better as a seperate app. 99.99% of viewers will never upload, much less use that feature.

It's still part of YouTube. And if Google is following their own guidelines for it, they won't ask for those permissions until you try to do something that needs it. Seeing as how I've been using YouTube for a while and have not been asked for those permissions, it seems to be working fine.

Or, of course, users could avoid installing apps altogether. Which, apparently, is the approach that many people take:

https://www.recode.net/2016/9/16/12933780/average-app-downlo...

It seems likely that lots of folks already realize 'experiencing the joy of the Krispy Kreme app" will not improve their life in any way, shape, or form.

It is these kind of "behind your back" shenanigans that will quickly force governments to move to regulating the industry, giving rise to a whinging chorus of "leave us alone" from the industry. An industry that has shown itself to be utterly untrustworthy, sneaky and aggressively invasive.

I see a need for a good, simple, slick and solid interface that allows you to select what functions an app can and cannot do on your device, be it laptop, tablet, smartphone, car, whatever.

> these kind of "behind your back" shenanigans that will quickly force governments to move to regulating the industry

These kinds of things have been going on for years, and yet the U.S. government, for one, just reduced privacy protections for consumers.

These kinds of things have been going on for years, and yet the U.S. government, for one, just reduced privacy protections for consumers.

True. I have higher hopes for the EU

My first instinct is that the signal probably doesn't need to be ultrasound. In the same way that my phone will sometimes hear my car radio and falsely hear, "hello Google", I bet the beacon can just be planted on top of the signal and match filtered to a decent SNR. Similar to image steganography, it doesn't need to be perceptible to the listener. Compression issues would exist, but at least they wouldn't be fighting against the transmission hardware.

But lower volumes would limit the range.

You don't necessary need ultrasound, but a modulation scheme to put the sound energy outside of hearing range. Ultrasound can be unreliable since phones have different frequency response that affects sensitivity. Also compression tends to apply low pass filter, so overall the range is quite variable.

To combat this, you can add forward error correction code, and have the audio source transmit data at low bit rate. Also, it's possible to modulate data using spread spectrum sequence (similar to GPS and ultrawideband) to reduce the energy below hearing threshold.

The state of the art is not to embed data at all, but use audio fingerprinting, aka Shazam.

> Their results revealed Shopkick ultrasonic beacons at 4 of 35 stores in two European cities. The situation isn't that worrisome, as users have to open an app with the Shopkick SDK for the beacon to be picked up.

Wouldn't it be far easier to just transmit a wifi SSID that encodes this information?

I suspect they wanted to isolate it so that people walking past a store wouldn't be counted.

it's interesting research, but there is no list of apps provided, only thing I could find it PDF of research is this:

100000+ SMS Messages Moziberg 2.4 1,000,000 – 5,000,000 McDo Philippines Golden Arches Dev. Corp. 1.4.27 100,000 – 500,000 Krispy Kreme Philippines Mobext 1.9 100,000 – 500,000 Pinoy Henyo Jayson Tamayo 4.0 1,000,000 – 5,000,000 Civil Service Reviewer Free Jayson Tamayo 1.1 50,000 – 100,000

so from those 5 with significant install base are minimum 3 targeted at Philippines market, the other two probably too, though they mention India

also note: Within the 1,320,822 Android applications, our scan yields 2 and 1 samples with functionalities of Lisnr and Shopkick, respectively. These samples are either applications that have been released by these companies themselves or by other companies officially collaborating with Shopkick or Lisnr. The user is thus aware of the deployed technology and needs to start the audio analysis manually.

so conclusion is, from 1.3mil tested apps, around 230 have this functionality, around 5 have significant user base and all of these are in third world countries (PH/IN). also according research many devices have issues detect these higher frequencies and they didn't find it working in TV streams or European shops. also from those 230 in most of them they use technology of Shopkick and Lisnr where you need MANUALLY start audio analysis. it's interesting research, but let's keep it in perspective

TLDR: don't give microphone permission to apps which have no use of microphone

Is it really ultrasound? Microphones on phones may be able to pick this but what speakers are able to play even 20 kHz?

And these apps should always listen, that will drain battery quickly, so these apps will be listed in top power-consuming apps and user will notice it.

18-19 kHz is usually high enough; smartphone speakers can play that fine from my experience.

Yes, battery drain is an issue. Most apps use a background service that wakes up at a fixed interval. The longer the interval, the longer the broadcast has to be though, so it's basically a trial and error kind of thing.

Another issue (besides the privacy issue) is that it may be annoying for pets. Dogs and cats can hear these sounds.

Also the apps on the phone have access to the microphone (even though they probably do not need this permission for any other purpose), so these apps are all potential listening devices.

i'm so glad you said this... made my day

Clock sync? Protocol usually is to check NTP and broadcast at prechosen times if you wanna keep the battery drain down.

I'm talking about the phone receiving a broadcast. The app has to be designed efficiently such that it minimizes network activity and doesn't hog the input audio stream. You also have the issue of trying to maximize the probability that a device in proximity to a beacon will pick up the full message. So you need some redundancy, which obviously increases overhead.

NTP sounds like it would work. As you kindly noted, just make sure the beacons broadcast at a agreed upon time and in fixed increments.

I wouldn't be so sure about users knowing, unless they are told. Plenty of users use apps that drain a lot of battery.

your first point coupled with diminishing free air range in bands above 40kHz makes this hack seem like a futile attempt to simply gather as much data as possible, as low or uncorrelated as it might be. Some phones might be more cappable than others, however, and air is dense enough for several meters of significant ultrasound transmission at low power. With e.g. Samsung TVs always listening, I wouldn't be surprised if they optimized the speakers and micros in that regards, while benign applications aren't out of the question either.

The second point however is an overly broad generalisation disregarding the technical inaptitude of the target group of such apps (wherein I might include myself).

I don't think people are using true ultrasound, e.g. 40kHz. In most cases, it's more like "poor man's ultrasound" at 19 kHz, Just outside the hearing range of most people. They have to stay as close as possible to the human hearing range to avoid audio low-pass filters and simple capability envelope of the speakers and microphones.

The article gives the example of speakers in physical stores, so I imagine they would be special ones that could transmit ultrasound. Additionally, the article states that phones are mainly just the receivers.

I understand why this sort of thing is uncomfortable, but for the last 15 years or so I've believed that the coming decades will likely see sensors everywhere, doing every imaginable analysis on everything.

Shouldn't be too hard, at least in principle, to enable a low-pass digital filter in the Android audio subsystem. There must already be one there for anti-aliasing when apps demand 16000 or 8000 samples/second capture. Just need to leave the 8KHz low-pass filter enabled for the 99% of us that never use the mike to capture music.

Reading the title, I thought "ultrasonic" was some evil site that paid for people to use their beacon...

Reading the article, it's actually worse!

This sort if things should be taught in school, don't give an apps permission to your mic, GPS, camera, contacts, etc... Unless you understand why. Not everybody will write "hello world" in JavaScript in their life, but most people will installed apps on a device.

Don't give Microphone permissions to apps that don't need them.

This kind of think has been fairly mainstream since 2014. https://en.wikipedia.org/wiki/SilverPush In 2013 there was PC malware that used this technique to jump network airgaps. https://arstechnica.com/security/2013/10/meet-badbios-the-my...

Google Play also pairs with set-top box devices like Roku using an audio mechanism, although I'm not sure if it's ultrasound. A series of audible clicks are present while pairing, so I'm assuming it may be a different audio or environmental-based encoding, maybe even just location -> audio correlation rather than data modulated over any kind of over-the-air carrier. Does anyone know more about how that particular setup works? It sounds similar to the Shopkick app in a lot of ways.

Sounds a little like one of Powa Technologies ideas before they went boom.

Embed inaudible tones in tv content to sell you stuff. Never saw the appeal.

But as we know the appetite for tracking is endless, foe some reason.

Facebook and Google's advertising revenues can give you some idea of the reason.

This is quite interesting and shocking too that we can be tracked from these apps. My question is, if it is so and many tech geeks here have said that if the mic let's say is irrelevant to the actual context of the application, so why Android App Store does not block this using AI or any intelligence techniques?

Side project idea: ultrasonic jammer. It's really simple, just use a piezo speaker and drive it with a small microcontroller (or an analog circuit) to jam the frequencies they're using.

The only problem is that dogs and other animals won't like it ;)

Is there a physical way to deactivate the microphone (on my tablet, I never use it)?

a thin, pointed device may do.

The destructive way: open up the unit and destroy the mic, either by prying it loose from the pcb, or just smashing it if it's too integrated. On my Fairphone I think it was a small metal box with a little hole on top.

The top answer to this question[1] has a few suggestions. The dummy plug idea is interesting, although it doesn't actually physically disable the microphone.

[1]https://security.stackexchange.com/questions/47345/surveilla...

Some sort of aftermarket high bandpass filter on the microphone will be necessary.

Would something like taping the micro stop it or the signal would get through it?

Unethical behavior: let people decide with their wallets.

should be illegal

how is this not illegal?

Probably because it hasn't been litigated yet. However the FTC has issued warning letters to apps which use similar technique.

https://www.ftc.gov/system/files/attachments/press-releases/...

Reply on news.ycombinator.com