Handling App Transport Security in iOS 9 | Hacker News Reader

Handling App Transport Security in iOS 9

googleadsdeveloper.blogspot.com

123 pointsKallikrates59 comments

Intentionally disabling security settings for your entire application just to allow advertising from companies who haven't upgraded their infrastructure seems quite user-hostile. Google is a big supporter for HTTPS, strong certificates, etc., but apparently only when it doesn't affect their bottom line. If Google told their advertising networks that they need to be using HTTPS or they won't be available for iOS users they would probably get secure connections up and running pretty quickly.

I'm going to copy my comment from below verbatim because that one is being downvoted and this one isn't despite saying the same thing.

---

[Google] are first, and foremost, the worlds largest advertising company. This is how they make their bottom line and it will come at the detriment of anything else. however, they value reputation too- so it's likely this will be fixed in future. But let's not throw exaggerations around. Google are not "for the people" but they're not against them either. Google are the new lawnmower[0] except they generally do things we like right now. [0] https://youtu.be/-zRN7XLCRhc?t=2084

At my last job, we did something similar to what iOS 9 is now doing, where we migrated a survey engine to serve all forms over https. There was high fiving and champagne all around the engineers desks, while media was freaking out that their impressions took the sharpest reverse-hockey-stick in the world. Ad networks are seriously the worst when it comes to https traffic. Given the dozens of redirects and pixel injections and iframes slapped into a media page, it's nearly impossible to serve secure traffic since it only takes one network to downgrade the https request to http and then the page is "broken".

> Given the dozens of redirects and pixel injections and iframes slapped into a media page, it's nearly impossible to serve secure traffic since it only takes one network to downgrade the https request to http and then the page is "broken".

You mean, then the specific ad is broken, as long as its ad router isn't fixed to use https?

Right, the browser gives you an "Only secure content is displayed" notice and the page works fine.

Ever worked with affiliate ad funnels before? Everything looks like it was coded by the bosses 14 year old son. Pages served under https containing tracking pixels under http, iframes sourcing http endpoints, various obscure analytics setups without any semblance of ssl...

And when all your impression pixels are refused because of insecure content warnings (because your server is serving over https), your impressions stats dive harder than a lead zeppelin.

What's broken is the total lack of standardization for any of these companies, which makes sense given that most of these guys are slinging diet pills and brain supplements to the LCD; Great devs don't usually gravitate to industries like that.

Who or what exactly do you refer to as “media”? Is this what this company called their advertising division?

The people who monetize content and the viewing of content. Generally for places where impressions and traffic sourcing/funneling to a site is a higher stream of revenue than selling or marketing to customers. Think of Gawker, not Uber.

Seems they're between a rock and a hard place. When Google proposed HTTPS everywhere, a number of people took exception because not all content has sensitive data needing protection.

I guess the real question is whether an HTTP call to load an ad copy is sensitive content. I think you can make an argument that it is sensitive content, because if I were monitoring your connection, and everything was encrypted, but I suddenly saw lots of ads for Ashley Madison and cheating sites, I might conclude that you had been researching those in the past even if I couldn't see your other traffic.

A better way would just to let the ad networks fix it. You can bet that after iOS9 ships, if they see a massive drop in ad traffic, they'll be burning the midnight oil to fix it ASAP.

I mean, iOS9 betas have been out for a long time, so it's not like they haven't had time to prepare.

We've moved passed the idea that only sensitive content needs to be transported over SSL/TLS.

https://www.amnesty.org/en/latest/campaigns/2015/04/7-reason...

https://www.aclu.org/blog/you-may-have-nothing-hide-you-stil...

http://www.ted.com/talks/glenn_greenwald_why_privacy_matters

http://falkvinge.net/2012/07/19/debunking-the-dangerous-noth...

https://en.wikipedia.org/wiki/Nothing_to_hide_argument

Yes, we, the geeks and privacy advocates have moved past. We care about ubiquitous encryption for non-sensitive content.

The public at large doesn't care or understand unless they're banking or porning, and I'm not sure about the banking.

