[Photos] [iOS] Decrypting and encrypting photos no longer possible on v.1.3.54 using http

[valmir95]

My app was recently automatically updated to version 1.3.54 and suddently my photos were blacked out and could not be seen. I scoured the logs and found the following:

NSErrorClientException: the resource could not be loaded because the app transport security policy requires the use of a secure connection
[domain=NSURLErrorDomain, code=-1022], uri= [http://192.168.xx:8080/files/download/10000xxx](http://192.168.0.xx:8080/files/download/10000xxx)

Going through the stacktrace further, it seems to happen thumbnail_util.dart at the _downloadAndDecryptThumbnail function call.https://github.com/ente-io/ente/commits/main/mobile/apps/photos/lib/utils/thumbnail_util.dart

Seeing the git history (https://github.com/ente-io/ente/commits/main/mobile/apps/photos/lib/utils/thumbnail_util.dart) it looks like the change to the native Dio adapter were made. I am not sure this is where the root cause is, but that's how far the logs got me. The result of this seems to be that decrypts/encrypts are not allowed anymore. This does seem like a regression, unless this was intended, and http is not supposed to be supported? As far as I can see, it works flawlessly on the web versions and on the desktop apps (for Linux at least), so this change seems to only target iOS (not sure if Android is also plagued by this). Wanted to open an issue, but it specifically said to use this discussion forum here if it had something to do with self hosting, which it might be interpreted as being, seeing as the cloud solution uses https. Would be nice to have some clarification if it's indeed a regression that will be fixed, or an intended change.

[CoderDeltaLAN]

This is a regression from the switch to native_dio_adapter in 1.3.54 it uses cupertino_http under the hood on iOS, which enforces Apple's App Transport Security and blocks plain HTTP connections (that's the -1022 code) The previous Dart HTTP client bypassed ATS, which is why it worked before
No user-side fix for this without setting up HTTPS on your self-hosted instance. Quickest route is putting a reverse proxy in front with a valid cert, or using Tailscale which gives you HTTPS automatically on local addresses.Worth opening this as a proper issue since it's a clear regression for self-hosted users on HTTP.