Google, sadly, tells ad developers how to disable Apple’s transport security

Instead of helping developers to turn off app transport security, Google should help them apply as much of it as possible.

App Transport Security is Apple's forward-looking way to make sure any communications between an app and a web server are done using TLS 1.2 and SHA256 or better security. That way nobody can eavesdrop on or tamper with your data. Yesterday Google not only told developers how to disable it, they supplied the code for them to do it. From the Google Ads Developer Blog:

While Google remains committed to industry-wide adoption of HTTPS, there isn't always full compliance on third party ad networks and custom creative code served via our systems. To ensure ads continue to serve on iOS9 devices for developers transitioning to HTTPS, the recommended short term fix is to add an exception that allows HTTP requests to succeed and non-secure content to load successfully.

That caused a backlash in the security community. Rather than help developers, for example, configure things in such a way that app traffic remained secure while working on making the ads secure as well, they simply told them how to turn it all off. Private data connections and ads, all of it. It's the easiest approach but also the laziest and worst approach for users.

Google updated the article later in the day:

We've received important feedback about this post and wanted to clarify a few points. We wrote this because developers asked us about resources available to them for the upcoming iOS 9 release, and we wanted to outline some options. To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.

Our own Nick Arnott wrote about ATS after Apple announced it at WWDC 2015 and recommended several options, the third of which could be a better solution for developers and users both. From Neglected Potential:

Conversely, you may only want ATS to work on domains you specifically know can support it. For example, if you developer a Twitter client, there will be countless URLs you may want to load that may not be able to support ATS, though you would want things like login calls, and other requests to Twitter to use ATS. In this case you can disable ATS as your default, then specify URL which you do wish to use ATS.

In this case you should set NSAllowsArbitraryLoads to true, then define the URLs that you want to be secure in your NSExceptionDomains dictionary. Each domain you wish to be secure should have its own dictionary, and the NSExceptionAllowsInsecureHTTPLoads for that dictionary should be set to false.

ATS is brand new with iOS 9 and there will be some initial pain, especially for people with content like ads. But that doesn't mean the privacy and security baby should be thrown out with the bathwater. Everyone is stressed and rushed leading up to a launch, so if a company like Google recommends an easy out by just shutting security down, that out is more likely to be taken.

Recode put it this way:

Both companies say they're moving toward the same goalpost on mobile security. The difference: When ads and security clash, Google wants to figure out a compromise, because Google is an advertising company. Apple isn't.

Everyone, platform owners and developers included, can be inclined to punt in the face of impending change. I'm optimistic, however, that Google can get it together and help developers achieve the best results for now, and better ones going forward.

Nick Arnott contributed to this article.