Episode 31, recorded Saturday March 31st, 2012 – UDID FIre Mach ado about UDID, jobs for iOS developers abound and my guest today is Appsfire Co-Founder Ouriel Ohayon. Ad News Apple informed developers via e-mail that iTunes Connect will have individual reports for Sweden and Denmark from now on. For March, app sales earnings in Sweden and Denmark will be split and reported in two different documents, one covering the time period before the change and one covering the time period after the change. Earnings from sales that occurred before the change will be in the Euro-Zone (EUR) financial report. Earnings from after the change will be in the new financial reports for Sweden (SEK) and Denmark (DKK). I am wondering what the benefit to us developers will be. Are the reporting guys SEARCHING for work to do that nobody actually cares about, just so that they are not bored? Speaking of non-sensical changes: Apple invented two new price tiers. Tier 63 is $124.99 and Tier 69 is $174.99. Both tiers are available for both apps and In-App Purchases. Can anybody explain to my what this is good for? Are apps too cheap? Does Zynga want to sell more expensive In-App-Crap? You know, lower levels of tiers usually correspond with the price in dollars. The geek in me revolts, what is the secret algorithm here? UDID, or didn’t you? Now that some rumors seemed to indicate that Apple might be beginning to reject apps that are using the unique device identifier developers are scrambling and are ripping out the trusty old identification code and replacing it with something new. But that only seems to be part of the story. Tapbots published the original rejection letter they received from Apple and this contains some very interesting information. This letter says that they where sending identity information to their server without having asked the user. Apple seems to actually do a man-in-the-middle attack on HTTPS when reviewing our apps. Tapbots was sending the UDID in a HTTP GET request over HTTPS. If you simply look at the data packets then you don’t know the URL that is being requested because the first step in the HTTPS is to do a CONNECT. Then the GET is performed and already encrypted. This man-in-the-middle means that Apple has a tracing server that spoofs the HTTPS target and re-signs the packet such that it is still accepted by the URL connection on the device. This is technically easy, I blogged about how to spy on any app’s traffic with the Charles debugging proxy app. What’s interesting that we learn for the first time that not even encryption is holy to Apple. So if you are sending something naughty to your server, then don’t rely on HTTPS thinking that nobody can see the contents. Better to send hashes instead of plain text. This is sort of similar to when the Path app sent your address book. Many people ask: what should be use instead of UDID and the privacy advocates generally say: nothing. A user is not the same as a device. About the only market that requires to uniquely identify devices is advertising, especially when it comes to conversion tracking. If you need to have some sort of temporary identifier then you can use CFUUID to create one and then you can store it in the keychain. This will persist even when the app is removed as opposed to the user defaults. For those who are developing libraries for ad networks the de facto standard has become the OpenUDID project which is available on GitHub. It was developed by on of the founders of Appsfire. There is a second competing project called SecureUDID but when I surveyed the market as to which is winning I found that most ad networks had switched to using OpenUDID. This includes the MobFox framework which you might know that I originally developed. Flurry Analytics reports the relation of income of the three major app stores: Apple’s app store, the Amazon app store and Google Play (aka the Android app store). The comparison they came up with is this: $1 on Apple’s App Store is ...