Among many improvements in iOS 9 that will quietly make our digital lives better or offer more security, App Transport Security (ATP) is one you likely will hear little about, even as it enforces a strict approach to moving data about that lowers an app’s vulnerability to interception, which in turn makes your data more secure in transit.

Apple’s demand is that apps use a secure connection when sending data to and from an iOS device; this is separate from securing data on a developer’s servers or on the device. It seems like a smart thing and very much in keeping with privacy and security concerns in 2015.

And then a few days ago, Google posted advice on working around this requirement that generated a reasonable amount of blowback because ad networks were involved. Google wasn’t suggesting anything nefarious: it was perfectly within the rules and will probably help developers in the short run. But the fact that security barriers must be lowered to keep ad delivery working reveals another piece of what’s wrong with the current delivery systems.

The ATP policy in iOS 9 requires that all apps communicate off device using modern TLS encryption, the same used on the web for securing sessions between a browser and a server. This covers things like an app talking to the developers’ servers to move data back and forth, or accessing a third-party API (application programming interface), which is a very common way to tie in services offered by other sites and companies.

Insecure connections can be sniffed, allowing third parties anywhere between a device (say, on a café or airport network) and the destination server to see exactly what’s being transmitted, which could include cookies or session identifiers. Those can be sidejacked, or used to authenticate other devices or apps instead of the one that was authorized. Any credentials sent in the clear can be grabbed and used. File-oriented data, like documents and images, can just be downloaded and associated with whatever account information is also sent without protection. An increasing number of websites use https by default, and moving apps firmly in that direction is a great idea.

This requirement is entirely separate from other security and privacy policies, such as what kind of information an app or a company collects, how it maintains privacy for users, how it secures information it stores within the app or on its servers or intranet computers, and what sort of password-encryption protocols it employs.

Apple’s policy is very strict, requiring the most resistant versions of encryption ciphers and the TLS protocol. Many web servers will accept connections that use standards that have been broken years ago; Apple is upping the bar. (TLS is the successor to SSL, and while even I would recently write SSL/TLS to make it clearer, all SSL standards are now considered insecure, and only recent TLS version 1.2 and later can be relied upon.)

Now, many apps almost certainly use TLS security for communication, because it’s relatively easy and inexpensive to set up a server with this kind of session security. Many APIs, like those used to interact with cloud-based developer services like Amazon’s AWS and Microsoft’s Azure, offer encrypted endpoints that comply with Apple’s requirements.

Developers running their own servers need to obtain a free or inexpensive security certificate, which has an annual cost of from $0 a year to a few hundred dollars, depending on what they need. These certificates have to be renewed annually or biennially for the most part, and it’s trivial to obtain, install, and update them.

The problem Google was addressing has to do with advertising, analytics, and related networks to which developers build connections within their apps. Ostensibly, some of those are run by, you know—Google. Many of these networks are bizarrely unable to offer a fully encrypted session.

I had baffling discussions with a few in the last couple of years when helping other sites set things up, where the sales or marketing people were unaware of what I was talking about, and the engineering folks they consulted waved concerns aside. This despite Chrome years ago being configured by default to kick up a fuss when any insecure content appeared on a page that was retrieved over https.

Apple does allow exceptions to ATP. Developers can enumerate domains and then set lower security levels, like allowing older versions of TLS to work or not requiring an encrypted connection altogether. Google’s advice was completely reasonable: Build new apps with TLS everywhere. Use TLS as much as possible with older apps. Only use exceptions when there’s no other choice.

But here’s the key statement on the Google blog:

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 has done an exceptional amount to improve the amount of data that passes over parts of the Internet in an encrypted fashion, allowing protection from casual snoopers, criminals, and government agencies that act outside the structures of civil-liberty protections. And yet: it can’t enforce a rule on its own subsidiaries and partners well enough to ensure a base level of security that’s now seen as an acceptable minimum for new apps and sites.

A year ago, Marketing Land offered this story about how relying on https was “still” breaking websites. It’s not like ad networks and other distributed marketing channels didn’t have time to work on the problem.

Apple allows exceptions because it doesn’t want to cause apps to break, and would rather give developers a structure and incentive to move forward. By requiring these carve-outs, developers will have to sort precisely which parties they work with that have fallen behind.

I can imagine a future date at which Apple eliminates all exceptions without specific rationale and App Store approval. And of all unilateral behavior the company could engage in regarding allowing and excluding apps? In this case, I’d agree. The future of the Internet is all encrypted, and ad networks shouldn’t be holding apps back.