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.
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.