Why does my remote control need to know my location?


Here's an interesting user-hostile pattern which could easily be avoided if programmers and business-people thought like regular humans.

I have a Pioneer / Onkyo sound system. It's pretty nice and comes with a (not too crappy) Android app to let me remote control it.

One day, the app updated itself. The changelog was the usual bland "bug fixes and improvements" message, but when I opened it, this happened:

Allow Pioneer Remote App to access this device's location?

Why does a remote control need to know my location? I assumed it was for some marketing bollocks, so I refused permission. Then the app refused to work.

Authority to access is required to play/display the contents and to get network information in App info.

Let's ignore the grammatical atrocities in the pop-up. Something that was working fine and is now broken because the app developer didn't think that people would dare refuse their demand for sensitive data.

I complained, along with several other users. A few weeks later, they published an update:

What’s New Change the permission indication of Device’s Location to be indicated only when needed. * In case of use Android 4 or 5, the permission indication will be indicated when install this App or update to the latest version. * Why Device's location is needed? Answer: In order to set-up your wireless devices which are located around you, SSID and Access Point info is needed. There is no other purpose to use the information of Device’s Location.

The new app works even if I don't give it permission to track me. Result!

Cause #1

The first mistake was Pioneer / Onkyo. They should pop up a message saying "Hey, we would like your location so that we can..." and then let the user make an informed choice as to whether to grant that information.

If the user refuses, gracefully degrade and provide some other way to accomplish the task manually.

Cause #2

Google, in its wisdom, has tied "Location" into things like BLE Scanning and WiFi scanning. The excuse is that you can use these things as a proxy for location. That is, if I know you are near access point X your location is probably near Y.

I appreciate that. But is there a better way to request the permission? "Allow WiFi scan? This might share your location." That's probably not the best way to word it - but the current situation just confuses and upsets customers.

This is a much complained about problem with Android. And one which won't be fixed anytime soon by Google.

Permission to speak freely

In the bad old days of Nokia, apps constantly asked for permission. It was a running joke that the web browser app would ask for permission to connect to the net, and then ask if you really wanted to connect to a secure website.

You think I'm joking? This was a common experience on Symbian:

A pop-up asking if the user wants to connect to https.

Android and Apple were meant to free us from this drudgery. With their carefully curated walled gardens, and double-checked apps, there was no need to bother the user with requests for permission.

Then this happened: A long list of unnecessary permissions requested by a dodgy flashlight app. App developers abused that trust and started cramming in needless permissions in order to exploit the user.

Users don't want to have to think about this. App stores don't want to police the apps they stock. Developers don't want to put friction in the user journey. Regulators don't want data being shared without consent. Users say they want to manage their permissions, but don't really understand the consequences.

What a mess! Perhaps I should find some AA batteries for the physical remote instead...?


Share this post on…

  • Mastodon
  • Facebook
  • LinkedIn
  • BlueSky
  • Threads
  • Reddit
  • HackerNews
  • Lobsters
  • WhatsApp
  • Telegram

3 thoughts on “Why does my remote control need to know my location?”

  1. There really isn’t a more granular way to ask for permission in this case. Giving access to scanning for signals around you enable the app’s developers to triangulate your position. There isn’t really any room for granularity in this system as you can’t separate one purpose from the other.

    You could conceivably let the OS handle scanning in a dedicated UI and let users choose the device they want to connect to from a list. However, hardly anyone would want to use a solution as complicated as that. Modern devices keep changing their MAC every couple of hours too so you can’t really grant access to a specific device based on their MAC address.

    A better design would probably involve connecting the sound system to your local network and let devices discover it using mDNS and DNS-SD instead. Apps can currently see all services on the network, and the OS could handle more granular app permissions by proxying service discovery queries and resolution. Apps could request permission (through their manifest and probably not by prompting users to specific service instance names such as _googlecast._tcp or _printer.tcp depending on their actual needs.

    Reply
    1. says:

      Connecting via network discovery is exactly how the app worked before the update.

      I don't see why Google couldn't expose an API to search for a specific set of MAC addresses. The one on my amp is not dynamic. Or tell the amp to broadcast a specific SSID to connect to.

      There has to be a better way of doing this than granting GPS position just to find a network.

      Reply
    2. Harry Bullen says:

      It sounds like the location feature is used to connect the sound system to the network. It is really hard to enter a wifi password on a device without a screen or keyboard so. The phone finds the device over bluetooth, and then sends it the credentials for connecting to the right wifi network. The app could of only asked for permission when you tried to use that feature which would of been much smarter but apps like this are written by the lowest bidder so......

      Reply

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.

Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">