
Handling App Transport Security in iOS 9 - Kallikrates
http://googleadsdeveloper.blogspot.com/2015/08/handling-app-transport-security-in-ios-9.html
======
alexbock
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.

~~~
dijit
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](https://youtu.be/-zRN7XLCRhc?t=2084)

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

~~~
acqq
> 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?

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

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

~~~
uxp
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.amnesty.org/en/latest/campaigns/2015/04/7-reasons-
why-ive-got-nothing-to-hide-is-the-wrong-response-to-mass-surveillance/)

[https://www.aclu.org/blog/you-may-have-nothing-hide-you-
stil...](https://www.aclu.org/blog/you-may-have-nothing-hide-you-still-have-
something-fear)

[http://www.ted.com/talks/glenn_greenwald_why_privacy_matters](http://www.ted.com/talks/glenn_greenwald_why_privacy_matters)

[http://falkvinge.net/2012/07/19/debunking-the-dangerous-
noth...](http://falkvinge.net/2012/07/19/debunking-the-dangerous-nothing-to-
hide-nothing-to-fear/)

[https://en.wikipedia.org/wiki/Nothing_to_hide_argument](https://en.wikipedia.org/wiki/Nothing_to_hide_argument)

~~~
mtgx
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...](https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/)

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

~~~
ceejayoz
> 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?

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

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

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

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

~~~
inversionOf
_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.

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

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

------
st3fan
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!

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

~~~
Afforess
Temporary fixes are usually the most permanent kind of fix.

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

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

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

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

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

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

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

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

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

------
rubyalex
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-...](http://ste.vn/2015/06/10/configuring-app-transport-security-
ios-9-osx-10-11/)

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

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

