“Apple says it cares a lot about privacy,” Mark Bergen reports for Re/code. “Hence, its new iOS 9 operating system will boast a new feature, called App Transport Security, or ATS, which is supposed to require iPhone app developers to use an advanced security protocol. The idea is to keep the operating system lock tight.”
“But Google also says that not every app developer and mobile publisher will be able to work with Apple’s new standards, at least not yet,” Bergen reports. “So, when those app publishers that aren’t running the protocol meet Apple’s new encryption, their mobile ads won’t run. No ads, less revenue.”
“On Wednesday, Google gave publishers a pointer,” Bergen reports. “It published the five lines of code to disable Apple’s encryption, offering them a ‘short-term fix’ before they get up to speed with the security rules that both Apple and Google are pushing. (It should be noted: Disabling the protocol doesn’t appear to violate Apple’s rules.)”
Read more in the full article here.
MacDailyNews Note: In an update, Google’s Tristan Emrich (Mobile Ads Developer Relations) wrote:
We’ve received important feedback about this post and wanted to clarify a few points. We wrote this because developers asked us about resources available to them for the upcoming iOS 9 release, and we wanted to outline some options. To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.
We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products.
Evil
Google’s Ex-Mole: Oh No! They got out of the gates before us again! By the time we get SAT out (our version ATS), we will be shut out yet again!!!!
Google Ex-Mole’s CEO: Never you worry Mr Mole, we will sit on ATS with SAT after we bury ATS with the five lines of code sent to us in our App Developer Software from Apple inc.
Ha! ha! mwaaa ha! Haaaaa!!! Yep, we are not Evil nor do we see or hear it!!!
Google dwarfs Satan on the Evil Scale!
LOL. This whole “tip” benefits nobody but Google. App developers and advertisers can get around this problem just by switching ad providers.
Desperate.
I still just want a setting that turns off ads entirely on the phone. I’m not against developers making money. Just charge me for the freakin’ app instead of proclaiming it’s “free”.
Many apps offer in-app purchases to make them ad-free. Best of both worlds.
Or simply have ‘free’ ad supported versions as well as a paid version of the same App.. Angry Birds come in both ‘flavors’..
I don’t like those as much because it pollutes the app store with essentially duplicates of the same app. That was necessary in the pre-in-app purchase days, it is not needed now except where the free version is smaller due to not containing resources found only in the paid version.
And even that becomes moot with the upcoming “app thinning” in iOS9, where only necessary resources are downloaded when called for.
If the “app thinning” works the way I imagine I guess you could release a single version then that will show ads till you pay for the App via a one-time in-app payment. I’m sure there are already Apps like that in mobile Apps stores already. Do you think the “app-thinning” allows removal of no longer needed resources too? (e.g. above example of removing ads after in-app payment).
There are many apps that do exactly that (one-time IAP, no more ads).
I’m not sure about removing resources afterward… however, most ads are temporary and downloaded for just-in-time display anyway, so the only thing to thin would be to strip out the code that handles ads. Not much point doing that though, that code would be minuscule, and would just be flagged as inactive/disabled after the IAP to disable ads.
True.. I guess if iOS9’s App manager allows you to clear the cache for individual Apps that might get rid of the residual downloaded ads after the in-app payment is made.
I see web ads as coming from the pit of hell and I am an agnostic.
IMHO ad supported applications should be BANNED from the App Stores OSX and iOS. The same for apps that are designed to mine wallets with in-app purchases. Some use of in app purchases is legit, but some is abusive to the end user.
I would rather pay a proper price for an app than get it free or on the cheap and get milked for in app purchases to make it work properly or eliminate ads.
Some some pricer apps, I want to test drive them first with a free demo version.
I hate ads too. I’m also a developer though. My goal when possible is to make an ad supported version of my app but give people the option to pay a one time fee instead to get an ad free version. I like to give people choice. There are those who don’t mind ads and there are those who would rather pay for the app. I’m the kind who would rather pay.
I concur. Freemium games have ruined the App Store. They are a cancer that should be eradicated.
The problem is that a small percentage of people are willing to spend quite a bit of money in “freemium” apps – hundreds of dollars in many cases. The freemium approach preys on children and susceptible adults. Just another $19.99 or $49.99 or whatever will get me the Keg o’ Gold that will enable me to move up a level and get the Sword of Omnipotence without having to wait two weeks. But then you find out that the company has released a new level,or a special feature that requires another Keg o’ Gold of Cask of Jewels is required to get past the next level…and so on. Why sell an app for $2.99 or $4.99 or even $9.99 if you can get people to pay again and again?
Real Racing 2 was a pretty good game that cost around $7.99. You opened up new cars and upgrades as you raced and gained experience, and it worked pretty well. Real Racing 3 went freemium, and it is engineering to disadvantage and/or annoy players enough to spend lots of real money on virtual cars. If you are not willing to slowly accumulate gold through gameplay and watching ads, then buying the high end cars will cost anywhere from *real* USD$40 to USD$90 to buy them. But gold is also required to upgrade cars, so it will cost tens of USD$ more to fully upgrade the car and be competitive. Not surprisingly, many of the RR3 time trial and team racing challenges involve these high-end cars.
I, myself, have played RR3 for many hundreds of hours over the past couple 18 months or so. I have 105 out of 118 cars and about 35 of those 105 are fully upgraded. Even after all of those hours of racing, my best guess is that it would take around 10,000 RR3 gold to get all of the cars and fully upgrade them. That is about as much gold as I have collected to date while racing in the game. And Fire Monkey occasionally updates RR3 with new tracks and new cars, ensuring that I will never reach the end without spending real money (which I will never do) and coaxing children and addicted game players to purchase another installment of gold.
I would have been willing to purchase the entire game for a reasonable price – perhaps $19.99. And I would also be willing to pay reasonable amounts for worthwhile updates with new tracks and cars – perhaps $2.99 or $4.99. But I intensely despise any company that abuses the freemium model and they will never get a dime of my money. Consumers must unite to make the freemium game model as unprofitable as the games are unplayable.
.
If the developer feels he can’t make sufficient money to make it worthwhile to maintain or grow the app w/o in-app purchases then, perhaps in the case of games that include in-app purchases for upgrades and such, have separate leaderboards for those that pay for upgrades and those that have built up their account through hours invested in the game.. Nothing more frustrating than seeing someone ‘beat’ your hard won score by paying for it. 😛
Same with the Asphalt Racing Game among many others.
Charge a fair price for the ads and leave it alone.
Apple to google: we want your ad business and this is just the beginning, well second or third beginning. Anyway, got to start somewhere
Yes. Unbundle. Unbundle the app from the ads. Let consumers know exactly what they are “buying”.
I’m sure Apple will find a way to block this code, even if it comes to disallowing Apps containing it in the App Store.
With a method approved by Apple.
No. I think you need to read about this situation more closely. Apple NEVER approves of using anything but a secure connection (nothing less than HTTPS) between an app and its ‘back end’. The only caveat Apple offers is:
If your app needs to make a request to an insecure domain, you have to specify this domain in your app’s Info.plist file.
What Google served up was NOT Apple’s designated solution at all.
https – it’s good… yep…
It’s security is dependent on the host’s site to have an appropriate certificate from a trusted authority.
Ban GOOGLE. C’mon Apple. Do it!!!
Errrr… Guys…
You know that this is the exact same workaround Apple is recommending??
== If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. ==
https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html
Just saying…
No. You either didn’t read Apple’s ‘What’s New in iOS note’ or didn’t read it carefully. Seeing as this is the second time in this thread spouting ignorance on the subject, I’ll post Apple’s ENTIRE quote on the subject, found at the URL that YOU provided above:
App Transport Security
App Transport Security (ATS) enforces best practices in the secure connections between an app and its back end. ATS prevents accidental disclosure, provides secure default behavior, and is easy to adopt; it is also on by default in iOS 9 and OS X v10.11. You should adopt ATS as soon as possible, regardless of whether you’re creating a new app or updating an existing one.
If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn’t follow this requirement, an error is thrown. If your app needs to make a request to an insecure domain, you have to specify this domain in your app’s Info.plist file.
Apple’s ‘workaround’ is to specify any required insecure domain connection in the app’s Info.plist. This is NOT what Google cooked up as a solution.
The only positive thing to say is that Apple does offer this is a working code. But NOWHERE does Apple advocate using it. What Apple does advocate is entirely clear. It’s NOT the code Google obnoxiously tossed into the ring.
No Derek,
It’s you who didn’t read my post. You also missed the update that even MDN has posted.
I clearly stated that this is the WORKAROUND Apple recommends. I hope I won’t have to explain what a workaround is.
And here is the quote from Google that surprisingly even MDN published:
—————-
To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.
We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products.
—————-
So… Even the most diehard fanboy won’t be able to contest that Google simply provided a code snipset of a, once again, WORKAROUND that even Apple proposes AND, that Google does ONLY recommend to use it if no other more secure way exist.
I give you one point on the fact that the solution Google propose relies on a slightly different technologies… But only slightly… What it does in the background is really similar.
I can understand that, especially on MDN, it must hurt to admit it… But no… Google didn’t do anything bad here and many people just jumped on the traditional anti-Google bashing train.
Oh… And don’t understand me wrong, but I won’t start a pissing contest here… So feel free to continue without me. Enjoy.
I stick by exactly what I posted because I read the developer notes Apple provided. You’re off on a loony tangent that is NOT AT ALL what Apple prescribes, aren’t you.
IOW: Google shoved its face where it was NOT welcome. Nothing new. It’s called ‘Google arrogance’. It’s real, tangible, continual and detrimental to their well being. Why anyone finds Google omniscient, scary, or remotely worth their current stock price, I cannot imagine.
Here’s How To Bypass Android.
Buy Apple gear.
Google gave publishers a pointer. It published the five lines of code to disable Apple’s encryption.
Does ANYONE still believe Google has any integrity? What a hellish outfit.
Well, maybe ‘hellish’ is too strong. At the very least, Google is doing its usual barging into the room without an invitation and interrupting the party with a loud expulsion of gassssss.