Those settings, which are slated to arrive when Apple launches its iOS 9 operating system in September, will require all content that arrives on an iPhone (via apps, ads or otherwise) to use an encryption setting known as “https.” The setting ensures that third parties can’t read or track what users are doing on their phones.
In a blog post this week, Google told AdMob users to get ready for the new Apple setting. But if they’re not prepared, Google said, they can use a few lines of code to override it.
Go fuck yourself Google.
They simply restated something from a TechNote from Apple. It’s a setting in the apps info.plist file, I don’t get the drama this time.
A powerful ad-revenue-funded company advocated sidestepping security to maintain the flow of its ad revenue. Nope, nothing to get annoyed about.
Did you even read what Daniel wrote? Apple provided the SAME info. Stop the kneejerk anti-G reactions or your opinions mean nothing.
Jim, how is Google’s post different from Apple’s own? From what I see, Google is just a bit more explicit about what the exceptions are for.
If Apple wants to address that, they should make it transparent, e.g. by changing the status bar to red, indicating apps that are below standard. I bet that will be enough to eliminate most use of this feature.
I do understand that Apple has to allow that setting for the time being, many small developers will not have the backend infrastructure in place to make that happen immediately. But they should give them a reasonable deadline and then eliminate that setting.
Apple provides developers who can’t cope with the requirement (yet) with a workaround. Google advises others to use a less safe setting as the norm for their benefit. I consider that a huge difference.
The fact Apple released the workaround as well was not well known. On the surface it looked bad for Google. No need to attack the journalists or Google on this one now it appears.
Requiring https can be expensive and a lot of work for developers, especially those using distributed content delivery systems.
A bit harsh telling Google to go fuck itself. It isn’t doing anything to undermine the security if the security can be circumvented in the first place. Isn’t Apple supposed to be the closed ecosystem?
Have you not been reading Jim’s stuff? He provides insights and has access that many can’t and don’t. But unbiased he is not.
This is bigger than ads. I develop an app that uses an in-house developed API. The server which hosts that API uses SSL, but not the restricted subset that Apple is forcing in iOS 9. While we are looking at updating our server to increase security, we will not have that completed by the time iOS 9 ships.
This article is over-reacting to what google wrote. Google later updated the blog entry to clarify what they were saying (because many other people also misunderstood what Google had written).
There are some web sites which do not accept HTTPS (and LoopInsight seems to be one of those web sites). Apple knows this, so Apple posted the workaround that iOS developers can use to make their apps work in iOS 9. Apple posted it.
Google was then getting questions about the same issue, so they wrote up their own note on the method that Apple provided.
Any major transition like this requires a phase-in period. Apple wants to push HTTPS for good reasons, so instead of just “recommending” HTTPS, they’re forcing it. However, they’re also providing a legit workaround for developers who need such a workaround.
It should be noted that Google has also been recommending HTTPS for some time now. They updated all their own web sites to handle HTTPS quite some time ago. Consider this web page where they recommend what other web sites should do to “maintain your site with Google in mind”:
https://support.google.com/webmasters/answer/6073543?hl=en
Google has an open ecosystem, except where it’s closed. And those are generally the parts that matter.
Somehow Google no longer seems to show The Loop in my search results. Weird…
Can you explain what “restricted subset” means here?
so this is why the ad loads, yet the page you want to view fails! … or something like that. lovely fascist (or crap technologists – yes I’m looking at you Google).
why does this require “backend” infrastructure… I mean its https – which has been around for some time. I would think at least its a small yet important update to an existing webserver – maybe some certificate installs… though I think most “security” is fooked, some day “it” may work.
yeah, Apple is not a “closed” system, so much as curated, though I guess it is getting tricky (and less safe?) to JB an iOS device…
It is much more complicated than that. Hosted backends (databases, CMSs etc.) might not even have an https option with the current hosting company, or they might cost significant (for small developers) amounts of extra money. The second point is processing overhead; systems running on hosted virtual servers might need to be upgraded to more vCPUs and additional RAM to guarantee sufficient performance. The third point is (where applicable) load balancing. Depending on the setup https might require more expensive load balancers which can terminate and inspect the https requests to handle forwarding to the correct server/service. These are very expensive and only very few (and costly) hosting companies do even have them.
This is certainly no problem at all for big outfits, but for people just making pocket money on the App Store it might be prohibitive, or require extensive changes (e.g. moving from the current backend provider to Apple’s free CloudKit, which can require extensive code changes).
“App Transport Security” (Apple’s marketing name for the changes) requires servers to be using current TLS and current strong ciphers.
Many older servers (and even some new servers) are using outdated versions of TLS, or certificates generated with outdated, less-secure/insecure ciphers or signatures. SSL is then rendered less effective or entirely ineffective. Thus the “restricted subset” is TLS 1.2 and a bevy of modern, strong cipher and signature options, nearly any of which are ordinary if the administrator ordering a certificate is up-to-date on his or her SSL.
Apple’s latest changes are part of an ongoing, larger push to eliminate the use of weak ciphers. This is a problem server operators HAVE to solve, period, but Apple’s timeline is shorter than most—and Apple’s user base is substantially larger than most.
I know what Apple means. I’m curious what Charles means. Does he mean he’s offering “security” via an older, broken protocol like TLS 1.1 or bad certificates? Is that really a thing website operators do? Because it’d be better to offer none and at least be honest about it.
Sorry, both the article and this summary are complete bullshit. If security can be undermined it’s not secure in the first place. Apple dictates secure as the new norm, but if you’re not ready for it yet, you can explicitly opt out of it for the time being. Presumably Apple will remove this opt out eventually. That’s standard deprecation practice.
Google’s ad network is hit quite hard with this new policy and needs to point its customers to this option for those who missed it. Period. End of story. No actual developer is batting an eye over this. Only writers looking for scandalous headlines.
Charles and Colin are right except that the certificate isn’t what has to necessarily be upgraded. It’s the server software, specifically OpenSSL on UNIX and Linux machines. If your OpenSSL can’t do TLS1.2 with a narrow set of strong ciphers, then the connection fails. If you’re running Tomcat on Java 6, then you’re stuck too. Do you risk upgrading to Java 8 which could likely break your app just for better SSL?
When you set up your server, you can tell it to start with TLS1.2 and downgrade to TLS1.1 or TLS1.0 or even further. It’s even more complicated because maybe the client can use one of the really strong ciphers but only with TLS1.0.
Thankfully your OpenSSL library handles those decisions. Unfortunately your distro may keep you on an old version of OpenSSL, unless you decide to compile one for yourself and then you’re on your own for further updates.
Not complicated enough? Older clients can’t use the new standards and many times a server admin must disable the downgrade options. This can translate to lost business because the IE6/7/8 crowd may be left out in the cold. Who uses those browsers? Without trying to be ageist, it’s likely our parents who likely have more disposable income than you or me.
It’s also difficult for folks like me who support customers who bought our software years ago and run their own server stacks. We’re a Java shop and upgrading Java 6 to Java 8 is risky, but unfortunately it’s the best option we have. Still, that means contacting those folks and scheduling downtime, etc.
So for now, I’m disabling that strict option in my app, specifically with the NSAllowsArbitraryLoads Info.plist key. I plan on reversing this as quickly as possible.
https://www.ssllabs.com/ssltest/ will open your eyes.
Oh, nice. I’ll try it against a few sites. 🙂