The thing that bugs me about this model is that it's not challenge-response, so someone can play man-in-the-middle.
While it's possible to hijack someone's phone number, as demonstrated, it requires a relatively high amount of effort per target. Whereas if you compromise a network segment somewhere (with DNS and a rogue SSL cert or whatever you need), you could just sit there, farming authentication cookies. Have your MitM check the "authenticate this computer for 30 days" checkbox and you've got a nice little collection to work with.
I was talking to someone recently who likened it to a shifting pendulum. For a while, he told me, terminal control languages were sufficiently complex that you could send a program to run _on the terminal_, and then things shifted back to running things where you store them on the server.
Now there's HTML5 and javascript, the world's most complicated terminal control language.
Unless your product is something that builds on Twitter's platform, I wouldn't recommend it. It means your users don't have a choice about how they're authenticated to your site, and
A) Failwhale, anyone?
B) Twitter doesn't provide serious options for protecting their users' login credentials. It's the same username/password combo which is easily phished & replayable.
Sadly, I've pretty much given up on the hope that we'll have a healthy ecosystem of OpenID providers, but at least Google's login system does offer some two-factor options.
Bah. I've been happily using Google services with a non-Google email for years now, but when I created a gmail account for that ID, all my notifications from all google products (e.g. google calendar notifications, notifications from other Google products like Google Code) suddenly started going to the gmail mailbox instead of the address they'd been going to all along.
Fortunately I was able to delete the gmail account to reverse this, but it was relatively difficult to find the "turn off gmail" button. And if all new accounts get gmail, they may stop letting you turn off gmail at all.
Yeah, and this is the one thing I didn't see addressed in the article at all. It doesn't have to be about "interesting problems," it's that your entire business model is based on something that no tech-savvy 20-something wants to support.
While it's possible to hijack someone's phone number, as demonstrated, it requires a relatively high amount of effort per target. Whereas if you compromise a network segment somewhere (with DNS and a rogue SSL cert or whatever you need), you could just sit there, farming authentication cookies. Have your MitM check the "authenticate this computer for 30 days" checkbox and you've got a nice little collection to work with.