StoreKit
Latest
DevJuice: Beeblex offers in-app purchase validation services
The security of iOS in-app purchases is a hot topic after an IAP hacking server was launched last week by a Russian developer. When The Next Web talked to Alexey Borodin, he told them he's since turned the service over to an unnamed third party -- and, as of that conversation, he'd collected only $6.78 in donations to cover his costs. While we strongly advised users to steer clear of this theft-of-service hack, that doesn't solve the problem for developers waiting on Apple to come up with a fix. In the interim, indie startup Beeblex may provide a validation workaround for developers. Some background: The underlying framework for all IAPs in iOS is StoreKit, covered in depth in my iOS Cookbook. Every successful StoreKit purchase transaction contains a receipt. This receipt, which is sent in raw NSData format, corresponds to an encoded JSON string. It contains a signature and purchase information. Apple strongly recommends that you validate all receipts with their servers to prevent hacking and ensure that your customers actually purchased the items they are requesting. You POST a request to one of Apple's two servers. The URL you use depends on the deployment of the application. Use buy.itunes.apple.com for production software and sandbox.itunes.apple.com for development. The request body consists of a JSON dictionary. The dictionary is composed of one key ("receipt-data") and one value (a Base64-encoded version of the transaction receipt data). I normally use the CocoaDev NSData Base 64 extension to convert NSData objects into Base64-encoded strings. CocoaDev provides many great resources for Mac and iOS developers. A valid receipt returns a JSON dictionary. The receipt includes the transaction identifier, a product ID for the item purchased, a unique ID, the bundle ID for the host application, and a purchase date. Most importantly, it returns a status. A valid receipt always has a 0 status. Any number other than 0 indicates that the receipt is invalid. Simply checking for the status may not be sufficient for validation. It's not too difficult to set up a proxy server to intercept calls to the validation server and return JSON {"status":0} to all requests. What's more, the receipt data that is sent along with the validation request can be easily deserialized. For that reason, always use receipt validation cautiously and as part of the overall purchase process, where it's less likely that proxy servers can override communications with Apple. Enter Beeblex. They just launched a free IAP validation service for iOS apps that, according to their marketing text, "verifies IAP receipts against Apple's servers" using time-limited tokens and strong encryption to limit IAP purchase end-runs. Encryption prevents "man in the middle" attacks; time limited tokens prevent replay attacks. Together they make it much less likely that a simple proxy could successfully spoof an IAP reciept and fool your app into providing something for nothing. It's an intriguing option. The advantage seems to be that Beeblex provides a server component for apps developed without one. Still, I'm not sure I'd want my apps to rely on a third party service when any service interruption could create a large angry user base. I wonder how Beeblex will pay for the bandwidth necessary to facilitate this service, and what would happen should they get hacked. Hacking could be a big deal, because it'd circumvent potentially hundreds or thousands of apps, instead of just one. [Update] Marco Tabini, one of the Beeblex developers, writes, "One thing that I wanted to point out is that we have, in fact, thought about the possibility that our service may go down by building methods inside the SDK that would inform the app of transaction failures due to networking errors. Of course, you are completely right that we need to show that we can grow and maintain the service, and we have a lot of work ahead of us in this respect. We'll do our best!" I'd probably feel a lot more comfortable buying from a well-known quantity than relying on a free start-up. Urban Airship doesn't appear to provide this kind of service. I gave them a call and a sales guy said it's not an option. [Update] CEO Scott Kveton replied to my email saying, "Yes we do IAP receipt verification." He adds a note from his team: "This is not really a security problem. It's long been known that you can put your own root CA on iPhones, and at that point you can basically do anything as a proxy. The people being bitten by this on the IAP side are only those that are not doing receipt verification with Apple out of band via a server, which is something we do in our IAP product as a standard. If you do out of band receipt verification, this fails and nothing is purchased/granted." My feelings on IAP and piracy are this (in no particular order): Developers use IAP too much, and often without regard for the user experience. Requiring IAP in apps for kids is, in my opinion, evil -- it should be strongly discouraged by Apple policy. If your app requires IAP to bypass gameplay segments, your game design needs some serious reconsideration. Focus on providing good experiences for your paying users instead of fighting piracy. If your anti-piracy protections tick off even one paying customer you have lost the war. Trying to fight piracy is a losing proposition with one exception. The one exception is scalable server support. If pirates are killing your servers, either find another app to build or try to limit the impact of unpaid customers. Don't save IAP unlocks in plain text files. There are keychains and other more secure solutions available.
Apple relents: in-app purchase for free apps allows demo-to-paid
Big news coming down the pike today for App Store developers. Apple has finally relented on a sticking point in the developer agreement, allowing in-app purchases for free applications. Finally, developers can distribute a free trial version of their applications, unlocking features from directly within the app as users request them (and pay for them). Until now, developers had to deliver two applications, with two unique identities, and no simple way to share data from the trial to the full version. (Yes, you could have used servers and shared keychains, but that's burdensome and kind of pointless.) What this news means is that developers can unify into a single application. One project to maintain and support, one place to consolidate reviews, one application sandbox for a single set of application data. Earlier today, Mike S. mentioned Gas Cubby and Gas Cubby Lite -- now there could be only one version of the app, with an 'upsell' inside to go from the light to full feature set. Expect to see these free-to-paid apps hit the store within the next few weeks. Apple will likely be deluged with new apps to review based on this news. Visit the App Store Resource Center for more details and check your e-mail account for the developer news that went out to all iPhone devs today. Q&A: Readers ask: "How will this affect the no reviews situation for free apps." Good question. Apple is going to need to sort that out. Since in-app purchases are registered to an iTunes account and associated with an application, it shouldn't take much work to limit reviews to those who have purchased something in a free app. We'll have to watch for this to happen because as things stand now, if you download an app, you get to rate it and developers know that free apps are thoughtless review magnets. "How will you deliver binaries?" All the functionality must already be built into the app. StoreKit allows you to unlock those features when users pay a fee. You can download data or extend a web based service but you can't download additional executable binary components. "Will I have to buy this twice for myself and other members of my family?" No, not if you both sync to the same iTunes account. It works the same as with applications. One app that has bought an upgrade extends to all apps for that same account. Each time your app launches, developers will check with App Store and restore any purchases that have already been made. So if you buy your upgrade on an iPhone, that upgrade will propagate to your iPod touch when it checks in."Will this help in anti-piracy measures?" Definitely. StoreKit allows developers to validate receipts, ensuring that unlock codes are only sent to paying customers. Add a hash-check algorithm for the current device and developers have better control over who gets to use their applications."What about promo codes?" I think Apple has learned its lesson about free apps/promo codes. I'm betting that they've already thought about a way to distribute in-app purchases via promo codes."What about people who have already bought apps?" Admittedly, this news is currently best suited for new products than existing ones. Devs who have built in shared keychains already have a slight leg up but for the time being you'll likely want to at least consider a new product that leverages this ability rather than trying to retrofit. As for people who have already bought a paid version whom you want to support while migrating to a free demo/in-app purchase model, you're likely going to encounter trouble until Apple irons out its policies and its solutions. Again, I expect Apple to provide some sort of solution shortly. And why all this trust in Apple? Any move that benefits developers ends up benefiting Apple in the end. This was a smart move on Apple's part, it's a good move for users, and for developers too. And it still has a long way to play out so keep watching for Apple's next steps."Who are the biggest winners here?" It's the people who have been putting out free and ad-support apps. They now have a way to turn off those ads and to solicit donations. In-app purchase doesn't have to be about buying and unlocking features. It provides a real solution for free apps to monetize, and for Apple to transform a huge part of their store into a paying model."Can free app devs charge an in-app purchase for nothing (i.e. donation)? Can the user repeat purchases or pick the amount?" Apple provides several kinds of purchase types and those purchases can be applied in multiples. For example, you can buy 5 hit point boosters or make 5 donations of $1. So yes, that model does work for donations."Can devs now charge for updates?" Not unless those new features are added as unlockable items. Again, this is something that Apple will likely address given the great demand for exactly that. Expect to see new App Store terms of service should that happen because the current one uses a "buy once, use and upgrade forever" model."What kinds of limitations should I think about?" TUAW reader Scott Kveton suggest the following in the comments for this post. He writes, "The key is keeping the app under 10 MB so it can be downloaded without wi-fi. A lot of developers can just 'unlock' functionality but when you get into actually delivery potentially large(ish) content to the device that's not possible. It also opens up the possibility to make the apps that much smaller on initial 'purchase' and then download content on the fly."
