ATS and HTTP connection

ATS does not allow HTTP connections by default unless the Info.plist is configured to permit it as an exceptional case. However, I'm working in a slightly unusual situation where my code is running as a plugin to a host application on macOS. Although the plugin bundle includes a Info.plist, ATS appears (probably logically) to be referencing the Info.plist of the host application. Plugins are naturally not allowed to modify this file.


Can anyone suggest an alternative method or workaround for permiting an HTTP connection under ATS? Note that neither the host application or plugins are targets for App Store submissions, so there is no need to comply with the store's requirements.

Replies

You would have to have a helper app, launched independently via launchd or similar, and communicate using that.

What are you doing with HTTP? This matters because the best way to fix this problem is to secure the user’s data by adopting HTTPS. That may not be possible in some circumstances, and if that’s the case here then my follow-up advice is going to depend on those circumstances.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This is work for a 3rd party - we're accessing their server via SOAP calls from their remote clients. I've strongly urged them on many occasions to support https connections, but no success so far. I think their internal development team is inexperienced (for a variety of reasons), but they assure me they plan to support secure connections in future.


I've fallen back on using curl, which works fine. My ambition was to utilise the macOS frameworks to the greatest possible extent, but this appears to have been a step too far.

I've strongly urged them on many occasions to support https connections, but no success so far.

Yikes! I’d be very leery of working with a partner who can’t get HTTPS working )-: Remember that your users will hold you responsible for any problems that arise from this.

One thing you could do here is to implement your own HTTPS front end for this service. That is, you stand up an HTTPS server that your app talks to, and then that server forwards the request to this third-party server. This definitely increases security (the traffic is only vulnerable between the two data centres, not all the way to the client device) and it has other benefits as well:

  • Your front-end server could cache results.

  • This approach can be used to anonymise requests, which is a good idea in general and may be really important if there’s any personal data involved (and remember that client IP addresses can be considered personal data).

  • It puts this service under your control. For example, if this third-party server falls over, you can update your front-end server to talk to another server without having to update your app.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks – that's great advice. The customer is distributing and supporting the software with their own customers, so I'm invisible as far as they're concerned. And fortunately there is no personal data involved in this case – it's communicating process documentation that isn't sensitive or valuable. Unfortunately the development project was very advancedwhen they admitted they didn't support secure connections. They have written warnings from me and I hope they follow through. I'm not sure what it will take to make the general business world understand that this *really* matters (and in all cases).

Thanks for explaining the background. And yes, I do realise that it’s easy for me to offer advice when I’m not the one actually on the hook for implementing it! (-:

One word of caution about the following:

it's … process documentation that isn't sensitive or valuable.

While this documentation may not be confidential, privacy is not the only important security benefit of HTTPS. It also provides a level of authenticity.

Imagine that one of your users is working on a MacBook in a coffee shop. Your plug-in has no idea whether the data it gets back from the server is authentic or not. If you have some other way to authenticate the data (perhaps it’s cryptographically signed), you’re all set. But if not, your plug-in may end up showing malicious documentation to the user. Not good.

Even worse is that your plug-in’s code must treat this data as untrusted. If, for example, the code that parses this data has a buffer overrun, an attacker could send you malicious data to exploit that buffer overrun.

HTTPS is really important, which is why we did the whole ATS thing in the first place (-:

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"