Why OAuth works on iOS

John Gruber writes today about OAuth vs xAuth in his post “Twitter’s Shit Sandwich”. In it he declares that “So long as you remain within the app, there’s no security advantage for OAuth … but there’s a huge decrease in usability, simplicity and clarity to the user”.

Context: xAuth and OAuth are two ways to log in to twitter. With xAuth, an iOS app asks you for your username and password. You have to hope that they dont abuse it. Online apps use OAuth: you are redirected to a page from twitters servers, and the app never sees your password. On the iPhone, some apps use OAuth, in an embedded web browser. In this case, the app can steal your password, even though you are using OAuth. It offers no better security, and adds complexity.

But there is another option for app developers, and it has a huge advantage over xAuth and in-app OAuth: you don’t have to type in your password. All the app has to do is open the regular safari browser on the phone, log in using OAuth, and then redirect back to a custom url. Because it’s safari, the username and password for twitter only ever have to be entered once, and, because its safari, I’m happy to do so. Is it more complicated than xAuth? That depends on how you measure “complicated”. If my password is already in safari, then it seems to me that not having to enter my username and password, but instead just press “Yes”, is way less complicated.

What’s Hot!

Our Startup Weekend app is #8 in Educational Games on iTunes! Tireless work by Jeff Solomon, our fearless leader, and Garrett Lauringson, our in-your-facebook expert, coupled with more regular updates appears to have paid off!

Screen_shot_2011-05-09_at_3

Ok, you called my BS on that one

Last night I attended “Steve Blank Meets San Diego”, organized by Brant Cooper. The event was packed – standing room only. I wasn’t sure what I’d learn from hearing the guy speak (I’ve read all the books, right?) but I was pretty certain I’d get something. Well, what I got was that I didn’t have a clue about the two most important things: What Is a StartUp and What Does Scale Mean. The latter, in a way, defines the former. A Start-up is “a temporary company” to search for a business model that can scale. And “scale” means add people/servers/factories/whatever in order to execute the discovered model. The business model might be realized by a single McDonalds restaurant, and “scale” here means “open 1000 restaurants all exactly like it”. My job, as a tech-company Founder, is to search for that business model, and then be willing to hand it off to a team whose experience is massive execution.

The last question of the night was from a young man who was clearly facing this problem: “But how do you know when you’ve got the right model?” Steve’s response was “Ok, you called my BS on that one.”  That got a laugh, but he was sincere in his explanation. Often times, in his experience, a company has found “a local maximum”, but not a model that will scale. The most important thing to do when you realize this fact is, not to fight it, but return to “iteration without crisis”, and “fire the entire sales team”. They arent needed yet, and they are a cash burn. The company made a mistake in thinking they’d found the model. It mustn’t make another and try to carry on regardless.

New Years Resolution: Share Less

OSX 10.6 made some great improvements to samba file sharing, but if you are an admin, it will kindly share every single file it can find. Bugger. My goals for today, then, were:

  1. Disable automatic sharing of everything under /Volumes
  2. Disable automatic sharing of my home directory
Turns out, both of these features are enabled in a dynamically created file by OSX. That is, if you edit this file to disable them, they will magically come back. Fortunately, you can modify the smb.conf file after the inclusion of these dynamic files. I added my lines just before the [printers] section:
...    
    com.apple: show admin all volumes = no

[homes]
    path = /Users/%S/smbhome

[printers]
...
Then restart the smbd service. Needless to say, you’ll need to be root for all of this.
I’m not totally worried about the fact that using samba requires storing my password less securely, or even that older versions of windows will send it plain text. Even if someone has my password, they still can’t log in remotely: they’ll need my ssh keys and their passwords too.

MonoTouch and Resharper

I have tried many ways to make Visual Studio and Resharper play nice with Monotouch.dll but no matter what I did, my code either had to reference .NET only, or mono only. This means no running unit tests in Resharper. Finally I broke down and spent 8 hours yesterday hacking (in the “and slashing” sense) together a solution. Only afterwards did I think of a better one, but whatever. Its done. The result is a mutilation of Jason Bock’s FileGenerator Add-In for Lutz Roeders .NET Reflector. I call it the Bare Bones Generator. I feed it Monotouch.dll, and it spits out the source code for an assembly with all the same classes, methods, fields etc as the original, but with none of the code. It is like a header file for .net. I can compile it, and reference it on the windows side. On the OSX side, Mono Develop uses the real dll and all works as expected. 

Result: R# works. Unit tests work. Jamie happy.