Google tells iOS 9 app devs: Switch off HTTPS if you want that sweet sweet ad money from us

Apple's encrypt-everything rule gets in the way of plain HTTP

Google has told iOS 9 app developers to disable Apple's enforcement of HTTPS-only connections – or their in-app Google ads won't show up on up-to-date iPhones and iPads.

Apple has added what it calls App Transport Security (ATS) to iOS 9 and OS X 10.11, which ensures software only uses encrypted connections when talking to servers and other systems over the network.

It's supposed to make sure programmers always protect people from eavesdroppers and man-in-the-middle tampering: when an app sends someone's personal data over the internet to the app maker's backend servers, the information should be safeguarded by encryption. But this enforcement can be switched off on a per-application basis.

Apps can be built using the Google Mobile Ads software development kit to show adverts on-screen, and earn developers cash. By not showing these ads, the programmers lose out on vital revenue.

On Wednesday, Google admitted that it's still shifting a ton of adverts over unencrypted HTTP connections – and apps running on iOS 9 and OS X 10.11 with ATS switched on will be forbidden from connecting to Google's ad network over HTTP. That means no Google adverts can be dished out to those applications. No dosh for the developers. No cut for Google.

So Google's advice is to: switch off ATS, and let apps fire off connections over HTTP and 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," blogged Googler Tristan Emrich.

"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."

Developers are urged to edit their apps' Info.plist files and add:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

It is true that Google is "committed" to HTTPS: its search engine uses encrypted connections, and in April the web giant promised that "the vast majority of mobile, video, and desktop display ads served to the Google Display Network, AdMob, and DoubleClick publishers will be encrypted."

Asking app makers to disable ATS doesn't mean everyone is suddenly going to be hacked; applications can open separate HTTPS connections to their backends, and keep HTTP for ads. Plenty of ads are served today over plain old HTTP (and plenty of people use ad blockers.)

It's just frustrating to see Apple enforce a sane and safe policy of encrypt-everything – a strong step in the right direction for privacy and security – and then watch the whole effort be undermined by advertising.

Ultimately, it reveals the HTTPS problem publishers and app developers face right now: more and more readers and users want, or need, encrypted connections to protect themselves from the internet's criminal infestation. And yet advertising, the lifeblood of many legit organizations, is keeping websites and software anchored to HTTP.

You can't safely serve a webpage over HTTPS if it needs to pull in material over HTTP. It's why here at El Reg we can serve our images and PDFs over HTTPS, but not the full site because we rely on advertising from outside networks that use HTTP.

The Interactive Advertising Bureau, which represents hundreds of media outfits and has joined calls for HTTPS to be used everywhere, explained in March this year:

Many ad systems are already supporting HTTPS – a survey of our membership late last year showed nearly 80 per cent of member ad delivery systems supported HTTPS. That’s a good start, but doesn’t reflect the interconnectedness of the industry. A publisher moving to HTTPS delivery needs every tag on page, whether included directly or indirectly, to support HTTPS. That means that in addition to their ad server, the agency ad server, beacons from any data partners, scripts from verification and brand safety tools, and any other system required by the supply chain also needs to support HTTPS.

Let’s break that down a bit more – once a website decides to support HTTPS, they need to make sure that their primary ad server supports encryption. That ad server will sometimes need to include tags from brand safety, audience and viewability measurement, and other tools – all of which also need to support encryption. The publisher’s ad server will often direct to one of several agency ad servers, each of which will also need to serve over HTTPS. Each agency ad server also may include a variety of beacons or tags, depending on how the deal was set up, all of which similarly need to have encrypted versions available. That’s a lot of dependencies – and when one fails to support HTTPS, the website visitor’s experience is impacted, initiating a costly search for the failure point by the publisher.

Something for the huge brains at Google and its ad pals to think about. Finally, it's worth pointing out that iOS 9 will include mechanisms for blocking, among other things, cookies, popups, ads and web traffic analytics – all the things that make up 90 per cent or more of Google's annual revenue. No wonder Google's in a rush to shut Apple's barriers down. ®

Also, don't miss: Malware menaces poison ads as Google, Yahoo! look away

Updated to add

Google's PR folks have been in touch to say the aforementioned blog post by Emrich has been updated with some clarifications following "important feedback."

"To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful," the update reads. "Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.

"We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products."

Sponsored: The Joy and Pain of Buying IT - Have Your Say


Biting the hand that feeds IT © 1998–2017