Apple extends developer deadline to support App Transport Security into 2017

Apple on Wednesday informed developers that it has extended the deadline by which apps submitted to the various App Stores will required to use App Transport Security, a standard introduced in iOS 9 and OS X 10.11.

According to a brief statement posted to Apple's Developer News website, the ATS implementation mandate has been pushed back to an as yet unannounced date in order to give app makers "additional time to prepare" their wares for support.

ATS debuted in 2015 as a method of improving security and privacy by forcing apps to transfer data through secure connections over HTTPS. Similar protocols are already employed by banks, internet service providers and other companies dealing with highly sensitive user data.

Although ATS is switched on by default in Apple's development toolset, developers currently have the option of deactivating the feature. During this year's Worldwide Developers Conference, however, the company said it would begin enforcing ATS support starting Jan. 1, 2017.

Apple's shift to ATS sparked a minor controversy in 2015 when Google publicized a technique of sidestepping the network security protocol. At the time, the search giant discovered ATS was inhibiting ads from displaying in certain mobile apps, so the company proposed a "short term fix" that involved inserting HTTPS exceptions into affected titles.

While the extra lines of code help Google serve up ads, and bring in ad money, the exceptions skirt Apple's recommended protections and inherently put end users at risk.

Apple has not announced an expected timeline for ATS integration, saying only that developers will be updated when a new deadline is confirmed.

Follow AppleInsider on Google News

6 Comments

Soli

said about 7 years ago

I wish there was a way to see which apps aren't supporting different types of security. I'm getting a lot of app updates this month, and maybe that's because they can get their new SW in under the wire for this requirement.

nmdias

said about 7 years ago

Soli said:

I wish there was a way to see which apps aren't supporting different types of security. I'm getting a lot of app updates this month, and maybe that's because they can get their new SW in under the wire for this requirement.

There is. Get a proxy, like Charles Web Debugging proxy. Then configure the Wireless connection on your iPhone to use that proxy.

Donvermo

said about 7 years ago

Soli said:

I wish there was a way to see which apps aren't supporting different types of security. I'm getting a lot of app updates this month, and maybe that's because they can get their new SW in under the wire for this requirement.

At least for OSX/macOS there is an app called LittleSnitch, it's an outgoing firewall and tells you how and when apps communicate. I use it a lot to determine trustworthiness of developers and block certain analytic services that are built into apps. (LastPass for example tries to connect to Google Analytics) You get a simple prompt informing you of the request and you can then choose to block or allow it temporarily or permanently.

emoeller

said about 7 years ago

Donvermo said:

Soli said:

I wish there was a way to see which apps aren't supporting different types of security. I'm getting a lot of app updates this month, and maybe that's because they can get their new SW in under the wire for this requirement.

At least for OSX/macOS there is an app called LittleSnitch, it's an outgoing firewall and tells you how and when apps communicate. I use it a lot to determine trustworthiness of developers and block certain analytic services that are built into apps. (LastPass for example tries to connect to Google Analytics) You get a simple prompt informing you of the request and you can then choose to block or allow it temporarily or permanently.

I've used LittleSnitch for years - works great. The solution for Apple to enforce this at the developer level, but allow the end user the option to bypass if they so choose to do so.

indieshack

said about 7 years ago

I think the general goal of ATS is laudable, but the way Apple introduced this, particularly timelines, was bone-headed. Existing apps with the ATS exception in their plists wouldn't have been yanked, but updates to them would not have gotten approved. Many apps using publicly accessible data servers (e.g. train times, etc) would have been effectively orphaned since in many cases the public data servers don't comply with the TLS 1.2 etc. requirements (there's no reason for them to, why use SSL for train times?). I understand Apple was suggesting requesting exceptions on an individual basis, not sure how that would be practical. Unless the app developer proxies them through their own servers, which many they won't because it's not cost effective, they'll abandon the app. I'm lucky enough to mostly be working in enterprise environments where in many cases the data being shifted is neither critical nor confidential and I can tell you that ATS exception use is the norm. Apple needs to re-think the rollout of this, perhaps limiting ATS where logins are used.

Regarding Soli's suggestion to denote which apps enforce ATS, I think that's a great idea, shaming apps which don't enforce ATS - would you use a shopping or banking app which was highlighted by Apple as having less-than-perfect security? - rather than imposing a timeline.