Hi Damon, > None, taken. I am a network sysadmin, developer and ultimately businessman so > I do know a little bit about how they are all related.
Cool, so we have exactly the same background :-) > I understand you are in a slightly different position having to deal with > xAuth. However, xAuth is not a secure system in itself. Any system that > passes a user and password through a third party cannot be secure. Yes you > are "supposed" to discard the info after the initial tokens are exchanged and > received back, but there is no proof that actually happens. A third party > still had access to my username and password. This seems more like a question of philosophy. You certainly cannot say xAuth / disclosing passwords to third party apps is insecure while oAuth is secure. In the end, the risk is exactly the same: a malicious app impersonating you and sending spam links or fishing links in your name. No matter if you use xAuth or OAuth. Such a malicious app can and will do the very same. The only advantage of OAuth for the user: he doesn't need to change his password. The obvious disadvantage of this: the user thinks that OAuth makes his password secure. But you - as an admin - know very well that passwords of "users" are seldom secure. Usually, they use the same password for everything and it's their name and their birthdate or so. But they shouldn't. You should use a specific password only for Twitter, another for Facebook, another for ... and so on. Why have people been so upset about the Sony hack? Their usernames and passwords are the same for all the services they use ... > In your case you are limited by the the underlying OS from achieving a > traditional OAuth flow. Your work around sounds like it will suffice and is > no less potentially insecure than the existing if properly setup. Well, the workaround makes me a Twitter service "provider" and makes me responsible to take care of my users OAuth tokens. I think there is a difference. If I tell my users that I have access to their accounts soon, whereas before I haven't had, I think they will find the new solution less secure. > You say you "know nothing" about your users under the current system, and > that's the way it should be. But that is you in your specific case, being I'm > sure an honest developer. Allowing insecure methods to continue though, > lowers the security of the whole. It only takes one bad app to screw a bunch > of users and ultimately it's Twitter who would have the proverbial egg on the > face. The app developer would be banned and forgotten. But this will happen anyways. Twitter said they have to revoke hundreds of apps per day. It is happening and xAuth/OAuth is the way to keep the platform clean. There will be malicious apps even without xAuth. Actually, I bet that Twitter only has to revoke OAuth apps and never xAuth apps. Only Twitter itself could disclose this info, but my reasoning is: if someone breaches the privacy, will he get access to xAuth again? I mean, we developers would risk a lot. That's why there's some "approval process" in place for xAuth. > I'm not happy about this change being forced down everyone's throat so > quickly as much as the next developer. In my option more levels of privacy > and security should have been rolled out all at once instead of this one > change. This change fixes one minor problem when a more broad change to add > finer-grained permissions could have been rolled out and affected third-party > developers not much more than this current one. Yes, I agree. And I think there are a lot of options for implementing this new security "feature" and even more stricter privacy or security options - but without breaking current implementations. It would be very easy to do so. That's why I am concerned about this move. Not granting DM access to xAuth apps doesn't really make sense in my opinion. > I also suspect as you hinted there may be other more selfish reasons partly > behind such changes and have written several articles about the > subject.http://bit.ly/lFZuZC Oh, didn't know about that one. No, I had something else on my mind ... I'd just like to continue working on my Twitter client and using Twitter the way I've done for the last three years or so. I think Twitter and third party devs can get along if we both want to, and I think we do :-) Again, I hope I didn't offend you with my first reply :-) Ole -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk