App for bluetooth lamps needs location and network permissions?!?

DeletedUser143

Howdy!
I need an explanation about Bluetooth smart lamps.
I've decided to buy a lamp that would be BT controllable. Found one. Tunya Smart is the name.
Purchased, put into desklamp, installed the app.
And it does not allow me control the lamp without wifi and location permission.
And if I set the network permission to 'not allow' via app info the app doesn't even allow me to do a thing. So can someone explain me how a BT lamp is WIFI AND LOCATION ENABLED ONLY?

Aeon

DeletedUser143

Oh that's easily explained: Data harvesting.

From technical point of view a bt device does not need wifi nor location.

I would only get smart devices that can be flashed with alternative open source firmware for example https://tasmota.github.io/docs/ so you can control them with open soruce apps that are more privacy respecting

mmobder

DeletedUser143 from what I remember:
1 location permission is always required by Android/Google to pair / search for nearby devices.
2 "network" permission is granted by default in non-GOS world, thus the app devs assumes its "enabled" and thus the app is simply not expected to work properly. Why would devs spend hrs/$ to develop for a niche case like lack of basic permission in a niche OS?.
3 if the controlling app is "generic" and is not specific to this particular bulb, it's highly posssible that it doesn't keep information about how to communicate with particular device locally, as there are thousands of those tuya stuff around. So it requires internet to fetch details once it understands what device it is connected to.

so "oh yeah, it's just because data harvesting" is kinda detached from reality to say at least.

So, assuming GOS is a kinda niche thing, if you're really bound to the bulb, you can try your chances with #3 (if it appers the app has everything locally), block real network access via 3rd party "firewall" (like RethinkDNS etc) to ensure that app is not phoning home, then enable location, network access and try to pair/control the bulb. Thus you will be able to workaround limitations, except for the case described in #3 above

ErnestThornhill

Research is important. Looking at an app in an app store will show you what permissions it requires.

DeletedUser143

ErnestThornhill if it is written as required, it not always won't work without permission. unfortunately not in this case.

fid02

mmobder location permission is always required by Android/Google to pair / search for nearby devices.

This is simply not true.

fid02

mmobder location permission is always required by Android/Google to pair / search for nearby devices.

You probably meant the Nearby Devices permission.

Also relevant: https://developer.android.com/develop/connectivity/bluetooth/bt-permissions#declare-android11-or-lower

mmobder

fid02

pls put my answer into the context of OP's post as well as comments 2 and 3.
if you still consider it relevant, do you think your answer is rather on theoretical side (applied, maybe to 1% of apps of that kind), or on the practical side that makes sense in the real world of Google Play and non-niche GOS like the OP came from (99% apps of that kind)?

OP is wondering why is it happening. I'm saying #1 that for what OP is looking for (generic app for managing whole variety of smart devices), google will ask/force for a coarse location permission. And #3 internet access is easily explained (fw update for the BT device, download of communication protocol locally in order not to store thousands of Tuya devices, etc)

So, conclusion - access to location and internet are not necessarily reasoned by data harvesting. If you set OP's expectation this way, combined with possible soluition of "firewalling" the app (rethinkdns), you will not lead him to unrealistic search for something that barely exists, or is not maintained (like many FOSS projects) or is unreasonably complex to handle (like flashing tasmota, etc).

Take a look at FOSS GadgetBridge app, their manifest ask for ACCESS_COARSE_LOCATION and doesn't mention neverForLocation. Then re-read comments 2 and 3 that claims that all who do that are just harvesting data, thus, GadgetBridge does that too, right?
The same applies for highly-special Calor BT app that manages eq3 thermal valves - it also require coarse location and internet (to download firmware).

fid02

mmobder pls put my answer into the context of OP's post as well as comments 2 and 3.

I simply fact-checked one of your claims about the Android permission system and linked to a primary source so that some context to the topic could be provided.

mmobder

fid02 I simply fact-checked one of your claims about the Android permission system and linked to a primary source so that some context to the topic could be provided.

fid02 I simply fact-checked one of your claims about the Android permission system and linked to a primary source so that some context to the topic could be provided.

my claim is meaningfull and practically correct for OP's case (as we're here in this particular thread).
yours, though accurate (from developer point of view), is practically useless and misleading for a generic user. It creates false expectation that one can get away wihout location and internet access in a generic smart device management app from GPlay, OP is referring to.
So if an app like that asks for those two, it doesn't mean it's evil data harvesting (see Calor BT and FOSS GadgetBridge as an example). As simple as that.

BTW, Tuya Smart doesn't list ACCESS_FINE_LOCATION among required ones (unlike FOSS GadgetBridge).

fid02

mmobder my claim is meaningfull and practically correct for OP's case

You made a wrongful claim about an Android permission, implying that Android forces all apps to use the location permission to connect to nearby devices, and saying that the claim suddenly becomes correct when put into some wider context is not true. You're obviously intent on still arguing against a fact, and we're going around in circles because of it. No point in me writing more about that.

mmobder So if an app like that asks for those two, it doesn't mean it's evil data harvesting

You're reading way too much into my posts. To me it's obvious that you're correct in your argument that (to paraphrase my interpretation of it) "if X app requests Y and Z permissions from the user, and does not allow the app to function without those permissions being granted, it does not necessarily follow that X app will be using the data it collects from having those permissions for data extraction purposes". I think that logic makes sense, and I doubt that a lot of people will argue against it as a general principle. The fact that someone here is arguing that Tuya is performing "data harvesting" appears to be an assumption which, as far as I can see, has not been backed up by concrete evidence.

On the other hand, gathering objective evidence – without putting blind faith into the app developer's own statements – about what a closed-source app does with the data it collects is not something most people will know how to do. Moreover, you're relying on the collected data not being used for nefarious purposes after it has been potentially extracted from the app and landed in the hands of the app developer. In such cases, most people will have to rely on the app developer's privacy policy to determine that. According to Tuya's privacy policy, it does not share the data it collects with third-parties, with some exceptions. It's up to the user to determine if that's acceptable to them personally, and whether or not to trust that Tuya tells the truth about their data policies.