I trust Alex, Matt and co. to make the proper decisions in regards to
what takes precedence.
It's been my intention to lump OAuth in with the next major release of
the API. Because we're changing stacks, I didn't want to duplicate
the work of adding OAuth in our current stack only to have to redo it
mere weeks later in our new stack.
If we can deliver it sooner with minimal effort, though, we will.
Doing so requires resources beyond the API team here at Twitter,
though, as there's a strong User Experience component to any OAuth
implementation. We'll be talking with our UX team about prioritizing
some of their time to get beta OAuth support out the door sooner than
Hope that helps. Long story short, we've been punting on OAuth to try
to minimize duplication of labor as we transition to some new
technologies, but we're willing to be pragmatic if the libraries have
Alex Payne - API Lead, Twitter, Inc.
Ugh. If the available OAuth implementations (libraries) suck, and
you're not interested in writing your own implementation from scratch,
then don't do OAuth - just generate a "Twitter API key" (think: random
128-bit string) and store it. Let folks authenticate to the API with
either their password OR their Twitter API key. Provide a small area in
the Settings pages to view/generate a new API key.
This at least gets us away from users handing out their login
credentials which is 90% of the issue and shouldn't require "a library"
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
Dude, the only priority it has is LOW. Did you an I read different
emails? Alex wrote:
"If we can deliver it sooner with minimal effort, though, we will."
Basically, this is a "ain't gonna happen" response - because it seems
nothing at Twitter which ought to be simple or minimal in effort seems
to work right the first time. Or the second time. Or how many times
have they "switched their stack" so far?
I really appreciate Alex's efforts here, but lets call a spade a spade:
OAuth won't happen until Twitter has to shut down the service when
someone steals 50% of the user's passwords through some poorly written
API-using app that gets pwnt.
Then, Twitter will simply shut off the API. And won't turn it back on
until they have some kind of API key implementation in place. Then,
they'll quietly change their ToS to say "sharing your auth credentials
It could be a long wait ...
1) You can't derive internal policy from a small set of relative bug
2) I read Alex's E-mail to say, '*sooner* with minimal effort' [but will
occur regardless of the effort required], emphasis mine. So far I haven't
seen anything to dispute that interpretation.
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Bowl angry. ----------------------------------------------------------------
Right. Just like "IM to Twitter will eventually come back" became
"sorry, we suck, and gave up on getting IM to Twitter working."
I've seen this movie before. I know how it ends.
We would like users to be able to add there twitter account details
and feed all their tweets into their profile and randomly pull out
tweets from different members onto the homepage.
Can anyone point out how to do this or where to go to find out how to?
And... people have to change their password. Which really isn't too
different from the OAuth scenario, where people give their permission
to an evil app and then have to go revoke it (in both cases after the
harm is done)
I love OAuth as a developer because it lets me use a generic
mechanism and opens up some new kinds of interactions, but it
isn't a security silver bullet, and there's a popular conception that
it protects users in a way it really doesn't.
Christopher St. John
Because it's free?
I do understand the frustration, really. But I think I can safely say
that the dudes who post here from Twitter bust their ass for you and
me, and this kind of thing really doesn't help.
So, what would help? Sycophantic cheerleading? I don't think so.
Lets talk about real reasons why it's important for Twitter biz people
to up the priority on some kind of reasonable API auth scheme. If we
can't come up with a compelling business reason to make it priority #1,
well, then perhaps it really shouldn't bother getting worked on unless
it was a near-zero effort, as I interpreted Alex's original message to
Oh, wait - there is no biz reason. Right.
Of course not. Suggesting one extreme is not a good idea doesn't imply
an opposite extreme is a good idea either.
> Lets talk about real reasons why it's important for Twitter biz people
> to up the priority on some kind of reasonable API auth scheme.
I think it's Twitter's job to do that. But go for it if you're
interested in the exercise.
Mainly, I just think there's a difference between saying "I really
want to see feature A" and "feature A would be awesome, but I know you
guys won't do it." The second one, for me, fails the "would I say that
to his face?" check, so I wouldn't say it in email either. But that's
me; you may feel or do differently.
Many people on Twitter store their bank passwords as their Twitter
passwords. I'm not arguing that's a good idea, but how long before we
have an elaborate phishing scheme on our hands? I suggest days, not
months, so unless Twitter has plans to release in days, I say this
needs to take priority over the new API, even if it means duplicated
Store the passwords encrypted then decrypt them when you need to
use them. There's a chicken-and-egg problem with where you keep
the master key, but if you're clever you can substantially reduce the
risk of a breakin exposing passwords.
The thing is, OAuth doesn't solve this for you because for any app
that would require storing passwords you'll have to persistently
store (and protect) various OAuth secrets just the same way you'd
need to protect passwords and your master key.
As far as using the same password for twitter and your bank account,
well, (a) it's a dumb thing to do, and technology cannot protect users
from dumbness, and (b) while it helps _you_ the app author avoid risk,
OAuth makes users substantially more vulnerable to phishing, so it's
kind of a wash in protecting careless users from themselves.
"I read Alex's E-mail to say, '*sooner* with minimal effort' [but
will occur regardless of the effort required], emphasis mine. So far I
haven't seen anything to dispute that interpretation."
Indeed, where my thinking is at is that we'll do the work necessary to
get beta OAuth support out there in our current stack, even if it does
mean some duplication of effort as we go forward. As I said, Matt's
opinion was that the Rails OAuth plugin/library had improved to the
point where we wouldn't have to rework it.
If you have questions about our schedule and priorities, just ask.
There's no need to speculate. I'm happy to be as open with you all as
I can possibly be about why and how we schedule our work, and what our
concerns and limitations are when implementing support for a new
I would strongly encourage a re-read of Christopher St John's posts is
this thread. OAuth is simply a standardization of the token
authentication systems that several large companies were making use
of. It's not a security silver bullet; token auth has a different
threat profile from BasicAuth, but not a non-existent threat profile.
At the end of the day, you can hand out your password or hand out a
token and you're still giving a potentially malicious application
rights to access your data.
OAuth's main benefit is that it decouples rights to API access from
general access to one's Twitter account. It should also allow users
more granular control over which applications have what sort of rights
on their behalf. That's good, and something our API and other APIs
that make use of BasicAuth sorely lack.
The downside is that OAuth suffers from many of the frustrating user
experience issues and phishing scenarios that OpenID does. The
workflow of opening an application, being bounced to your browser,
having to login to twitter.com, approving the application, and then
bouncing back is going to be lost on many novice users, or used as a
means to phish them. Hopefully in time users will be educated,
particularly as OAuth becomes the standard way to do API
Another downside is that OAuth is a hassle for developers. BasicAuth
couldn't be simpler (heck, it's got "basic" in the name). OAuth
requires a new set of tools. Those tools are currently semi-mature,
but again, with time I'm confident they'll improve. In the meantime,
OAuth will greatly increase the barrier to entry for the Twitter API,
something I'm not thrilled about.
Despite these downsides, we're pushing forward with OAuth, and we'll
keep you updated as to our progress.
I just don't want a user's password. A proxy (API key token, OAuth
secret, whatever) is better, even if it doesn't afford any extra actual
Users are educated over and over not to give up their password except to
the site that it belongs to. Undoing that by encouraging people to give
up their Twitter password is just so frustrating.
Unauthenticated requests are rate limited by IP. Used to be 100/hr,
unless that's changed.
Twitterank uses your password to post porn spam links. I mean, it uses it
to look at your replies:
Or rather, it used to:
-- I can't complain, but sometimes I still do. -- Joe Walsh -------------------