There are a lot of applications that would like to persist user state for one reason or another and right now there are two options:

Option 1: tie everything to the device identifier.

Option 2: implement your own authentication and registration mechanisms.

From an end user perspective both of these methods provide me with a less than optimal experience.

Option 1 is convenient in that I don’t have to provide up front information, but if I ever upgrade or change devices then all of my information is lost.

Option 2 solves the problem you encounter with with option 1 and even provides a way to access my information across multiple devices, but at a serious burden. Now I have to complete a registration process where you choose a unique username, password and probably an email address. Filling out registration forms on my tiny iPhone keyboard is never a great experience and when you are done you have yet another set of credentials that you have to keep track of. In addition, the second option is non-trivial to implement from the developer perspective and requires a decent amount of server code.

“iTunes Auth” would be an easy way for a developer to invoke the iTunes login dialog and then retrieve a unique token identifier when a user successfully authenticates.

The token would be unique to the application and user and would provide no information about the user. It would just be a constant identifier the developer could use to associate persistent data to.

Technical details

Below is an overview of the implementation I have in mind. It’s not extremely in depth, but should give you a pretty good idea of what the implementation would look like as an application developer.

First your application would prompt the developer to sign in. For most applications this would only need to be done once per device + application combo.

[AuthKit authenticateUser];

Which would bring up the standard login dialog:

Once the user has authenticated your application might receive a callback similar to the one you get after registering for push notifications:

- (void)application:(UIApplication *)application didAuthenticateWithUserIdentifier:(NSData *)userIdentifier

With the user identifier being:

hash(Bundle Seed ID  + iTunes Username)

Where the hash function is something like sha256 and the Bundle Seed ID is an identifier that is unique to an application or group of applications. This way each developer’s application has a different identifier.

OAuth would be another options, but I don’t see Apple exposing this as a web-service outside the device due to the phishing concerns so I don’t know if it’s really necessary.

Security

The method described above doesn’t provide any information about the user to the developer so no personal information is exchanged.

Even though the hash for that user+bundle identifier will always be the same, each application will have a unique hash for that user. This way it is impossible to determine if a user is the same from one bundle id to the next preventing any concern about libraries collecting analytics about user habbits across applications.

Phishing could become a concern since an application could present a login dialog similar to the actual dialog, but this is currently possible with StoreKit; therefore shouldn’t create any additional concern.

Summary

iTunes Auth would provide a simple solution to allow developers to easily persist user information without having to implement complex registration systems while giving users the ability to use the credentials they are already have. The unique nature of the user hash would allow developers to consistently identify a user without exposing user information limiting security and privacy concerns.

http://www.9to5mac.com/AT-T-20mb-app-size-436859856

http://bacn.me/zhe

I had the opportunity to take a Eagle CAD workshop given by the local Dorkbot group. It turned out to be a blast. Probably the best $35 I’ve ever spent – seriously it was only $35 and I got 6+ hours of instruction and three copies of the circuit board I designed!

Below is a picture of the CAD drawing of the circuit board. It’s should appear pretty close to scale on your screen. It is just a Atmel attiny13 micro-controller powering a RGB led. Which is pretty similar to my RGB nightlight, but with much cheaper parts and a better footprint.

One other interesting bit: I don’t own a AVR programmer, I’m actually using my Arduino compatible board running mega-isp to program it.

I posted a ton of photos showing the construction. I purchased all of the materials at Craftwarehouse and the Arduino board from Modern Device. The RGB LED and DC barrel jack I got at Radio Shack and the power source is a recycled 9v wall wart that was for an old RC radio.

An LED powered nightlight is perfect for a child’s room because it has a long life, consumes very little power and most importantly it doesn’t get hot!

I had to turn it off the first night I put it in my son’s room because he wouldn’t go to sleep. Instead he stayed up saying: ‘Oooh, it’s blue.’ ‘Oooh, it’s greeeeeeen.’

Host example.com
    User root
        IdentityFile ~/ec2/example.pem
Host example2.com
    User gitosis
        IdentityFile ~/.ssh/id_rsa

So since I’m at OSCON I thought it would be a good time scratch that itch while giving something back.

Pretty simple hack, but infinitely useful for me personally. Hopefully someone else will find it useful as well.

So here it is in all it’s glory. It’s compiled for Mac-Intel/Leopard.
Download:
HTTP Client – with ‘Web View’