Telecoms, shareholders, advertisers, governments, and criminals are actively opposed.

We have a ways to go.

It's also a security issue (in all cases), regardless of the privacy implications:

https://citizenlab.org/2014/08/cat-video-and-the-death-of-cl...

Ad networks haven't supported HTTPS fully on the web either, not just iOS. In fact, Google says you will earn less with just HTTP

"If you do decide to convert your HTTP site to HTTPS, please be aware that because we remove non-SSL compliant ads from the auction, thereby reducing auction pressure, ads on your HTTPS pages might earn less than those on your HTTP pages." [0]

I wouldn't be surprised if many app developers put in this exception because at the end of the day, they will hurt too if ads stop showing up.

[0] https://support.google.com/adsense/answer/10528?hl=en

This short story comes to mind http://www.crimeflare.com/doctorow.html (re: looking at ads displayed to you to know what you are looking at)

Who is "between a rock and a hard place"? Google, or the ad networks?

I'm guessing Google, but they have enough power in the market that they could probably say "start serving HTTPS if you want your ads seen" and the networks would jump.

When Google started pushing HTTPS everywhere, a number of threads on HN criticized them for it. Some of the points made:

1. Imposes cost on people serving content even if they think the content doesn't need it in terms of machine resources.

2. Imposes an extra cost on people serving content, in the form of SSL certs. ("Why do I need to pay for this when I'm just hosting a plain vanilla homepage!?!?")

3. The PHK rant.

My point is, not everyone believes that every request should be encrypted (I do), and Google has face criticism on both sides of the fence from purists who believe HTTPS somehow takes away some of the original freedom and centralizes the Web a bit more by requiring cert-authorities.

Surely this matters only if Google's priority is to avoid criticism. If you guys believe in keeping end-users safe, it's a straightforward decision.

This is a gross misinterpretation of what Google wrote which is : 1) Changes are coming 2) Here is best practice for app devs-- use https everywhere. 3) If you can't use https right now, figure it out soon 4) During the tranision, people are going to fuck up. To deal with these fuck ups gracefully, you can enable NSAllowsArbitraryLoads while we get our partners sorted out.

> To deal with these fuck ups gracefully, you can enable NSAllowsArbitraryLoads while we get our partners sorted out.

And how many apps will forever more have NSAllowsArbitraryLoads enabled because a) Google can't get all their ad partners to switch and b) because devs don't remember to go switch it back off?

Presumably, Apple will remove that option at some point. It's normal deprecation.

Not that I agree they should offer that option, because of course there is no such thing as "gracefully degrading" security.

How exactly do you see browsers operate without it? It's not going away.

It is, actually; just maybe not on a timescale you're looking at things on.

Alternatively we could never depreciate it and use it forever, a much worse scenario.

It's a lazy recommendation. The first 2/3ds of the post are fluff to try and compensate for the fact that their recommendation in the end is "turn off this security feature". ATS is configurable to disable or enable for particular domains. The fact that we've known about ATS for over two months now and this is the best solution Google can come up with means they don't care. They don't care enough to read Apple's documentation and offer a helpful solution.

Ignoring that it seems like the "fix" in this blog post is a really bad idea, I find it immensely funny that folks think this kind of thing is some high level decision somewhere or something deliberate and well thought out, and not "a developer relations person who got asked to make a blog post about the solution he gave some customer"

Not that you shouldn't hold companies responsible, mind you, but everything everywhere is not some company (no matter who it is Google, Apple, etc) deliberately trying to screw you with some motive and purpose and grand conspiracy for how to achieve it in mind. Most wrong/dumb things are usually just simply random people being wrong or not thinking things through on the internet[1]

I guess a lot of folks have never worked at any mid-size or large companies :)

[1] The large company comment also applies to the possible retort that they should know better.A lot of large companies have 100's of "official" blogs. I'm sure corp comm/security/whoever would love to just have 1 they have to watch. But such a thing is not really the world.

Ignoring that it seems like the "fix" in this blog post is a really bad idea

