On Thu, Dec 10, 2009 at 10:40:20AM -0800, Duane Roelands wrote: > Many of us in the developer community have been strongly pushing the > point of view that third-party apps should never be asking for user > credentials. We did so because we believed that Twitter was firmly > committed to the security of the ecosystem and protecting the accounts > of its users. It now appears that this belief was in error.
I see no evidence that Twitter is anti-security here. > This decision is going to actively hurt developers who chose the > more secure implementation. Application A just lets me log in with my > Twitter credentials, but Application B wants me to go through this > harder process. Most users will choose option A, and the more-secure > application B loses users. this decision punishes developers who > chose the more secure model. It's disappointing, because a lot of > developers have worked very hard to bring OAuth implementations to the > community that were robust and secure and **didn't require a user to > hand over their Twitter credentials**. 1) Given that third-party apps are currently able to request username/ password and use them for Basic Auth, I do not see how apps being able to request username/password and use them for oauth makes things any worse. I can see an (IMO weak) argument that this may prevent things from getting better, but it will not make them worse. 2) I seem to be the odd man out here, but I consider the current oauth web application auth method (which I'm assuming is "the more-secure application B") to be the easier method. Click-click-click, done. No typing in my username or remembering my password required. Username/ password is definitely the more familiar method for most users, since it's what they've been using all their (online) lives, but I reject your assertion that it's easier to complete. > There was a great opportunity here for Twitter to be a security leader > in the social network space by saying "We don't want our users giving > their Twitter credentials to anyone except Twitter". It's a shame > they didn't stick to their gun; the result is going to be a less- > secure ecosystem. They still can stick to their guns and say "We don't want our users giving their Twitter credentials to any *web site or desktop application* except Twitter." It seems clear to me from Raffi's comments on it that this third oauth flow is intended solely to enable Twitter use from embedded applications or in other environments in which it is not possible to use the existing oauth flows because there is no way to bring up a browser. It in no way prevents or discourages use of the existing oauth flows in scenarios where a browser is available. Really, the current lack of oauth delegation is a far bigger obstacle to being able to say "don't give your Twitter password to anyone else" than the ability to turn a username/password into oauth credentials will ever be. -- Dave Sherohman