Hacker News Reader

Comment by stavros | Hacker News Reader

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.

View on HN

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.

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

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

NSA -- coincidence?! I think not.

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.

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.

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.

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

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.

Reply on news.ycombinator.com