Apple mandates App Store apps support ATS security protocol by 2017
In an announcement at a Worldwide Developers Conference session on Tuesday, Apple said apps submitted to its various App Stores will be required to use the App Transport Security standard by the end of 2016, a decision that underscores the company's dedication to customer privacy.
Introduced as part of iOS 9, ATS transfers app data over HTTPS connections instead of HTTP, thereby reducing the potential of user exposure to nefarious code or data theft. Starting Jan. 1, 2017, all new apps and app updates submitted to the App Store will need to support the protocol, reports TechCrunch.
ATS is turned on by default in Apple's development tools, though developers currently have the option to deactivate the security feature if they so choose.
Apple's upcoming deadline mirrors a wider industry shift toward HTTPS-based connections. Banks and internet service providers dealing with highly sensitive user data were among the first to deploy HTTPS solutions, and an increasing number of companies have since adopted similar safeguards. Device manufacturers marketing bespoke operating systems, like Apple's iOS and Mac, have followed suit.
ATS found itself at the center of a small controversy last year when Google publicly disclosed a technique of sidestepping the iOS security protocol with just a few lines of code.
Google discovered that ATS was blocking ads from displaying correctly in certain mobile apps, which presented an obvious threat to its lucrative advertising business. In response, the internet search giant posted a "short term fix" to its Ads Developers Blog proposing developers inject HTTPS exceptions into their apps. By allowing non-secure HTTP requests to succeed, these exceptions inherently put users at risk.
In any case, developers looking to sell their wares on Apple's App Stores will have no choice but to comply with ATS guidelines come January.
Introduced as part of iOS 9, ATS transfers app data over HTTPS connections instead of HTTP, thereby reducing the potential of user exposure to nefarious code or data theft. Starting Jan. 1, 2017, all new apps and app updates submitted to the App Store will need to support the protocol, reports TechCrunch.
ATS is turned on by default in Apple's development tools, though developers currently have the option to deactivate the security feature if they so choose.
Apple's upcoming deadline mirrors a wider industry shift toward HTTPS-based connections. Banks and internet service providers dealing with highly sensitive user data were among the first to deploy HTTPS solutions, and an increasing number of companies have since adopted similar safeguards. Device manufacturers marketing bespoke operating systems, like Apple's iOS and Mac, have followed suit.
ATS found itself at the center of a small controversy last year when Google publicly disclosed a technique of sidestepping the iOS security protocol with just a few lines of code.
Google discovered that ATS was blocking ads from displaying correctly in certain mobile apps, which presented an obvious threat to its lucrative advertising business. In response, the internet search giant posted a "short term fix" to its Ads Developers Blog proposing developers inject HTTPS exceptions into their apps. By allowing non-secure HTTP requests to succeed, these exceptions inherently put users at risk.
In any case, developers looking to sell their wares on Apple's App Stores will have no choice but to comply with ATS guidelines come January.
Comments
This is why IPv6 should have encryption enabled by default because it wouldn't require a certificate. All packets would be encrypted.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s1-ipsec-net2net.html
Apple could allow connections that support protocol encryption and even self-signed certificates to make it easier on developers. It wouldn't matter if it's a self-signed certificate because the important consideration is that the traffic is being sent encrypted and isn't intercepted.
CPU overhead for SSL isn't that high these days:
https://www.maxcdn.com/blog/ssl-performance-myth/
You can test it on the Mac in the terminal. With a large file like a video you can run the following command and the time taken to process would be user+sys times, there's disk IO with a file that wouldn't be there at the network level:
time openssl aes-256-cbc -a -salt -in (drag file in) -out (drag same file in and rename with e.g .enc on the end)
It takes seconds for hundreds of MBs of data and the CPU doesn't spike at all.
Having to set it up is the biggest problem for developers. Setting up a server and maintaining a certificate has more costs associated with it. If a developer has very few downloads, they can get by with shared hosting. $10/month with SSL unlimited bandwidth, drop a script on it to access an unencrypted service and pass the data along. Shared services would probably handle hundreds of thousands of downloads.
Apple must have exceptions for some apps as a browser can access unencrypted connections so they may allow exceptions for some hardwired connections. They have a presentation at the following link that talks about the move to encryption and treating all data as sensitive:
https://developer.apple.com/videos/play/wwdc2015/711/
It would be nice if the networking industry would make things easier as time goes on. They should separate encryption from authentication. Encryption should be done by default without expiring certificates. An authority should just check the encryption is adequate and verify the connection details and then provide a certificate that gets integrated with the encryption that's already there.