Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Handling App Transport Security in iOS 9

googleadsdeveloper.blogspot.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Handling App Transport Security in iOS 9

#51

Post by revelation »

ceejayoz wrote: post #34
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?

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.

Re: Handling App Transport Security in iOS 9

#52

Post by wlesieutre »

acqq wrote: post #44
uxp wrote: post #19

Earlier quoted context omitted.

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

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

Re: Handling App Transport Security in iOS 9

#53

Post by fein »

acqq wrote: post #44
uxp wrote: post #19

Earlier quoted context omitted.

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

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

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.

Re: Handling App Transport Security in iOS 9

#54

Post by noir »

Kallikrates wrote: post #40
noir wrote: post #38

Earlier quoted context omitted.

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.

Re: Handling App Transport Security in iOS 9

#55

Post by leonatan »

revelation wrote: post #51
ceejayoz wrote: post #34

Earlier quoted context omitted.

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

Re: Handling App Transport Security in iOS 9

#57

Post by cromwellian »

gress wrote: post #45
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…

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

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.

Re: Handling App Transport Security in iOS 9

#58

Post by gress »

cromwellian wrote: post #57
gress wrote: post #45

Earlier quoted context omitted.

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

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

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.

Re: Handling App Transport Security in iOS 9

#59

Post by uxp »

alanh wrote: post #46
uxp wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Handling App Transport Security in iOS 9

#60

Post by grrowl »

leonatan wrote: post #55
revelation wrote: post #51

Earlier quoted context omitted.

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.

Post reply on HN