Hi HN, this is my efforts in reverse engineering a BLE car battery monitor where it's app has over 100,000 downloads on the Google Play store alone.
It turns out it's sending GPS, cell phone tower cell IDs and Wifi beacon data to servers in Hong Kong and mainland China on a continued basis. Google and Apple app store pages say no personal data is collected or sent to 3rd parties.
Hopefully readers pick up a few tips on reversing apps for their connected devices.
Thank you for your effort. There also appears to be a BM6 variant which explicitly states that you get a personal account and will be able to track your car.
You can click the images where the third one contains a comparison. Interesting that they pretend that BM6 has this as a special feature since it just is a feature of the app.
Nice find. It appears the application is by the same developer [1]:
The play store page for this app states:
- No data shared with third parties
- This app may collect these data types
- Data isn’t encrypted
- You can request that data be deleted
I just checked the BM2 app (subject of the blog post series) and they have updated with the similar detail [2], updated on the 25th of June 2023, although they say the data is encrypted - will need to verify if this is the case with the latest release. It also still says data not sent to any third party. If they still use the Alibaba AMap SDK - then that's a third party.
The Apple app store also now discloses location data is being sent [3]
I'd like to think my research / blog posts put pressure on them to start being honest with their customers.
This doesn't excuse them though. A battery monitor does not need to know your location.
We'll probably never know but it would be very interesting to get an idea for their motivation to collect this data in the first place.
It's a fine line between data collection for commercial reasons and spying. Of course the mis-representation is an issue all by itself and Apple/Google should kill this app for that reason alone if they are going to be consistent.
The worst part about this is last I checked, Android requires location permission to connect to a BLE device. Presumably because BLE scanning can determine location.
As described in sibling's link, they finally corrected this in Android 12 with fine-grained permissions including a flag for whether you are intending to use the BLE for location purposes or not. iOS is now somewhat behind in granularity.
I think the issue is, or at least was, that Google assumes that if you are willing to share your location via BLE, which could be guessed by sniffing for BLE MAC addresses, that you're at the same time willing to grant high resolution GPS access.
I get it that BLE MAC addresses can provide very detailed location information, in my case my thermostats/valves broadcast MAC addresses all the time, so if they are sniffable, it is known that I'm at home, but this is not the case when I'm on my bike or in my car, where maybe there's the address of the bike computer or the car radio, because these are traveling along with me, giving no positional information.
Once I meet other people or walk around some streets, geolocated BLE MAC addresses will be present again, but it still isn't the same as high resolution GPS. GPS doesn't require an additional database lookup from a database which the "spy" may not even have access to, it directly sends latitude, longitude and accuracy.
It's annoying that Google neglected or still neglects this.
The docs note that certain kinds of beacons (which presumably would only be useful for location-finding) will be filtered from results. Otherwise I suppose it's just a soft flag for Play Store review or similar. There's not much you can do - if a given app has access to BLE scan results, it's very difficult to prove that it's _not_ deriving location from that either locally or on a server. I'm satisfied that it's usually going to be difficult though, with the possible exception of say, a supermarket app who plants non-beacon-like devices in their stores. However a user would probably raise their eyebrows at a supermarket app that asks for access to Bluetooth.
It's difficult to comprehend what's going on here without it being spelled out because it really is that dumb. For an Android app to connect to BLE devices, it needs the location permission. An Android app with the location permission gets access to gps location. It's not possible to allow an app to connect to a BLE device without also giving the app access to the location API.
Again, this is before Android 12 - afterwards the app can declare that it just wants BLE not for location purposes, and not get access to GPS (and apparently certain kind of BLE beacons). Still it's mind boggling that this glaring issue survived so long.
I don't think "granularity" is what should be optimized here. Apple has made the right call by telling the user in plain terms what privacy/security they're giving up. Something like "Allow BLE 4.0 with EDR?" obfuscates to the user that they're potentially giving a permission which allows the app to track them and connect to nearby devices.
Binning these to practical real-world "sacrifices" makes far more sense. I'd say Apple is ahead on UX, not behind.
Yes. Because BLE scanning can effectively be used to determine user location it is grouped into the location permission.
In theory it would be slightly harder to determine the users location if only BLE scanning was granted but I'm sure the Alibaba would have no difficulty getting more or less the same amount of location info.
Plus how do you express this to users? Do you call it "BLE Scanning" and try to explain that this reveals location information? Most users will miss that explanation. Or do you call both permissions "Location"? But now what is the incentive to request the lesser one.
I actually think that Google made a reasonable call here. If they both grant access to more or less the same info it makes sense to be behind the same permission.
Why do 100k people need a car battery monitoring app? The dial is right on the dashboard of the car, what does this app possibly do?! And drain your phone battery continously as well, is that really worth the ability to see on your phone screen what your dashboard already tells? And if it's for a stationary battery, why not just analog volt meter dial?
Sorry for complaining, but it's so hard to find standalone devices that don't require an app nowadays (simple example: try finding an LED lamp where you can choose the light color that allows doing it with a button on the lamp itself without app - I found one but it was non-trivial and it still doesn't allow color cycling without app). If people wouldn't prefer this BS, it would be easier to find sane electronics/electrics again.
The battery is there to start the (ICE) car. Its voltage under ~500 of amps of load is the relevant voltage. The voltage when the car is off is almost always irrelevant (it provides no guarantee about the ability to crank) and the voltage when the car is running is doubly irrelevant (alternator). What you want to do is watch and record the voltage dip while cranking, and this alone will give you a sense of your battery health.
If it's this important, does the onboard computer of the car not check this and warn if needed? If not, why not and why did humanity end up in a state where clunky apps are needed for this when the car already has all the electronics it needs for this?
People are accustomed to the coping mechanisms: aggressive battery replacement (on a schedule / at the first sign of struggle) or letting the battery deteriorate until the car fails to start and then asking for a jump / calling a tow truck. People see these inconveniences as inevitable, not as the result of a missing feature that really ought to be standard. Manufacturers don't feel pressured to do better so they don't do better.
If not, why not and why did humanity end up in a state where clunky apps are needed for this when the car already has all the electronics it needs for this?
(Almost) No one is making their car purchasing decisions based on the existence of a car battery health feature.
I mean, probably nobody looks at whether a stick to measure the oil level is integrated in the oil cap either, but it's still there fortunately (or do you need an app for that too these days?)
Unfortunately, a lot of vehicles these days, mostly high-end, do not come with oil dipsticks anymore[0]. I know that Audi starting switching to sensors-only around 2012, and I believe BMW started even earlier than that.
Why the f@#k on Android can't the user stop Apps from 1. Running at start up 2. Running in the background. At a minimum why aren't these user granted permissions?
This would stop a great deal of the apps that hover up data like this.
LineageOS used to be able to do this and more by spoofing apps with fake data as an independent permission system the apps couldn't bitch about. Google forced them to remove the feature.
It was a Cyanogen feature called "Privacy Guard" in later releases. The devs haven't clearly explained what happened but it was likely threats of losing access to Play services and the Play store. Play services is the poison pill Google uses to support invasive tracking and ad delivery and they won't abide any interference with it.
That's not how this works. Google has no say in the matter. Custom ROMs always come without Google apps. You flash them on top of the ROM yourself if you need them. The file they come in isn't specific to any particular ROM either.
This happened back in the Cyanogen days where they released it on actual phones (by Oneplus if I remember correctly). They included the whole GAPPS-suite and of course fell under that license agreement.
You are confusing CyanogenMod (the custom ROM for which you supply your own Gapps) and Cyanogen OS (the commercial version of CyanogenMod) that was used by the OnePlus One and OnePlus Two.
Ditto, would like to understand this. Lineage OS has much greater device support than Graphene. If you don't install Play Services why would Google have a say?
Yeah, mobile really sucks for this compared to the 90s and 00s desktop experience. It really feels like a step backwards; at least you could delete things from the StartUp folder on Windows 98.
Except Keychain credentials. I still don’t know how to make my iPhone forget how to log into Discord after deleting the app. (It logs back in after reinstallation.)
This is because each app has their own private keychain (separate from the saved passwords) which is not cleared when the app is deleted. Apple tried to change the behavior and have it wiped on delete, but many developers complained. This allows apps to track you across installs of the app.
That's...actually terrible. A bit of a search around seems to say that the only way to actually wipe it properly is the do a full device reset, which is obviously completely unacceptable.
It might be that Discord is remembering user information in iCloud in a way that persists following reinstall, similar to how some games save progress. Clearing the password entry would thus be insufficient.
Projects like this tend to be built by people with no interest in marketing, and for a non-profit I think it's fine to keep that particular sort of poisonous corrosion at arm's length.
And I don't mean it as a knee-jerk response, this is open-source, anyone with skills is welcome and if you send a pull request here https://github.com/GrapheneOS/grapheneos.org with the screenshots presented in the way you'd expect them, it might get merged.
- I don’t have a phone that can run it, I’m just curious but without seeing what it looks like it’s hard to become interested
- even if I could install it, there’s basically no chance I would install it because I have no idea what it looks like, because there are no screenshots on the front page
Yes. The librem 5 is a somewhat solid alternative. The pinephone seems to remain a developer platform as it lacks simple features expected out of a phone.
Something I experienced recently on Android was an app that every few hours kept popping up an alert saying something like "App X wants location data, so it has turned location on".
How is that even possible? I know apps can request location data to be turned on, but I was surprised the app can unilaterally turn it on. I couldn't find any way to prevent that.
These are the kinds of reasons why I can't trust any phones at all.
> There is no way for an iOS application to just say "turn on GPS" and be granted granular location access without user intervention.
Damn. Just like on Android.
The permission to always have location access(while closed) exists. Important for apps like Find My, etc.
But that has to be manually enabled per App in the settings. Apps can't even prompt for it, the location permission dialog only lets you allow usage while in the foreground. Also everytime your location is used in the background you get notified about it. So yeah, op either uses outdated android or enabled it manually.
And this is why we should never stop fighting for digital privacy and the laws that protect it. It's not a matter of "we have nothing to hide", it's a matter of not letting 3rd parties spy on you and sell your personal data without your overt knowledge and consent.
Makes no mistake, we're in the middle of an all-out data war now. Fight hard.
It's annoying that this has become the norm with basically zero consequences for bad actors.
Seeing this article made me thankful for GrapheneOS. I've been dailying it for a few months now. Every single app is explicitly granted network permission (or not) upon installation. Local apps like this definitely don't get network perms, and neither does my keyboard app (that always creeped me out.)
I'm considering switching to GrapheneOS but the fact that it only runs on Google phones makes me hesitant. Yet the other Android replacements look a lot less compatible. Am I being paranoid?
Not the person you replied to, but from a privacy perspective Apple won't allow Westerners to disable all network access per-app. Something that's been around in Chinese iOS releases for nearly a decade.
I'd love to use many offline note taking apps, but not if they're liable to randomly upload my notes to a potentially adversarial third party. And the actively privacy-hostile behavior of maintaining a separate branch just to disallow access to this feature is not appreciated.
Operating systems need to make Internet access a permission that users can grant or revoke. (Pretty sure that used to be a thing in Android, but never in iOS except mobile data.)
If I get a device that claims to use Bluetooth, I would return it if it actually needs access to the internet.
Android grant/revoke style permissions are a retrofit. You used to have to accept all permissions before installing through the store, and internet access was one of those. But if you didn't accept, you don't get the app.
That's still how it works for some permissions, but many have a grant/revoke instead. Internet access is still a permission, but google play doesn't prompt you for it anymore. All apps get to have it. (But if they don't ask for it in their manifest, it doesn't work)
Does it stop data from leaving your device or just collect it all as a proxy and refuse to forward some of it. I'd much prefer to not have to hand all my traffic over to anyone offering a free app and just trust them not to use/abuse it.
How these apps "should" work (IDK how this one does) is use the VPN API to capture traffic then filter it locally. The traffic should then leave the device as regular internet traffic, no VPN tunnel.
It's not a VPN service like the type you'd use for privacy. The VPN part all happens on your device so there's no data being sent to a third party for them to harvest to begin with.
Not sure if that is what you meant. If your concern is more generally about the app being malicious, I suppose you could audit the source code. But this is not something I have done or even am qualified to do, so I don't know.
I wouldn’t mind seeing the network requests made and received by apps.
For noobs it could show the domain, and if it’s whitelisted by apple somehow it is green (server certs?). Yellow if it’s not whitelisted and not on a banlist. Or maybe skip the colors if it’s too confusing for people, annd just show the names. Apps that request to banlist are blocked from App Store until further review.
and for pros we can tap to see more details, like the payloads and headers. Etc.
What do you think? I really want this feature. It’s not that hard to add. Come on apple.
Wish I worked at apple then I would try and do it. Lol.
Thats the silliest thing. Of all permissions, the really only 2 important permissions are: universal file access and network access. Who cares if it has bluetooth if it can't read or write data (outside of it's own app storage?)
I leave bluetooth off 100% of the time on my phones. It doesn't need file or network access to be used to track you. bluetooth beacons can be still log your device just by being in range, and that range can be anything from ~1 foot to tens of miles. Bluetooth is a privacy nightmare.
> Who cares if it has bluetooth if it can't read or write data (outside of it's own app storage?)
Bluetooth can allow external parties to detect it for tracking. I always keep bluetooth off unless I specifically need it and then turn it back off. Same for location.
Just having the ability to control Bluetooth allows your device to become a beacon, it/you/anyone around you can be tracked anywhere it/you/they go(es).
Although, not a user granted permission, sandboxed macOS apps have an entitlement[1] for network access. And Apple mandates sandboxing for all apps sold on the Mac App Store.
Edit: this seems to be part of my custom ROM, I can't replicate this in Google's Android emulator. That said, almost every non-Google Android distro seems to ship with some kind of switch to disable internet access for apps, though.
You can disable internet for apps on Android. Open the app details in the settings (or by tap+holding the icon in the home screen), tap the data usage, and disable network access (cell access, wifi access, neither, or both).
Making internet access opt-in would be a massive pain for most apps, because almost every app has some online component these days.
> You can disable internet for apps on Android. Open the app details in the settings (or by tap+holding the icon in the home screen), tap the data usage, and disable network access (cell access, wifi access, neither, or both).
I don't have these options on Android 9. All I can do is disable background access or allow access in data saver mode. The only way I can keep active apps offline on this phone is to put the phone in airplane mode when launching them
which is a much bigger pain than having an opt in.
Yeah, I thought it was a generic Android feature because both MIUI and my current ROM has it, but I'm not so sure anymore. I can't reproduce it in the stock emulator so I guess the feature either hasn't made it to upstream Android yet or it has been removed at some point
So does android, but a bluetooth scan requires location permission, and gives you the option for "this time", "while app is running" and "always" ... users probably just click "always" and forget
Didn't operating systems like macOS and Windows 8 _try_ to push native app paradigms where there were stricter permissions, but everyone hated it? How many people install software from the macOS/Windows stores where those checks could happen vs installing it the traditional way?
Google and Apple app store pages say no personal
data is collected or sent to 3rd parties.
"It turns out it's sending GPS, cell phone tower cell
IDs and Wifi beacon data to servers in Hong Kong and
mainland China on a continued basis"
It seems to me that app store providers should drop the "no personal data collected or sent to 3rd parties" language entirely.
Instead, the warning should be: "this app has permissions to do network stuff and can potentially send whatever the f-- it wants to whomever it wants" or "the app maker claims it won't give data to 3rd parties but we have absolutely zero way of verifying this."
Because the reality is that neither Apple nor Google can have any idea what a "3rd party" is. Those servers in China and HK may well be 1st party. Who knows? Who can know? Nobody but the app maker.
More importantly, simply expect that if you are touching any digital/electronic technology that touches China, you should expect that they are extracting and collecting every bit of available personal, location, and other data, and that it is available to the CCP. And, while the CCP likely does not GAF about your particular data, they do care a LOT about the aggregate data. They also will find it very handy when in intersects for particular targets, such as any of the millions of US govt employees whose data they harvested over years [0][1].
The Great Experiment, in which it was thought that open commerce and exchange would lead to democracy and freedom for China's millions, has failed, resoundingly. All it did was further empower a ruthless dictatorship bent on global expansionism. Do not do business with China.
Realize the thing that watches the thing is also slowly consuming it, to the point of it being necessary to actively monitor the monitor. (The BLE gizmo will slowly but surely drain your car battery. You must take action to recharge the battery when it eventually sends you an alert, because it will soon stop sending them to you.)
It also siphons data on your phone and sends it to China. Oh, and I bet that drains your phone battery. I can't think of a better anti-gift for the holidays. This gizmo is a rare triple consumer threat.
For a typical 70AHr car battery, the 1 mA from this monitor will take 8 years to drain the battery. When you get a "25% remaining" alert, you only have 2 years to recharge it! No, seriously, the self-discharge is about an order of magnitude greater than this monitor.
That might have been true decades ago, but modern ICE car batteries are designed for providing high cranking amps, not longevity under constant trickle. And even occasionally getting under 12 volts (12.6 is full) will damage them. That is the trade off of making the battery lighter and smaller. You'll notice that alternators and vehicle electrical systems have changed, too.
This is a big problem with aftermarket dashcams that continue to monitor the surroundings when the vehicle is parked.
Android warns the user that location related permissions are required. The issue is, is that this is required for Bluetooth scanning and the app developer abuses this by collecting other 'location data'. The app developer even tries to explain to the user with a pop up saying (paraphrasing) "click accept, so bluetooth will work".
Or they just lie to you 'we need your location data to do <sensible thing you want>' (like say localized weather or nearby starbucks or whatever) however they then turn around and basically track you constantly and sell your data to all comers.
That said, the attention of the blog post seems to have triggered them to disclose now on the Apple [1] and Google Play [2] store that they are indeed collecting your location data. They got away with lying for quite some time, over 100k downloads on Play store and 1.57k reviews.
This is horrendous. Android does it to make it clear, actually this is my best guess, that having access to WiFi and BT controls might leak location data based on, I assume again, where those BT and WiFi devices are located - ie by some kind of reverse search. And since that might leak why the hell not force user to grant the location permission anyway when they want BT/WiFi functionality.
I mean this is just retarded design. Unless there’s a “technical need” to use GPS while dealing with BT or WiFi that I am not aware of that.
There is a "mock location" feature in developer settings. As I understand it, you download an app that provides "mock location data" and select it, then it will provide mock locations in whatever manner it was written to do.
At this point its fair to assume that all these devices are collecting large amounts of data and phoning home. I wouldnt be surprised if TP Link routers also send everything back to China. But this is not limited to China anyway, the iPhone im using here is probably sending every keystroke and location data back to the US.
I’m not sure I like this pattern of thinking. For example, a TP Link router would send data back using packets over the public internet (unless there is some true spy craft at work). That’s verifiable.
If you suspect your TP Link router is sending everything to some remote server… monitor the traffic?
Like, how exactly? With a separate firewall between WAN and the TP Link? It makes little sense because TP Link makes cheap home routers and adding a firewall to the design would make the whole setup expensive.
Using a lab setup, not all the time. If you’re worried about these things you can reuse your lab setup to test multiple devices for “phoning home” packets.
Setup a lab using an old PC with two Ethernet cards, a WiFi card, etc. and observe the traffic flowing through it from the device you connect.
If it’s phoning home you’ll see those messages.
If you think it’s event based, or targeted surveillance, you’ll need to get more creative. But in OPs post it sounded closer to “logging everything and sending it all back” - if you’re already technically inclined that’s detectable with less effort than a lifetime of worrying about such things.
When my friends laugh at my obsession over privacy and data collection, this is the kind of thing I point at. There's no reason to believe they're doing this for malicious reasons, but we really have no way to know. It's probably just ignorance/incompetence.
Thanks! Part of my motivation to documenting this is to raise awareness and also provide encouragement for others to start looking at what their devices/apps in their home are doing.
The amount of location data the device maker is collecting is significant - perhaps they are monetizing it? If so, would you consider this malicious (if not disclosed to the end user this was happening)?
The AMap SDK the app uses collects much more location data - here I feel they are likely using it to improve the accuracy of their location service/mapping software. I don't consider this malicious, unless this behavior is not disclosed to users and developers. Their site is in Chinese [1], would anyone read through their fine print to verify?
That's my thought exactly: there's no logical reason for this to need to send your location, so it's probably monetized by AMap to improve location accuracy. The fact that it's not disclosed is worrisome but sounds more like incompetence or ignorance to me.
I haven't taken the time to fully dig into your posts, did you notice if they're generating a user ID? For me, that would be the difference between using it for location accuracy or tracking user locations. That being said, the data they already have is probably more than enough to track individuals.
Reminds me of this one post that I just can't find anymore: a (danish? finnish?) journal bought a pack of "anonymized" location data and chose one individual. They were able to track where they lived and worked, and where they went for vacation. They even went to their place and talked to them, and they had no idea this was happening whatsoever. I really wish I could remember where I read it.
Which is one in a series they did after some employees of a data broker or digital ad company (if I recall correctly) leaked a dataset to the New York Times because they actually were concerned about this kind of dataset existing.
It doesn't matter if the intent doesn't seem malicious. And if they had nothing to hide, why weren't they upfront about the data collection? Remember when we thought having all those Facebook "Like" buttons on every website was harmless until we learned the level of which everybody was being tracked without consent?
This is China's typical playbook. Purposely collect data in seemingly harmless ways, or intentionally leave wide open security flaws that they can exploit in the future. And when they get caught it's an "oops sorry, we'll fix it right away".
The worst part is that there is no consequence for this behavior. Google, the EU, and/or FTC should be lodging fines.
It is itself a special case or inversion of the tragedy of the commons when people share their data without thinking too much about it. It isn't applicable everywhere of course, but there is a price to adopting to the most naive.
For once, I really hope the US govt would do something about these sort of devices. I bought a digital picture frame from amazon. It's listed as having an SD card. When I tried to set it up. It wanted me to install an android app, and that was the only way to save pictures to the SD card. To connect the device to Wifi, then use my phone to send picture to the device. So nothing only would I have an unknown device in my network, collecting and reporting who knows what, it would be on my cell phone as well. I returned it. Imagine if there was 100k or 500k of these trojan horse devices in the US. It's truly scary what it means for US's national security.
Nothing to imagine, I am certain that there are 100s of thousands of such devices, and even if their design intent is not malicious they are typically security nightmares.
It doesn't matter if the intent doesn't seem malicious. And if they had nothing to hide, why weren't they upfront about the data collection? Remember when we thought having all those Facebook "Like" buttons on every website was harmless until we learned the level of which everybody was being tracked without consent?
This is China's typical playbook. Purposely collect data in seemingly harmless ways, or intentionally leave wide open security flaws that they can exploit in the future. And when they get caught it's an "oops sorry, we'll fix it right away".
The worst part is that there is no consequence for this behavior. Google, the EU, and/or FTC should be lodging fines.
I don't think it matters at all for US national security. It would be hard to imagine that the NSA doesn't listen to all inbound and outbound traffic in the US already and other nations don't do the same. Nationally sensitive information isn't going to be presented anywhere near these devices, thats still a "come to the office" industry unless you somehow have the clout to get a scif installed in your basement.
The metadata around peoples behaviors could be a very valuable source of operational intelligence when targeted at specific people.
For example: Imagine if you could track the security teams availability and behavioral patterns. You could infer when the business has been hacked or there is going to be a release they have been hacked, you could trade off this information for profit.
It would take some serious hollywood plot logic to come up with some actual business decision even if you had all of this information in front of you. Are you going short based on what time the security team is clocking into work or something? They could get hacked but you might have no idea when that will finally affect the stock price if at all. You'd be way better off just bribing someone from that company to tell you whatever, than to come up with some sort of model that actually indicates something reliable based on this metadata.
> You'd be way better off just bribing someone from that company to tell you whatever, than to come up with some sort of model that actually indicates something reliable based on this metadata.
You'd be better off hacking the company yourself if you wanted effectiveness.
Let me give you a lower stakes example, I can figure out when you're at work to know when to rob your place via when you post on instagram. Lower stakes but same theory.
That seems a lot less reliable and far more risky than just casing a house and seeing when the cars leave, since people often post on instagram after the fact. That's the thing with a lot of these digital "what if" scenarios. The confidence you have in your model is lower compared to old fashioned techniques that work well enough for far cheaper.
I've wanted many times a voltmeter dash gauge, something that used to be standard. A voltmeter will tell you if your charging system is working properly, and if your battery is dying. Having an app do that for you is like firing an 88mm flak gun at a cockroach.
I don't know why Apple cannot vet these apps for transmitting data irrelevant to its stated purpose before they approve it for the walled garden.
Get a red LED from any auto parts store. Connect it to the alternator and the positive battery terminal. It will illuminate when there is a voltage differential. Brighter is worse.
Optionally add switch if you want to prevent full illumination when vehicle is off. Or add a relay spliced into the radio / ignition / accessories circuit.
While I'm happy that apple and others have added these access grants (for location, disk access, etc) to their systems, I'm less happy that the way to do whatever the fuck you want is to ask the user to give you whatever grant under some thin pretext and then exploiting the fuck out of your generosity. 'We need you to grant us access to location services so we can adjust for your timezone... PSYCH! We're actually tracking your every goddamned move and selling all that data to all comers including law enforcement in your area!'
If you say no to these grants often the app will go into whiner mode, where it constantly asks and fails to perform even the most basic function.
What apps have done this to you? I've been pretty happy with Apple's ability to:
* Restrict permissions
* Prompt me with the ability to allow an app a permission forever, or just one time
* Have the OS prompt me later on about how often an app has been using my location, and ask if I want to modify my approval
I don't think I've run into many apps that have refused to work without something like locations services. If an app does do that, I simply uninstall it.
Their dashcams are optically fairly nice for the price, but their app is a monstrosity. It demands:
1) The ability to run unrestricted in the background, ignoring battery restrictions and autosuspend
2) Location access. Not "allow this time", it detects that, it wants perpetuity
3) Access to all phone storage. Not "allow this time", it detects that, it wants perpetuity.
If you refuse to grant any of these it will simply show you "the following permissions are required" and refuse to proceed. Do you simply want to have a live view from your dash cam to check the angle of its placement? Too bad. If you grant these permissions and later go back to settings and remove them, then the next time you start the app it happens all over again. It is an absolute abomination and I will never buy their products again.
Oh! I assumed your problem was with an Apple device; I haven't used Android in a long while, so I have no idea what the state of permissions is there.
But, like I said in my previous comment, I haven't seen this happen on my iPhone and I always deny location/bluetooth permissions unless there's a good reason for the app to have it.
That's an issue with how Android handles these permissions. Apple's system is much more fine grained, and my understanding is that it also has the requirement that the app must function without the user granting any additional permissions, even if the functionality is limited/restricted. e.g. if you have an app that wants to scan for local wifi networks (eg, sonos) and you don't grant that permission, the rest of the app still has to work even though you now can't set up new speakers.
Thanks for the reply here. I was just looking through the thread on Twitter. That was a great quick check, and I agree with your conclusion based on the information available. It seems like there's no BS going on :)
I'm actually looking at some Victron kit for a real-world application. I saw you're an Aussie. I'm based in Sydney, so if you're here as well then I can let you know in case you wanted to play with a real-world device in the future?
How is it that giving an app the ability to scan for nearby wifi networks is not a permission in and of itself?
The very first time it happened to me, it was confusing - hm, why does this random app, having nothing to do with connectivity, require bluetooth access?
Permissions should be more granular - and more importantly, Apple should make it so not giving an application a non-essential permissions is not grounds for not letting the user use the app.
Here I am specifically referring to the behavior of the app in question. As pointed out elsewhere, Android 12+ offers flexibility here. That said, it could be argued that there is too much trust for developers doing the right thing when Bluetooth and other location permissions can be mixed under ACCESS_FINE_LOCATION as we witness here.
I... just assume any bluetooth device that requires a vendor supplied locked-in application is exfiltrating every piece of data it can get it's grubby mits on. As the business model.
Unless it provably states otherwise. Is that a minority opinion?
AMap is the equivalent of Google Maps in China, so when Google started collecting wifi SSIDs and cell IDs on android and using them for faster-than-GPS or GPS-denied location determination, it was only a matter of time until AMap added it.
The article seems to be suggesting the device itself is gathering data and reporting back covertly ... but I believe it's just the AMap library included by the app developer doing its thing. In all likelihood, the data comes from phone sensors and is gathered by the app library, not from the device. And indeed, the Chinese language app logs on the Part 3 page only seem to refer to bluetooth and power related functions.
This supports a hypothesis of the app and device developers not knowing this collection is going on - ie. standard-library-using-developer not international-covert-surveillance-product-conspiracy. I think that is far more likely.
> The article seems to be suggesting the device itself is gathering data and reporting back covertly ... but I believe it's just the AMap library included by the app developer doing its thing.
If this is the take away, then I need to think about how I have phrased things. The GPS co-ordinates are sent two separate companies:
1) The Bluetooth device developer (bm2.quicklynks.com)
2) AMap (dualstack-cgicol.amap.com)
Looking at the decomplication and HTTP REST messages, it is very clear the app developer is deliberately sending GPS to their servers. They send a JSON object with the battery voltages, bluetooth device address and lat/lng in the same request.
The cell data, wifi beacon data - this is exclusively collected by AMap services and is not apparent without investing significant time reverse engineering their SDK.
Oh right, fair enough. So the actual breach of trust is the non-premium (non-tracking) app version sends GPS to the app developer, when they'd claimed otherwise and only the premium version is supposed to do so. This doesn't really justify delving in to device firmware, but more power to you.
I'm confused by what you mean here, could you elaborate?
For clarification - you purchase the hardware then you are required to download the phone application. You find this app by scanning the QR code printed on the physical device's box. This app is free. It does not link to a premium version.
I thought I read something saying there was a position-reporting version you could pay for. If that's the case, and they share an app, this is not surprising. If not, no idea where that idea came from. Anyway, phones = no privacy, app installed and reporting online or otherwise. Too many tracking vulnerabilities... every wireless stack (wifi/BT/cellular), platform accounts (Google/Mac), mobile network operator, SIM provider, SS7, etc.
The best way is to just start practicing. I would say pick some simple apps on your (Android) phone and dig straight in.
The great thing about Android applications is that often they generally decompile quite nice into human readable Java so the barrier of entry can be quite low to start reversing.
Grab a copy of JADX[1] - it will decompress and decompile the APK files. If you don't have an Android handset, use an emulator and/or grab APKs from apkpure[2]
Dynamic analysis is a bit more challenging. In my blog post I use Frida[3] extensively.
If you get started on something and get stuck/looking for support, feel free to DM me on Twitter (handle in HN profile), more then happy to help.
Phones already have app permissions: can access you contact, can access your location...
But no major phone OS provides a reliable "can access the internet" permission (without jailbreak/root). This would solve this issue much above the stack. I can install the dubious app. If the app can't access the internet at all (properly enforced by the OS) then by definition it can't leak anything.
I find it particularly disappointing from Apple. If they were truly committed to privacy as they claim, this would be a feature already.
A temporary workaround is to turn off Wi-Fi and the Cellular Data permission for the app. Once you know what it’s trying to reach, you can block it with an iOS firewall or something like NextDNS.
On iOS you can disable cellular data and it won't allow the app to connect to the Internet, and you can work on Wifi Assist to remove cellular data even on wifi
Pretty much everything that uses AMap does this - any popular Chinese-developed application with mapping functionality will exhibit the same behavior.
I have trouble seeing this as being quite as sinister in motivation as it first appears; while this data is certainly invasive and valuable, it's the same data that Google and Apple collect to build their mapping services, as well. It's a tough problem. I think the Big Issue exposed by this car battery monitor is the lack of granularity in mobile OS permissions. By granting the Android app BLE access, you also give it "fine location" access which lets AMap slurp your data.
I think this write-up is pretty good but I wish OP hadn't buried the lede as much in the first paragraphs. Why not mention it's AMap in the tl;dr summary?
Hey OP here - I mostly agree with your points in respect to AMap. It's a legitimate mapping service and location SDK.
> Why not mention it's AMap in the tl;dr summary?
The GPS data is being sent to two different companies - the battery monitor developer and AMap. I could make this clearer in the tl;dr.
The cell phone tower data (MNC,MCC,LAC,Cell ID) and Wifi BSSID collection is AMap only.
That said, none of the AMap behavior is disclosed by the application developer. Literally apps that use the AMap SDK in this way turns the user's handset into a continuous scanner. This impacts user experience - just check all the complaints on the 1.75k reviews on the Play store [1].
I doubt many devs are aware of this - It took me countless hours to figure the AMap side of things due to obfuscation techniques in the AMAp code. (See part 2 on the blog post series).
The primary issue is that all this data is collected, sent to multiple 3rd parties (AMap being one of them) and none of this was disclosed to consumers when they download the applications.
> For the application to work, you must give the Android application permissions that let it obtain location information otherwise it won’t work: For Bluetooth scanning, Android requires this permission
This is not entirely true anymore as of Android 12 (API level 32). See https://developers.google.com/nearby/connections/android/get..., which suggests declaring maxSdkVersion="31" for the ACCESS_FINE_LOCATION permission, since it isn't required for Nearby Connections in Android versions newer than that.
The hard part about locking down permissions after the fact like this is that it requires app developers to play ball. Forcibly blocking location access to apps that currently rely on those APIs to scan for Bluetooth connections would break a lot of apps, and not forcibly blocking it makes it easy for app developers to just continue requesting those permissions even though they no longer need them. Furthermore, users are already conditioned to expect location access permissions for apps that need Bluetooth so it doesn't even look suspicious, and there's a lot of outdated documentation out there telling developers to request that permission in that situation even though they no longer need it.
I know it has been talked about this many times, but any tips for readers on how to safe guard from such issues? What comes to mind:
- don't install apps unless absolutely necessary.
- don't let apps have extra permissions when possible.
- if app is free - most likely you paid for it somehow (your data)
Anything else?
I also use 1blocker on iOS to block trackers etc, although, I am not sure if 1Blocker is not spying on my browsing.
Very sound advice. What if you have purchased some Bluetooth enabled device that requires an app? Don't purchase Bluetooth/connected hardware? Perhaps!
My next blog post will be on a bike Speedometer that uses GPS to calculate the bike speed. It has an Android app, and yes it sends your data to remote servers hosted within Hong Kong.
Noob question, but was the application streaming over plain http, or did you do something to decrypt https traffic? How would you do the latter?
Edit: with mitmproxy and installing a cert in the phone's store, as explained in the latter half of the write-up. I guess that wouldn't work if the application pinned the server certs, but I guess this "commercial malware" is not that sophisticated.
In the second part of the blog post series, I show that they AMap SDK they use encrypts data data first using AES and then further encrypting the AES key(s) with a public RSA key embedded in the application. Not trivial.
If certificate pinning was used, it can be bypassed by modifying the APK or dynamically hooking into the running application using Frida. Often you have to try a few things before getting it working, often starting with a universal TLS bypass Frida script [1][2]
Really appreciate the write up. Just wanted to share, while unimportant…I still thought I would share, some grammatical errors near the top of the page
> reveals that that the Apple iPhone version is also location data to remote servers.
I’m guessing there should only be 1 “that” and there’s a missing “sending” between “also” and “location data”
The worst issue here is that Google and Apple do not seem to care that apps can claim "no data collected".
Should Google and Apple take some sort of care to make sure the claim have some validity if they require that info to be disclosed? Or it is just marketing to make us feel safe?
I suspect that all the location data stuff is to prevent someone pirating the app and building/selling their own hardware.
Sure, the Chinese manufacturer is a factory making gadgets on the other side of the world - they have no real avenue to monetize your location data. They likely don't even know your name.
Hence, my suspicion is this is all a complex way to stop someone else making a 'compatible' device and selling it without developing their own app. Thats why the app checks the mac address is valid, and uploads location data so the manufacturer can see if one device is in two locations at once, confirming piracy must have occurred.
Not directly related to this. I own a CTEK one car battery charger. CTEK is not some Chinese company but a very reputable Swedish company. Their car battery chargers are very reputable.
But the CTEK one has an accompanying App. Both are connected via Bluetooth like in this reversed battery monitor. You can add the battery charger to the app only, when you have a CTEK cloud account. Just this weekend, their cloud servers had problems. So you I was unable to connect to the local device in front of me.
What I'd like to say: CTEK requires a working cloud account to access their latest device via Bluetooth from within their app.
I am so sick of this I have resorted to putting almost all my apps on an old iPad (iOS being the lesser of two evils) connected to its own isolated guest network. My Android phone only has apps needed for leaving the house.
Could someone fill me in: why do people want to monitor their 12V battery? Is it just a proxy for “you seem to have left your light on”?
It honestly feels like a way to spy on family/company vehicles. Powered by the battery… knowing its voltage just being a side effect. But I guess that’s only if the app also tells you these data.
Less often used equipment/vehicles (say, boats or weekend motorcycles) are often put on battery tenders when not in use, to keep the battery fresh for when you do want to use it. Just yesterday my FIL was relating how he put his motorcycle on a tender because it had some parasitic drain that would flatten the battery in 3 days of sitting, for example.
This product seems to be a bit of an in-between, not having the ability to trickle charge the battery, but you can keep any eye on it and charge or jump it as needed.
I was in a warehouse of supercars recently. Stuff you had no idea existed. 10 offs, things like that.
Every vehicle was on a trickle charger, for a few reasons. But one reason I especially liked…
The La Ferrari CAN NOT run the batteries dead. If it does, and it’s locked, you are in trouble. Like call a Ferrari rep to come fly out and partially take it apart to get it charged and running again trouble.
Same with some Bugati I had never heard of.
Everything down to McCarens and lower. These aren’t vehicles that will run after sitting for a month let alone a few. Some might top at a week.
Wow that's surprising, especially considering most buyers would buy these things to drive a few times a year. It's not really something you get to drive to work or do you shopping :)
Every supercars owner knows to leave them on chargers. Or rather, everyone responsible for super cars leaves them on chargers.
One time, I had to change the oil on a McClaren… it has no dipstick, no oil pan, and you need to remove ~50 bolts and two skid plates to access anything.
They are art and engineering pieces that you get inside. They are not cars per se.
Yeah, I got tired of replacing batteries and now keep just about everything infrequently used on a battery tender. Lead acid as used in cars doesn't like being deeply discharged, so a couple good deep charges will trash them. A battery tender and extension cord is an awful lot cheaper than batteries, and a $30 unit will save you a lot more in battery replacement for infrequently used vehicles.
Also, they make the tractor a lot happier to start in the winter. :)
I know someone who actually has a few of these devices - they are big into their FWD'ing - they have solar panels on their roof and spend days 'off the grid'.
Another (more common) use case is people that take their caravan out on the road. Many have a plug into the car that keeps the caravan fridge powered on when driving.
For me, I wanted to keep track of the voltage of the battery in a caravan when not connected to mains power.
Even if it is, the attitude of ‘don’t install this app as it might track you’ is not a viable solution for it that classes of app. Reducing risk is one thing, but until regulation occurs there’s nothing to stop every app you use doing the same thing.
same here, I bought a Battey Tender solar charger and hardwired some SAE connections to my batter. I bought one of these to spot check the voltages at will CHAFON Motorcycle USB Fast Charger SAE to USB Adapter with USB C 18W PD,QC3.0 Quick Charge
https://www.amazon.com/gp/product/B087JCWX5Q/ref=ppx_yo_dt_b...
These types of gadgets are useful too in my other car where I can spot check the voltage when on the road and when charging USB devices 12V USB Outlet Qidoe Dual 18W Quick Charge 3.0 Port & 20W PD 12V USB C Car Charger Socket with Voltmeter and Power Switch, Waterproof Multiple Car USB Port Adapter https://www.amazon.com/gp/product/B0B1WJ3W5X/ref=ppx_yo_dt_b...
I'm currently looking for something to do this (bought one of these, it was junk and didn't work so I took it off) so I can have my Home Assistant installation keep an eye on it and notify my phone when it gets below some threshold.
Still looking for a solution, by the way, if anyone knows of something which will work (kind of thinking I want to go with ESPHome now though).
Renogy sells a 10A charge controller (https://www.amazon.com/Renogy-Wanderer-Amp-12V-24V/dp/B07NPD...) that frequently goes on sale for around $10. It has a RS232 port, and there are libraries for ESP devices and/or ESPHome that can read all of the (modbus) data from the controller. You need a serial adapter or level converter to adapt the serial voltages to 3V and a RJ-12 (6p6c) wire... or you could just buy their bluetooth module that does it for you.
Typically used for solar panels, but you could always hook up a 18-20v power supply and let it manage/charge your battery. The nice thing about these controllers is that they can handle multiple battery types and have multi-stage charging algorithms.
I've written a basic Python script [1] to read the battery voltage from this device. More details here [2].
Could easily integrate with Home Assistant. Might give it a go actually.
It reads the real time voltages, not voltages stored in the embedded device's
memory (for when there is no BLE connectivity while it's running). If there is interest, I can work out this part too.
Just want to add to the need of access_fine_location to scan nearby devices.
In fact scanning nearby access points or Bluetooth devices is much faster and more precise than GPS. If this sort of scanning could be done without requesting the access_fine_location permissions, it would be very misleading to the user. So I definitely understand Androids reasoning of requiring that permission.
Passive bluetooth devices can be used for very accurate indoor positioning.
In fact, I'm looking to set up a bluetooth LE beacon based positioning system at home to detect when I move between rooms and switch things like fans/lights/music.
Over a decade ago when I was in university there was practical experimentation going on into this form of indoor positioning (it was a project option in undergrad EEE), these days it's a done deal.
The OIAC (Privacy regulator in Australia) notes [1]:
> If you’re concerned your personal information has been mishandled, you first need to complain to the organisation or agency you think has mishandled it. If they don’t respond to your complaint within 30 days or you’re not happy with their response, you can lodge a complaint with us.
I have complained to the retail store that I purchased it from. It's been over 30 days, next is the OIAC. The device is rebranded and sold under many different names (globally) so the real impactful course of action is to have Google and Apple take the applications off the app store.
Update here is that the developers of this app have now updated the Apple and Google store pages disclosing that they do collect location data. So now it's up to the retailers/resellers to comply with local privacy laws and regulations.
Is it me or has this got nothing to do with the battery monitor. Sounds like run of the mill malware in the app, could even be the authors of the app are unaware, ie it’s embedded in a library they are using?
Huh, I think I bought one of these. Or a knock off of one of these. Either way, it's not in my car because it never actually read battery voltages (well it did, but evidently would crash after sending them or something).
> "Since the Android app requires location permissions to use the hardware device"
God because Blutooth LE devices need location permission on Android? How is that still a thing, I remember being outraged about that a decade ago or something.
Location permission is required because with Bluetooth access alone an app can essentially locate a device already by checking nearby device addresses against a database of known locations. Similar to how scanning WiFi BSSIDs can also determine location.
It's a tricky problem. As a more technical user, I'd love it if they were separate permissions and the Bluetooth permission included an extra "your location can be determined from bluetooth alone" warning. But for the average user that's just going to confuse them.
On Android apps that don't use Bluetooth to derive location, and assert that they don't, will not prompt the user for a location permission. But this app is requesting `ACCESS_FINE_LOCATION` in its manifest. It could be doing that because they're acknowledging they are using Bluetooth to derive location, but I don't think they are. I suspect what's actually going on is that they're requesting that permission just so they can show your location inside an embedded map view. In which case the permission is not related to its Bluetooth usage.
I do note that BLUETOOTH_SCAN could be used for versions 12+. The link you provided is good, I'll also reference that as it also has details on strong assertion (android:usesPermissionFlags - neverForLocation).
> I suspect what's actually going on is that they're requesting that permission just so they can show your location inside an embedded map view.
Does the embedded map do some processing in the cloud first? Because the lat/lng is sent over the same API request that includes the battery voltages as well as the BLE address of your handset. I really think none of this is essential to a simple app that reads a battery voltage on your screen.
> They will kick you out the store if they detect you're lying about the permission
You have to wonder how long this app never got taken down. Permissions declared in the manifest do not always equate to them being used.
Google could cross reference the privacy statement that the developer published against the manifest. That would have got it flagged.
The actual code that calls android.content.Context.checkCallingOrSelfPermission() obfuscates the permission strings in many places - bypassing static code analysis checks.
The manifest has ACCESS_FINE_LOCATION. When you run the application, the developer actually displays a popup saying to grant the permission so it can do BLE scanning to connect to the hardware device.
Of course they neglect to say they will also use the permission to collect your GPS co-ordinates.
Then the AMap location services SDK goes further collects MNC, MCC, LAC and CELL IDs (CGI) and Wifi SSIDs. Here I think the battery app developer does not even know this is happening, they use AMap SDK to obtain the GPS data only. It took me quite some time to figure this out (documented in part 2[1]).
Will also note the manifest has CAMERA, IMAGE_CAPTURE, ACTION_VIDEO_CAPTURE, RECORD_AUDIO and MODIFY_AUDIO_SETTINGS. I have not seen where/how they are used (yet). The code that included strings requesting various permissions (In the AMap SDK code) uses string obfuscation to conceal what it is doing. Likely to trick automated static code analysis tooling.
Note:
> Alibaba state “in 2018, Amap became the first Chinese maps service to navigate a path to 100 million daily users”. [2]
How are Google allowing this SDK to be used in developer's applications?
This seems like the problem? And it explains why the app can upload your GPS coordinates directly after querying the Android location APIs.
According to the developer docs, Bluetooth apps should only request ACCESS_FINE_LOCATION "if your app uses Bluetooth scan results to derive physical location". And if they assert that they don't use BT to derive location then the user won't be prompted with a location permission dialogue, just a bluetooth one.
This app isn't deriving location from Bluetooth alone? But I'm guessing it has an embedded map inside that shows your location, and that's why it needs ACCESS_FINE_LOCATION. Meaning it's unrelated to Bluetooth. From reading the docs linked by the GP it seems that for Bluetooth communication only purposes an app shouldn't request that permission.
Thanks for this: I've updated the post with a note on 'if your app uses Bluetooth scan results to derive physical location'. I highly doubt this is why they use ACCESS_FINE_LOCATION for this purpose. Rather it's an opportunistic way to get users to accept the permission - they tell users to accept it to get Bluetooth working when the app is first installed.
I wonder how many other apps on the Google Play store do this.
We can't expect the every day user to read and comprehend Google's developer documentation.
It always has been part of the manifest (Bluetooth permissions before, location permissions these days). However, even with the permission in the manifest, modern Android release don't just grant that permission on install; you need to ask the user for permission, and then ask them again for things like background permissions, and then display a continuous notification if your app is running in the background.
Just as with wifi networks, being able to see nearby Bluetooth devices is enough to figure out your location using publicly available databases like WiGLE.
Good point, and I assume this is why Google has taken this approach. That said, the more location data points you have, the more accurate the location (larger sample size, time proximity data - GPS is accurate always, SSID/BSSIDs can be out of date.
There is a huge difference from that to a device syscall getCurrentGPSLatLon() but I can see why Google would want to make their permission system as abtuse as possible
So… as I understand it… this is about Bluetooth beacons.
Bluetooth, it to require locations because if you passed by a beacon and an app is registered to the OS to watch it, that that is the same as reporting your location.
Your phone said “hey, app that the user installed, you know that BLE device you told me to watch for? Saw it just now!”
So it’s not it doesn’t make sense. Bluetooth low energy can be used to determine your location so you should have to give it permission.
The problem is… No one knows this.
It’s not even like there’s a solvable problem, because you don’t have to be using the Bluetooth low energy beacon format for this, you just need to be able to scan for advertising BLE devices which the OS does all time. Remember the rush to turn Covid Tracking on (Covid is over, but those changes aren’t going away).
This is how Tile and the Apple Tags that killed them work. Those are just roaming beacons.
Tons of apps that you install for major retailers, Home Depot, Target, Walmart, Best Buy all know exactly when you walk in the store if you have their app on an location services given into it.
Don’t install apps. Not unless you have to. Then questionable permissions aren’t an issue.
I wonder if and if so, how, they get around the notification iOS sends after an application tracks location in the background (‘Background Location Tracking Transparency’).
Because it's not always used for monitoring the main battery in a car. If you have a caravan, camper trailer, boat, etc with a battery in them then you often want to know what the charge is, but they don't have OBD2.
Why would a caravan, etc have a battery you ask? Inverters, lighting, fridges, USB chargers.. Lots of reasons.
Because that's what "consumer tech" has turned into. An excuse to lie to end users as much as you can possibly get away with, to collect as much information from them as you possibly can, gatekept by companies who do not care in the slightest about any of those, unless it makes bad press for them, at which point they "promise to try harder to not get caught doing this in the future."
And they don't even try to hide it. It's just that nobody looks.
> Note: Since the BM2 does not use HTTPS, there is no need to even install a certificate. What this means is that anyone can independently identify that their latitude and longitude co-ordinates are being sent on either iOS or Android with no modifications to their phone.
"Anyone can independently verify." And also, anyone on the network connection between you and the server can help themselves to this data.
Stallman was right. You absolutely cannot trust closed source to protect the privacy of your data. Reject all platforms that are not fully open, and reject all devices that come with any amount of closed software or firmware. Reading some damn "location privacy policy" is not going to cut it. Such policies are written by lawyers who lie by omission all the time. E.g. as soon as location data is "anonymized" the policy no longer applies. Which is of course a steaming lie. Location information cannot be effectively anonymized without basically nullifying its utility. Guess where that car parks? In one of two general locations for > 18 hours a day, usually. Gee, I wonder who that is. Even with 100m of noise, it's uniquely identifying of you. Don't even think about mobile phones that are accurate to the meter, tricked out with WiFi, accelerometers, and barometers. They are wireframe god mode tracking devices given the accuracy of sensors these days. What a nightmare to have these in everyone's hands and run by big tech.
It's worth a try though to push back. We are not talking holding off a bunch of murderous Russian troops. It's not a good look trying to recall " ... and they came for me" either.
Just push back. Here's an example: Reolink are a Chinese company, what makes cameras - nothing intrinsically wrong with that but you should expect them to be be required to comply with any requirements the CCP might ... require. Reolink are also quite a savvy bunch and have gradually ensured that their products don't actually require an internet connection, at all. They do offer an app and the requirements of using the app are that the cams need to see the interwebs and be gatewayed by systems that are eventually subject to the CCP.
Now this isn't quite yet perfect. Rio cams have offered ONVIF for at least five years, so Zoneminder, Frigate and all the rest can be your NVR. The camera's VLAN can be firewalled off from the internet. Mine is called THINGS and it is net door to SEWER for stuff I really worry about!
Their doorbell offering is pretty decent but two way comms needs some handling. At the moment their app is the best bet for functionality but there are signs that Home Assistant with webrtc - https://github.com/AlexxIT/WebRTC should be OK.
It is not impossible to live without prop software. At least care and try.
There are plenty of times however where you can choose between open and closed source, and in those cases its best to chose open and support that sort of development.
I would love to see a world where all of those things use open source software and hardware. It would take a long time to make it a reality, but I see a path to that where more people are out there today making successful open source hardware systems and learning the parameters of how to fund them and financially maintain development.
> ...the anti-abuse options are usually more expensive.
So you can read into that, "This is how profitable it is to abuse your users."
Smart TV companies make more money selling behavioral data now than they do selling TVs. Streaming stick companies are the same. Roku basically gives hardware away at cost in exchange for the juicy data streams coming off it (their "how we sell your data" "privacy" policy is a hysterical read, they grant themselves permission to scan your network and report other devices on it should they care to).
The more practical advice at the moment seems to be "don't buy anything with an internet connection if you aren't 100% OK with it tracking your every movement".
Seems like that's only going to last another year or two with 5G and shit like Amazon Sidewalk making every single device internet connected.
>Stallman was right. You absolutely cannot trust closed source to protect the privacy of your data.
People are fully accepting of data gathering when it's out in the open. Trust doesn't have anything to do with it, people are consenting to this kind of thing openly, and when something does come out they do not care.
> Location information cannot be effectively anonymized without basically nullifying its utility.
I was under the impression that properly anonymizing location data includes aggregating a sufficient amount of individuals and the radius of this aggregation of course changes based on the population density in a given area. In with anonymized location data we can only draw conclusions on a populace and not an individual, which is still very useful.
Of course, I generally agree with you. In most cases it won't be done properly and just replacing PI with the same "anonymous" id on a set of location data points of an individual achieves next to nothing.
You shouldn't just automatically trust it, but it allows you to examine what its doing and make your own informed decision about whether or not you can trust it. If you discover your data is being collected in an open source project you can, at the least, make an informed decision and give consent to it.
And while everyone won't be able to understand what they're looking at, the community as a whole would benefit from people looking at it an announcing/discussing problematic things they see in the code base.
If an open source project is syphoning data, someone's going to see it and talk about it.
If a closed project is doing it, it's harder / more complicated for that act to be discovered.
But how can I trust “the community”? I don’t know them. I don’t know their capabilities, nor do I have any say in what they check: whether it’s complete, or accurate; whether the software has been compromised since the last time the community checked; or whether they did the checking they said at all.
and on Github too, or some other public build mechanism. The thing of it is, is that if it's open source, but the binaries are built privately, there's no guarantee that the binary actually came from the source that's been presented.
This is very true.
I make an effort to point out that MITM proxy now supports Wireguard [1] to tunnel traffic out from the handset. It literally should take no more then 5 minutes from download to packet inspection. Of course if TLS is used by the mobile app then on iOS it's a few more minutes of setup time. Unfortunately with Android, installing your own certificate in the trust store is no longer trivial.
As you point out though, the application doesn't even use TLS for sending the GPS data.
In part two [2] of the blog post series, the Alibaba's AMap SDK uses both TLS and custom encryption and this took me quite a few days to figure out the Wifi and cell data collection - so it's not always so trivial. Either way, I recommend to everyone to at least do a basic 'desk check' on the apps they install. You never know what you will find.
Sadly certificate pinning is becoming pretty common in my experience. Most of the "big apps" do it. That means that even if you trust your own CA you still can't MITM the traffic. On iOS you need to jailbreak a device to override cert pinning.
Funny how mechanisms that increase security also remove some of the freedom and visibility we have into our own deviecs.
Most defiantly. iOS is a different kettle of fish.
Same challenges are present with performing forensics on an iPhone! The top commercial forensic toolkits will try to jailbreak the handset if possible to pull off artifacts. Good luck on newer hardware with the latest iOS versions. [1]
On the topic of iOS forensics, you can still get quite many useful artifacts from iOS backups with Mobile Verification Toolkit [2] being quite exceptional. I have had less success with iOS backups and the popular iLEAPP forensics software [3].
Thanks for those great tools recs. Had never seen mvt before and I'm running a check of my local iTunes backup with it now! (Funnily, this seems one of the easier ways to backup my text message history into an easily searchable form)
If you haven't used it before, Timesketch [1] is excellent indexing and searching timeline data for forensics analysis.
MVT takes a (MACB) timeline of your phone backup file changes and other events - including your text message history.
Here is a simple script that I wrote converts it into a format compatible with Timesketch [2] so it's trivial to explore events from the phone, indexed and searchable by time, kind of what you would see in Kibana.
My experience is mostly limited to iOS where adding a trusted root CA is relatively easy. It's uncommon for the average app, but most of the big ones do it. iOS itself cert pins most things as well. But on Android, since adding a new CA is much harder, I'd guess fewer apps do it there.
This kind of generic emotionally-charged flamebait is appropriate for Reddit or the YouTube comment section, not Hacker News. There's no useful information in this comment, and it doesn't inform others or satisfy intellectual curiosity - it's just there to stoke up anger.
Establish financial liability for products that engage in opt-out data collection. The liability should be shared by the manufacturers and by any resellers (especially including Amazon in the US).
Make sure the financial liability is at least the maximum of 100x the value of the data and 10x the revenue the suite of bundled products generate.
Also, criminal liability for everyone involved. Put every single employee and exec of these companies in jail for 10-20 years, with the first one to tattle on the employer getting a pardon.
And suddenly, a new style of ad: "Work from home! Be your own CEO! For a mere $5000, we set up your company, brand our products, and you get all the credit! No technical skills needed, just a bank account to receive your monthly income!"
Regulation is the only way to solve this issue, and regulation requires the people in power to care, where currently almost none in non European countries do.
This looks like fraud by Amap and negligence by Google (and Apple). The 100k users have cause for a class action. However the upfront cost of such a thing is prohibitive.
There is also the possibility that this is a national security issue. Exfiltrating location data to China for 100k Americans, probably including government and military employees, violates the law. But again, it's all about the cost. Also ambivalence (as others have pointed out).
The issue is that once again the permissions model as implemented on phones is complete garbage. Showing a list of permissions with "accept" as the only option is brain dead.
Google easily has the money and engineering resources to provide a complete fix to this issue (multiple spoofing options, deny options etc.) but of course they don't want to - because Google's business is advertising and advertisers want your location data. And your frequently visited locations. And wifi networks. And probably brand names of whatever is on your network.
We desperately, desperately need to get open-source considered as a national security agenda item. We need hardware vendors forced to publish full interface specifications. We probably need to require firmware blobs to be open source and tell Nvidia and AMD to stop breaking the law (i.e. they both suspect they'd be done for copyright/patent law if they had to publish their source code so they don't).
> The obvious answer is just stop buying this junk, but how would anyone know?
You don't have to know. You can safely guess. Assume anything "connected" is shouting as much as it possibly can, upstream, at all points in time. It's a cell phone app? You have location services turned on? It's streaming your position. Also, whatever else it can grab. Basically, if you've granted a permission to an app, assume it's streaming that attribute upstream, and keep things limited.
And, at all costs, prefer offline only devices. It took me a while to find some air quality sensors for my home that weren't online and App-based - but they're literally standalone displays that sniff the air and report out PM2.5/PM10/CO2/etc. I can't access them with an app, I have to walk past and look. So be it. For voltage of batteries, ffs, just use a voltmeter, or, if you care about always seeing it, install a little bulkhead voltmeter. I do this on all sorts of projects (most recently a "power toolbox" I use for stuff - battery, inverter, solar charger, USB ports, and a little voltmeter that shows pack voltage when it's powered on).
And then leave your little pocket snoops behind on a regular basis. I've gone back to carrying a regular watch on my wrist, or, when I'm feeling spicy, a pocket watch. And no cell phone, or a turned off cell phone in my backpack or something.
> Is this even solvable?
No. Because (a) most people don't care, in terms of actions they're willing to take. This app in question has had hundreds of thousands of downloads, so clearly the devices are popular enough. Saying "I care about my privacy!" is one thing, but actually living without 30,000 apps installed on your phone (shoulder surf when people are scrolling their screens in public places - I've watched people on an airplane with a iPad Pro Max or whatever have literally 20-30 screens full of icons) is pretty uncommon. and slightly inconvenient.
And, (b), politicians are largely in the pay of tech companies, or at least believe the lies about how they're bringing people together and will self regulate and... whatever.
The solutions are simply to opt out, or start using more aggressively hostile-to-profile things. Waves from Qubes-OS in a disposable VM
I don't have any other good ideas. The tech ecosystem has rotted, and I don't see any redemption for it. I work in tech, and I've been engineering my life to require less and less computer use, and I genuinely look forward to putting down a computer for the last time.
You can't clone them cheaply without the subsidy the data provides. These products are usually cheaper than they should be because the manufacturer knows they can get value out of the data sale.
Not this one, though. It's actually surprisingly expensive for what it is. One could build this with an ESP32 and a couple of jellybean parts to regulate the voltage to what the chip needs and create a voltage divider. Even with a case, it's less than $15 BOM.
You'd have to write the phone app, but that would be as complex as you wanted.
This is the result of "intellectual property" laws (which exist entirely outside of capitalism) being used by design. It's no surprise that when people have access to your computer and you are not legally allowed to know what they are doing with it, they abuse you.
I donated actual hard earned currency to my socialist candidate. Predictably futile, but I can state that none of this shit is my fault or what I wanted.
It turns out it's sending GPS, cell phone tower cell IDs and Wifi beacon data to servers in Hong Kong and mainland China on a continued basis. Google and Apple app store pages say no personal data is collected or sent to 3rd parties.
Hopefully readers pick up a few tips on reversing apps for their connected devices.