Allow connection to internal URLs without forcing exact location permissions

[Rhandos87]

iOS device model, version and app version

Model Name: iPhone 16 Pro
Software Version: iOS 18.1.1
App version: 2024.12 (2024.1032)

Home Assistant Core Version
2024.12.1

Describe the bug
Since updating to app version 2024.12 for internal URLs to work the app now forces users to
a) enter an SSID
b) grant exact location permissions at all times.

Getting forced by the app to permit always-on access to my exact location for my internal URL to work is a huge privacy red flag for me. I do not want to share such sensitive data with an app unless absolutely necessary for its purpose. I do not use nor plan to expose my HA instance to the internet so setting up an external URL is not an alternative for me.

If this change was made for security reasons I am not sure how reading easily spoofable SSIDs is a good tradeoff against granting the app granular location access all the time, even in the background. There should be a better way against protecting to malicious internal IPs on foreign networks if this was the rationale for this change.

Please let users use internal server URLs again without forcing them to grant the app permanent access to the device's exact location. Thank you!

To Reproduce

1. Add new server with an internal IP as the internal server URL
2. Add network SSID
3. Do not grant location permissions
   Result: The app refuses to connect to the internal IP and shows an error telling the user that there is no URL to connect to. In the server settings a box with red text asks the user to enable always-on exact location permissions for the app in order to read the SSID.

Expected behavior
Let users connect to internal IPs without forcing them to enable access to the device’s exact location.

Screenshots

[bgoncal]

Unfortunately Apple requires that level of permission to access SSID or hardware addresses (for macOS) at all times, such as in background, without that we cannot determine if you are on your local network.

This change came as a short term security improvement since many users have their internal URL without any encryption, and then when they leave their homes the app may try to reach this internal URL (in case they don't have an external URL) and exposes the token to the network they are at that moment.

Your situation has a simple solution if I understood correctly, just set your external URL to use your local IP, everything will start working again and no location permission is required for that.

[bgoncal]

Just a complement, you can choose location "While using the app", but this will make any background app interaction to fail in case you don't have a remote URL configured in the App.

[gwww]

I'd also like to see this design choice looked at again. Personally, I configure access to my server with two entries. One when local and one when on VPN (TailScale).

I had location turned off until this latest update for two reasons. Privacy and battery use.

Is it possible to add a checkbox to enable automatic switching between internal and external? That way people can choose to have to turn on location.

[bgoncal]

@gwww if you use through VPN you don't need 2 URLs right? You just need to set the external URL and it will be used all the time.

I'm considering adding a toggle like "Ignore local connection check" to ignore concerns described in my previous comment and allow internal URL anyways, I'll keep you posted.

[bgoncal]

And just to be clear, location permission was always necessary to detect when to use the internal URL, the only difference is that, before, we were defaulting to internal URL when external was not available.

[gwww]

I have two servers defined to access my single instance of HA. One has only a internal URL, used for internal access - which worked without location permission because I only defined the internal URL and left the external blank. The second entry only has external URL - a tailscale address.

I just tried a workaround. For my internal access I populated the external URL instead of the internal URL and turned off location -- everything worked that way.

[bgoncal]

Yes that is what I meant, let's ignore the name of the URLs, we have URL "A" and URL "B", "A" can only be accessed if we can detect if you are on your local network, if we can't we will use "B" or use nothing if "B" is empty.

[Rhandos87]

Thank you for your explanation bgoncal. So if I understand this correctly private IP addresses or reserved loopback TLDs like .localhost are acceptable entries for the "external URL" field and can be used there without disadvantages besides the potential token exposure you described above?

[bgoncal]

Correct

[tache]

Linking my comments to this under issue #3259

[tache]

And just to be clear, location permission was always necessary to detect when to use the internal URL, the only difference is that, before, we were defaulting to internal URL when external was not available.

This is only since you are trying to discover via the SSID. You need that permission since the SSID can exactly pinpoint a users location. Many people do not want to provide that permission.

If the app behaves like all other apps, via DNS resolution, you do not need those permissions. If the internal URL resolution fails, you are not on the internal network. It should then fall back to try to attempt connect via the external URL.

[bgoncal]

@tache what if you are on a public network and someone hosted a fake home assistant to hijack your token?

You can imagine that people usually have internal URL such as:
192.168.0.xxx:8123

So my example above could easily happen. Resolution would succeed. But it is not your HA server.

SSID is not perfect but it is the solution in place app-wide right now, and again, we will provide an option to ignore that and just fallback to internal URL if you need/want.