On Fri, Dec 11, 2009 at 04:03:01AM -0800, Duane Roelands wrote: > > 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. > > And this will be enforced...how?
The same way that oauth usage is enforced today: By attempting to educate users that they should not provide their login credentials to third-party websites. > Developers who want the easier implementation and easier user > experience will choose those methods, As noted in my earlier message, I dispute your assertion that "type in name, remember password, type in password" (even without an intermediate "try to remember which password was for Twitter, enter a couple incorrect and/or typoed attempts, give up, go find the piece of paper where password is written down" phase) is an "easier user experience" than "click, click, click, done". Again, I grant that "enter username and password" is more familiar from long use, but it is not actually easier. In my experience (both as a developer and as a sysadmin), users prefer authentication methods which do not require them to remember or locate credentials. They often initially resist these "alternative" methods due to unfamiliarity, but, once they've done it enough times that they no longer have to think about how to carry out each step, they are highly resistant to going back to more "traditional" authentication methods which require them to do more work to log in. The fact that methods exist which remove this extra work while also being more secure is just gravy for those of us who are concerned with such things. Once users are accustomed to the ease of passwordless oauth login from one site, I fully expect them to want that same convenience on other sites. I further expect that this is already happening as users find that the existing web-based oauth flow is easier for them than basic auth. (The exception to these comments is in the case where oauth fails to work properly, which can be intensely frustrating for users. However, this is much less commmon now than it was even three months ago and, more importantly, by allowing Twitter to focus exclusively on oauth, I expect that replacing basic auth with this third oauth flow will lead to increased reliability of *all* oauth flows.) > > It in no way prevents or discourages use of the existing oauth flows > > in scenarios where a browser is available. > > Prevents? No. Discourages? Absolutely. It provides an incentive > for poor security decisions by developers and users. Lazy developers will always take the easy way out, sure, and that's generally going to be less secure. But I'm still not seeing any coherent argument for how the planned third oauth flow will, in any way, be *worse* than the existing basic auth scheme. It may not be an absolutely perfect world in which absolutely nothing except Twitter itself is capable of accepting a Twitter password, but it's still a big improvement on what we have today. -- Dave Sherohman
