3 ms·
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 th
by thombles 3y ago
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.
- Retric 3y ago“intending” seems like an unfortunate phrasing there. Is Android actually verifying this, or can this be used to misrepresent what’s going on?
- thombles 3y agoThe 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.
- russdill 3y agoIt'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.
- lultimouomo 3y agoAgain, 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.
- reaperman 3y agoI 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.
- qwertox 3y agoI 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.