The only legitimate use case for location I can think of would be to pull down cable/tv/radio channel/station listings. But this shouldn't be a requirement since the user could easily manually enter in the ones they want. My guess is that something like this might be used as the pretext for requiring location. However, if the app continues to require location to function longer term (i.e. that this wasn't just an oversight which gets corrected in a future update) then I would assume that the real use case is something that has nothing to do with helping the user.
Keep in mind that many things including trivial flashlight apps have a history of wanting location access. There's usually a pretext in the form of some questionable/marginal feature that's used as a justification for the permission. Often after some digging the real reason becomes apparent in the form of data collection or an included ad serving library.
For example, I have a 'smart' thermostat which has an app that requests location access. I deny it and it still works. There's at least one feature they use to justify requesting it but I suspect that if there weren't other uses (having nothing to do with benefiting me) for location data that the feature requiring location data probably wouldn't even exist.
Maybe. Perhaps they fielded a lot of support requests related to getting Bluetooth and/or WiFi connectivity established before using the remote for the first time.
So it worked fine for this user, but didn't work well for less technical customers.
Too many apps ask for permission immediately without any context as to why they're doing it.
Technically, for example, an app may not even want to see all available SSIDs. Maybe an app just wants one passed to it. Sort of like a browser file dialog works.
The pop up text from the OS says it wants the user's location. That's not what it wants or needs.
This comment has some other examples: https://news.ycombinator.com/item?id=19216715
I could make an app that logs every phone call I make along with it's duration so it can recommend friends for me. I wouldn't expect that app's permissions dialog to read "Allow app to recommend friends to you".
Getting into the technical details doesn't work for average users, especially for cases like this where the risk isn't obvious - non-technical people will almost certainly not know that revealing local SSIDs reveals your location.
https://developer.apple.com/videos/play/wwdc2018/718/?time=8...
Browser wants to download a file, so I have to give carte blanche permission to access all my files. Why can't I just give permission to place new files with app-supplied content, i.e. no reading of existing files, no overwriting / deleting of existing files, and OS-managed name collision resolution?
The same applies to the camera app. And no, the camera app does not need to read my files to display a gallery of photos taken. The gallery app already does that, and Android is perfectly capable to re-using an activity (via intent) of the gallery app as part of the camera app without the latter gaining any permissions.
Maybe an option to open up a more detailed description of what the app wants the permissions for?
To a non-technical user, "Access nearby Wifi signals" (or something similar) sounds totally innocuous. Most people would approve that assuming that the app just wants to connect to the internet.
You could get more detailed and say "Access nearby Wifi signals, which could reveal your location", which conveys the privacy risk. But to the average user, "access nearby wifi signals" isn't adding anything - the only real privacy risk is that location is revealed, so it just makes sense to convey it as your location.
There's other cases where I think there's a better case for finer-grained permissions - some apps ask for phone call permission just so they can know whether you're a call or not - arguably something that should hardly require permission at all, but it's lumped in with one of the more scary sounding ones.
In this case, the phone OS could provide a similar interface for an app to pass off selection of an SSID or Bluetooth device to the OS, without giving away other permissions.
I think a jQuery update fixed it, but don't recall. It wasn't simple to track down either.
Disclosure: I work on a Sonos competitor [1] that tracks customer data purely for product improvement and is fully opt-out-able.
Frankly, this text isn't alarming enough.