noir's comments

Well that's just silly. There are plenty of high profiles apps out there with many users who have a set of known domains that their app will need to connect to. As an example, Facebook, will never push a config update that points their app do a domain other than Facebook. Most big apps will likely have backend mitigation for problems like DDoS. You're right that most apps don't hardcode URLs, but most configs also don't update domains to something completely unexpected on a regular basis. Also, even if you enable ATS on specific domains and you need to point your config elsewhere, following Google's instruction, that will mean your new endpoint no longer enforces ATS, which is still better than having disabled ATS for every URL in your app for all users from the start.

The exception is specified in the app's Info.plist. You won't be able to tell just by looking at the app on your iOS device, but you can download and unzip and IPA, and directly look at its plist to see if it has the NSAllowsArbitraryLoads key or not.

ATS is configurable to allow arbitrary loads, but specify which domains you wish to keep secure. The author of the above post failed to document or mention that. Most developers will have known domains that they wish to keep secure, and there are options available to do that.

It's a lazy recommendation. The first 2/3ds of the post are fluff to try and compensate for the fact that their recommendation in the end is "turn off this security feature". ATS is configurable to disable or enable for particular domains. The fact that we've known about ATS for over two months now and this is the best solution Google can come up with means they don't care. They don't care enough to read Apple's documentation and offer a helpful solution.

That's fair. The reason I put their email response in my post is so user's could evaluate for themselves how they felt about. The response so far has been mixed. Some are bothered by it, others, like yourself, aren't really worried. And that's fine.

The reason I reached out specifically to their security team is because on their security policy page that's the email they provide to contact them regarding security issues. Reaching out to their security team wasn't some intentional move to try and not get a quick response, it was just what made sense to me at the time.

I agree that their support is usually extremely quick to get back to you and it's one of the things I love about the company. Except for these issues and their security team's response, I love their service as well. I'm not rooting for them to lose here, I'm rooting for them to fix the issues so we can all happily move on.

They have been much quicker to respond to people reaching out to them over Twitter today and I have updated the blog post to reflect that. I look forward to having these issues all wrapped up.

Glad the app was able to see the light of day. It's a wonderful app and it's great that it was able to be used for a network, and people worthy of it.