Despite developers having a mandate from Apple to build end-to-end encryption into their apps, a high number of apps do not. Apple even offers a feature that helps developers comply with data privacy requirements, and our data shows that this isn’t being used properly. To understand how app developers are using (or not using) encryption, we analyzed over 30,000 of the iOS apps most commonly used by employees and found that more than two-thirds of apps don’t use this feature to encrypt data. More findings below…
Why would an app developer want to use data encryption?
Encrypting data improves user privacy and data integrity, safeguarding user data from malicious parties. It plays an important role in security and privacy by decreasing the visibility of traffic to anyone who might be monitoring it. This allows users to send sensitive information, such as usernames and passwords or credit card details, across the internet without it being found by a hacker.
In the case of a leaking app, i.e. an app that isn’t using encryption, a hacker on the same network can sniff the traffic and obtain the data in transit. And leaking apps are more common that you might think.
On Apple platforms, a networking security feature called App Transport Security (ATS) is available and enabled by default. ATS is basically a set of rules that ensure iOS apps and app extensions connect to web services using secure connection protocols. More information on ATS here.
In 2015, Apple released ATS as an optional feature with the arrival of iOS 9.0. In 2016 at WWDC (Worldwide Developers Conference), Apple announced that all iOS apps would be required to follow and use ATS by January 2017 unless there was a strong justification provided for any listed exceptions. However, Apple postponed this deadline indefinitely.
Why would an app developer choose not to encrypt data?
The App Review Guidelines currently state that developers need to supply a justification for disabling ATS. But according to multiple sources, as well as our own research, it seems the justification does not need to be a strong one and, in most cases, developers are successfully disabling ATS.
App developers may have good reasons for disabling ATS. Apps talk to third-party advertising, market research, analytics and file hosting services and these external services may not support HTTPS connections. Advertising networks such as MoPub and Google AdMob recommend disabling ATS completely to ensure ads are loaded correctly.
ATS – global exceptions
Originally, developers could completely disable or enable ATS. But in newer iOS versions (from iOS 10 onwards) there is more granularity available, so developers can set a global ATS configuration and then exception it on a case-by-case basis for specific functions within an app, such as when it fetches media content or enables a web browser overlay. Setting more granular rules overrides the global ATS configuration for those exceptions.
Most apps have ATS disabled globally – Only a few apps use the new more fine-grained keys
Our research showed that two-thirds (67.8%) of apps disable ATS globally and don’t set any granular exceptions for specific functions. Note: These apps may still whitelist or blacklist individual domains to use or not use ATS via the domain exception (more on exception domains later in the article).
Only 5.3% of apps use the new more granular keys to disable ATS, e.g. for media only, while most apps stick with disabling ATS completely for all communication.
When ATS is globally disabled, this does not necessarily mean all communication is unencrypted—it just means that system safeguards are disabled and hence there is much more room for error.
Use of ATS in paid vs. free apps
Ad frameworks often require ATS to be disabled to some degree, so it’s no surprise that paid apps—which usually don’t display ads—have stricter ATS settings.
Ad network operators are in a competitive space and want to streamline the process for developers to make their apps compatible. By removing “roadblocks” such as encryption requirements, they make it easier for more developers to incorporate their ad networks into their applications.
At paid apps, ATS is globally enabled more often
According to our research, a large percentage (45.7%) of paid apps have ATS globally enabled. Meanwhile, the vast majority (68.5%) of free apps have ATS completely disabled.
ATS global configuration by app category
ATS global configuration differs only slightly across categories, with finance leading the pack. However, even for the leading finance apps, only a third of them have ATS globally enabled and many of these still have global exception domains.
Not included in the data below, but still worth mentioning, are sticker apps. Sticker apps are apps that deliver stickers for iMessage. In our analysis, we discovered that almost all sticker apps (96.8%) enable ATS globally. While we aren’t entirely sure why this is the case, it’s safe to say most sticker apps have no reason to communicate to the outside web, therefore developers do not need to touch the ATS settings, leaving ATS enabled by default.
Apps with ATS enabled across all categories (Sticker apps were excluded)
ATS – domain exceptions
In addition to listing global exceptions, the developer can also specify exceptions on a per-domain basis. This configuration completely overrides the global settings for a particular domain, so the domain exception can work as both a whitelist and a blacklist, depending on the global configuration.
More than two-thirds (70%) of apps have no exception domains and the remaining 30% have less than five. Note: apps with more than 20 exception domains were excluded because there were very few.
Most apps have no exception domains (Apps with 20+ exception domains excluded)
A domain exception might actually mean both enabling and disabling ATS. The graph below shows whether each domain entry enables or disables ATS for apps with ATS globally disabled.
Exception domain types – For apps with globally disabled ATS
More than three quarters of apps with ATS globally disabled (77.3%) do not specify any exception domains, therefore the safeguards are completely disabled for all network communication.
A small portion (9.4%) of apps with ATS globally disabled specify exceptions that enable ATS. While the opposite approach is usually a better practise (enable globally, then disable for a few exception domains), this is still a sensible configuration.
However, for some, the configuration makes no sense at all, like the 9.2% that specify exception domains to disable ATS. This suggests developers might not understand ATS and therefore aren’t using it as Apple intended by disabling ATS globally and still listing exception domains to disable ATS.
For each exception domain, there are three possible ATS exceptions that can be specified: allowing HTTP loads, not requiring forward secrecy, and allowing the
use of obsolete TLS versions. Of these domain exception entries, the most common exception key is the ‘allow HTTP loads’ key.
Allowing HTTP loads is key used most often
What are the top exception domains listed by developers?
Most of the top 10 exception domains are related to Facebook and other large Content Delivery Networks (CDNs) like Amazon and Akamai. But as highlighted earlier, having a domain exception doesn’t always mean that domain disables ATS. In many cases, that exception is actually enabling ATS, so the domain is specified in the exception domains even though it fully supports ATS.
Top 10 exception domains – ATS checks are being both enabled and disabled
Most of the above domains are Content Delivery Networks (CDNs) that are tracking users with Cookie or Pixel technology for the purpose of targeting users with advertising. The reason they are the most commonly listed exceptions domains might simply be because they are fundamental to advertising functionality and used by most apps.
- fbcdn.net – a CDN operated by Facebook to serve static content (e.g. photos)
- m.faceboook – a mobile-friendly site operated by Facebook
- api.facebook.com and graph.facebook.com – web services that enable programmatic access to data within the Facebook platform
- Akamaihd.net – a CDN and cloud services provider. Note: Akamai is responsible for serving 15-30% of all web traffic. Their business model includes tracking users and serving ads
- Cloudfront.net – a CDN operated by Amazon that includes user tracking capabilities
- Amazonaws.com – web platform that provides cloud hosting and content delivery
Why are developers not following ATS?
Perhaps the reason many developers disable ATS, despite Apple’s efforts, is because they don’t actually understand how it works due to its complexity. Or maybe they are taking the easy way out by just submitting all the domains their apps need as exceptions to avoid any potential interruptions to the end-user experience due to incompatibility with servers. The alternative route would be checking that each domain supports HTTPS and only making exceptions for those that do not. Many developers are under pressure to increase speed to market and remove unnecessary costs, so it’s easy to see why they would want to take shortcuts like blanket ATS exceptions.
The question now is will Apple continue to allow sloppy development on its platform or will it decide to reinstate a deadline for the strict ATS implementation it had envisioned?
Web service operators also need to become part of the solution. They can’t keep supporting unencrypted content when OS vendors like Apple are trying to move toward total encryption. Web service operators should be supporting HTTPS and encouraging developers to use secure connections.