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

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 :-)

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: 

Reply via email to