Mikey Campbell
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.
Sponsored Content
Charles Martin
Christine McKee
Malcolm Owen
Amber Neely
6 Comments
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.
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.