Apparently for advertising reasons, Google has asked developers to disable a key privacy feature in the forthcoming iOS 9 that aims to make apps encrypted by default.
Apple was applauded by privacy minded developers in June after announcing that iOS 9, due for release this autumn, would introduce App Transport Security (ATS). It was Apple's answer to apps that leak data about their users. ATS would by default prevent non-HTTPS connections between web services and apps installed on iPhones.
What wasn’t obvious when Apple made the announcement is that one of ATS’ main casualties would be mobile advertising, which has over the years become an equally important source of revenue to app developers as in-app purchases and direct app sales.
Apple of course has relatively little skin in the mobile advertising game compared to Google. Besides Apple making most of its money on hardware, iOS users are more willing to pay for apps than Android users. However in-app advertising is also helping shape the market for apps.
As Google pointed out on Wednesday, when a non-ATS compliant app attempts to serve an ad via HTTP on iOS 9, it will display to the developer the message: “App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.”
So Google has asked developers using its mobile ad SDK, AdMob, to disable the privacy feature. It also deflected blame for its request — which goes against its general push for HTTPS everywhere — on third-party networks that don’t support HTTPS.
“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,” Google said on its ads developer blog.
“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.”
As Apple notes in iOS 9 technical documentation, developers can use an app’s “Info.plist file” to specify exceptions to ATS or simply turn the feature off.
"You can specify exceptions to the default behavior in the Info.plist file in your app or extension. Use the keys in the property list for specific exceptions or to turn off App Transport Security. Table 1-1 shows the keys and their types, and uses indentation to indicate structure," Apple .
However, as some on Hacker News argue, it's the latter option that Google suggests, which seems to be what Google suggested in its blog.
“Publishers can add an exception to their Info.plist to allow any insecure connection,” Google said, pointing to the following script:
While Google's recommended workaround may seem self-serving, it also isn't the first to suggest it. Several other iOS developers have previously published the same snippet, which they noted Apple didn't document and lets developers disable ATS altogether.
A corollary to the issue Google is addressing is ‘mixed content’ on desktop browsers, for example, where a news website loads resources from a source that doesn’t serve them over HTTPS. It can happen due to the need to serve resources from legacy publishing systems but more often than not it’s due to ads that aren’t served over HTTPS.
Particularly since Edward Snowden’s leaks, Google has been one of the major proponents of encrypting the web and even before Apple announced ATS, it committed to encrypting the “vast majority” of mobile, video, and desktop display ads served to the Google Display Network, AdMob, and DoubleClick publishers. But while Google is a major force in online advertising, it can only lead by example in pursuit of an objective that really requires the entire advertising industry to follow suit.
Whatever Google's and Apple's motivations are, there's a healthy debate going on at Hacker News as to each companies intent.
Want to know more?
Why not become a CSO member and subscribe to CSO's mailing list.
Get newsletters, updates, events and more right here