Regarding Apple's App Transport Security (ATS)

[faultables]

Some users have reported (via app store reviews and other channels) issues with "App Transport Security (ATS)" and this is understandable.

First, "Insecure network connections" are allowed by ATS if the request is to private IP ranges as defined by RFC 1918:

• 192.168.0.0/16
• 10.0.0.0/8
• 172.16.0.0/12

You'll also need to confirm when the app (like flo) asks for "Local Network" permission.

Second, the CGNAT range (100.64.0.0/10) is unfortunately not treated as private by Apple's ATS. Some VPN providers such as Tailscale use this range.

Third, technically, a VPN connection is not considered "insecure" even if web requests are made using HTTP. However this interpretation is subject to Apple's implementation not mine.

Options

1. NSAllowsArbitraryLoads: true

This option bypasses ATS restrictions, but neither I nor the app should be blamed if something goes wrong. This option is unlikely to ever be implemented.

2. Use a TLS Certificate

Using a TLS certificate is highly recommended. It's secure, free, and follows best practices™

However setting it up can be challenging especially if reverse proxy is not your thing.

• If you're using Tailscale (me too btw), consider using tailscale cert. The setup is relatively straightforward
• If you're using a VPN provider other than Tailscale, you probably already know what you're doing
• A "CDN" like Cloudflare and others may help you to setup TLS certificates with one click

3. Other Options

If you still prefer not to use a TLS certificate for personal reasons, here are alternatives:

• Use Tailscale Subnet Router to advertise the private IP where your Navidrome server resides. This option will allow you to bypass ATS
• Most VPN providers use RFC 1918 private IP ranges, so you likely won't encounter issues in the first place
• If you're accessing your server via a public IP, consider to rethink your implementation. Refer to the Security Considerations section in the Navidrome documentation to learn more

Conclusion

There is no solution from the flo (app) side to fix this issue. This GitHub issue is provided so users can find answers to their questions.

[faultables]

related to #16

[jpdagostin0]

I don't understand why enabling NSAllowsArbitraryLoads should not be implemented. Maybe the user could just get a warning that the connection is insecure.

It's supported by Apple's documentation since iOS 9.0.

[faultables]

Currently, it's an error, not a warning, so there will be no confirmation. Setting NSAllowsArbitraryLoads will opt out of ATS, which I also don't understand why I should do

The thing is, I don't want my app to be considered "insecure" just because it's opted out of ATS enforcement, even though, I think, nobody will care?

Also, do you use flo to access the Navidrome server over the public internet via http:// if I may ask? And what's the reason for doing so?

[jpdagostin0]

I don't think your app benefits from ATS.

I access my server over http:// because I use Apple Private Relay so all device traffic is routed through apple's VPN. Though, the only security implications would be on a public wifi network. Even then, the server uses authentication and worst case scenario someone on the network sees what I'm listening to.

Finamp for iOS does not have this issue and I can freely connect to my server over public IP using http without TLS

[jpdagostin0]

Actually Finamp literally has the same flag. You should be fine.

https://github.com/jmshrv/finamp/blob/main/ios/Runner/Info-Release.plist

[faultables]

@jpdagostino thank you for mentioning this. But I still don’t think I will set the NSAllowsArbitraryLoads value in the near future. HTTPS offers more benefits beyond security, like HTTP/2 and QUIC, which require TLS to function. But still, it’s not my place to judge the implementation the user chooses

However, I’ve given three options above if the user still wants to access their Navidrome server via flo using HTTP. Do you think those options are good?

[jpdagostin0]

To be honest I am not familiar with the Navidrone architecture, but I can see how HTTPS could improve the UX if the server depends on HTTP/2 and QUIC. I think the options you mentioned are fine, and it is trivial to install the tailscale cert; I'm just lazy.

[faultables]

Great! I mean I'm listening to every feedback and will happy to implement it as long as it benefit for the users (including me). However, I don't see any benefit in disabling ATS enforcement

I agree that a better error message could help (right now, it uses the default: "Login Failed The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." which is too technical) and maybe a little explanation might also help some users

[faultables]

for future (Tailscale) users: #44

[39555]

I have also experienced this issue. Im using my custom lan dns server and a reverse proxy. I solved the error by providing local ip address http://192.168... directly instead of http://navidrome.home.arpa