Handling App Transport Security in iOS 9 • Hacker News Board

Re: Handling App Transport Security in iOS 9

#31

Post by imglorp » Thu, Aug 27, 2015, 4:31 PM UTC

uxp wrote: post #24

cromwellian wrote: post #20

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 s…

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.

Re: Handling App Transport Security in iOS 9

#32

Post by inversionOf » Thu, Aug 27, 2015, 4:32 PM UTC

DannyBee wrote: post #30

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 everyw…

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.

Re: Handling App Transport Security in iOS 9

#33

Post by st3fan » Thu, Aug 27, 2015, 4:34 PM UTC

StavrosK wrote: post #15

alexbock wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Handling App Transport Security in iOS 9

#34

Post by ceejayoz » Thu, Aug 27, 2015, 4:37 PM UTC

boo_radley wrote: post #27

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?

Re: Handling App Transport Security in iOS 9

#35

Post by noir » Thu, Aug 27, 2015, 4:37 PM UTC

boo_radley wrote: post #27

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.

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.

Re: Handling App Transport Security in iOS 9

#36

Post by st3fan » Thu, Aug 27, 2015, 4:38 PM UTC

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!

Re: Handling App Transport Security in iOS 9

#37

Post by joshstrange » Thu, Aug 27, 2015, 4:38 PM UTC

cromwellian wrote: post #20

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 s…

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)

Re: Handling App Transport Security in iOS 9

#38

Post by noir » Thu, Aug 27, 2015, 4:40 PM UTC

Kallikrates wrote: post #12

stavros wrote: post #3

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.

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.

Re: Handling App Transport Security in iOS 9

#39

Post by noir » Thu, Aug 27, 2015, 4:41 PM UTC

skywhopper wrote: post #28

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.

Re: Handling App Transport Security in iOS 9

#40

Post by Kallikrates » Thu, Aug 27, 2015, 4:47 PM UTC

noir wrote: post #38

Kallikrates wrote: post #12

Earlier quoted context omitted.

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.