This is a new restriction and setting on an OS that won't be released widely for months. When fully functioning this setting doesn't downgrade the security of an app, but simply breakingly blocks behaviors that aren't compliant.

Google advises you to start all new apps as HTTPS only, but to add this exclusion to have existing behavior of legacy applications, at least in the short term while they continue migrating the entire ad network to HTTPS.

There is an enormous amount of overreaction and, dare I say, hysteria throughout this thread, and you would think that Google just disabled SSL on the device or something, versus offered an approach for apps to continue doing what they're doing, presumably with the developer understanding the consequences.

I think you're wrong on the timing of iOS 9 being widely released. I think regular users are likely to have it within the month, and adoption should be faster than ever.

Nobody is talking about conspiracies here - just that this decision demonstrates Google's priorities.

Isn't your willingness to throw your colleague under a bus like this just as much a statement about Google culture as the original post?

I'm pretty sure Google will eventually enforce HTTPs for their third party ad-networks. The problem is that a lot of those guys live in the Paleolithic era regarding security, google needs their inventory, so it's not as simple as just saying: "dude you're going down if you don't do HTTPs now".

And it's also easy to just say "google should just suck it up and take their losses and just do HTTPS". You have to think that a lot of games rely on Google having a big ad inventory to monetize (and it's their only revenue model).

I don't work at Google, but do work in ad-tech. The HTTPS only move by Apple is great and will make a lot of things better... But it's going to take a while.

PS: Check prices of CDNs with SSL... They are also expensive.

It is ok. My guess is that by the time iOS 10 is released, this execption is not temporary anymore.

Then if you flip NSAllowsArbitraryLoads to true you will have to justify in the app review process why your app is needing that.

And something tells me that 'making arbitrary insecure connections to ad delivery platforms' is not going to be a valid reason. You may be rejected for that. Or there may at least be a big fat warning on the app store page that says 'beware this app talks to random insecure servers'.

It is a big win for users and the fight against lawless surveillance. Go Apple!

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

---

I.e. they know it sucks, and are working on something better.

Temporary fixes are usually the most permanent kind of fix.

Linkbaity title. Google is actually asking developers to add an exception for its third-party ad network, if the developers use Google ads in their apps, since Google can't guarantee all third-party ads will be TLS-enabled.

For reference, the current HN title is "Google asks developers to disable App Transport Security preceeding iOS 9 launch", while the article's title is: "Handling App Transport Security in iOS 9".

Well, they are asking to disable security completely. It's not like their asking to be added to a whitelist - which is probably not feasible.

The instructions they give are not creating an exception for any particular ad servers or just for Google's servers; they're asking developers to enable NSAllowsArbitraryLoads, which disables the security features app-wide for any URL.

Still, it's only for developers using their mobile ads SDK. It's not for all developers, which the title implies.

The title is ambiguous on this point and it's irrelevant to the fact that it's an ugly choice of priorities.

No, it is not only for developers using their mobile ads SDK. It is for any application that uses their ads SDK. The result of this is that this application will allow arbitrary insecure http loads by default. They take away a very useful safety net.

Why can'g google be more specific about the domains on which to allow insecure http traffic? Because their SDK loads content from arbitrary ad delivery platforms.

NSA -- coincidence?! I think not.

Can you imagine how many servers would they have to actually add exceptions for?

Actually, no, it's not. Google is, in fact suggesting that developers who use their ads SDK should disable App Transport Security, by allowing all arbitrary loads for all domains. The title is quite accurate.

If you read the article you would see that it's not a whitelist for specific 3rd party domains. Without knowing every possible 3rd party domain ahead of compilation such a white list is not possible. The recommendation is a white list for connection types. Which removes App Transport Security checks from all outbound URL requests.

ATS is configurable to allow arbitrary loads, but specify which domains you wish to keep secure. The author of the above post failed to document or mention that. Most developers will have known domains that they wish to keep secure, and there are options available to do that.

Correct but most non toy apps don't hard code URL's even for their own services. If my service is getting ddosed/updated I should be able to push a configuration change out to apps and have them request another arbitrary URL. I might not know ahead of time what that URL will be, and ATS should be enforced on those URLs.

Well that's just silly. There are plenty of high profiles apps out there with many users who have a set of known domains that their app will need to connect to. As an example, Facebook, will never push a config update that points their app do a domain other than Facebook. Most big apps will likely have backend mitigation for problems like DDoS. You're right that most apps don't hardcode URLs, but most configs also don't update domains to something completely unexpected on a regular basis. Also, even if you enable ATS on specific domains and you need to point your config elsewhere, following Google's instruction, that will mean your new endpoint no longer enforces ATS, which is still better than having disabled ATS for every URL in your app for all users from the start.

Google is not asking for an exception. They are asking developers to disable the security feature entirely.

Google can guarantee all third party ads will be TLS enabled simply by not making this request.

Edit: true statements of fact downvoted again

> Google can guarantee all third party ads will be TLS enabled simply by not making this request.

This is the crux. Google can force all third parties that display ads through their service to support TLS, but instead they're asking the other guy, the client, to change their product.

We reverted the submitted title from “Google asks Ads SDK users to disable App Transport Security preceeding iOS 9” to that of the article.

I wonder if the App Store Review team will check that setting? I've had a Mac App rejected because sandbox restrictions weren't narrow enough.

If it was my decision, I'd allow disabling App Transport Security if your app is something like a browser or an RSS client, were you need to connect to servers not under your control.

If you need to disable it to make ads work, I'd reject it.

No, they won't be rejecting apps based on that setting. They know this is a progressive measure, and maybe some day in the future they will... but if you watch this year's WWDC session on this topic, it's pretty clear that they won't be rejecting anyone.

For Google, delivering ads takes priority over security best practices and customer privacy.

Edit: an unarguably true statement, fully supported by Google's own posting, begins to be downvoted.

Google could just as easily tell the ad networks to upgrade to HTTPS, but they have chosen to ask developers to reduce the security of their applications instead.

I kinda agree in this case - why couldn't a similar blog post have been written targeted at 3rd Party Advertisers, requesting that they serve all content over TLS?

I suspect I know the answer, but it quite clearly shows where their priorities lie.

They are first, and foremost, the worlds largest advertising company.

This is how they make their bottom line and it will come at the detriment of anything else.

however, they value reputation too- so it's likely this will be fixed in future. But let's not throw exaggerations around. Google are not "for the people" but they're not against them either. Google are the new lawnmower[0] except they generally do things we like right now.

[0] https://youtu.be/-zRN7XLCRhc?t=2084

I downvoted you and will explain why.

Very often there are trade-offs between security, usability, financial gain, and various other factors. If security and customer privacy should always win absolutely, then the easiest way to achieve that would be to disable the internet.

The reality is that Google has decided that the damage to their bottom line (and the bottom line of the publishers who benefit financially from using their ad system) is greater than the likely damage of making this change. I can't say whether or not their right, but it's silly to pretend that Google simply said "Security or profit? Profit every time!".

Saying it's "unarguably true" doesn't make it so.

He didn't say "every time" (in the version I'm looking at). He said they chose profit over security (implying in this instance) and I think that's valid.

Google's intent is very straightforward; to disable TLS in the interest of their ad business. The post does not include how to whitelist domains (which should be recommended before you completely disable TLS). I did this today and yesterday to my iOS app and it took 2 minutes of editing Info.plist [0]. You shouldn't compromise app security in the interest of letting ad networks continue to serve unencrypted content to your user's devices.

[0] http://ste.vn/2015/06/10/configuring-app-transport-security-...

So, my question is, as a soon-to-be iOS9 user, can I tell that the developers have intentionally disabled security features in their apps? I'd love to be able to set a rule to just hide all non-ATS-compliant apps from my view of the App Store.

The exception is specified in the app's Info.plist. You won't be able to tell just by looking at the app on your iOS device, but you can download and unzip and IPA, and directly look at its plist to see if it has the NSAllowsArbitraryLoads key or not.

Reply on news.ycombinator.com