I'm okay with anything - OAuth or not, so long as we're not forced to
store plain-text credentials.
Jesse
On Nov 14, 2008, at 1:28 PM, Alex Payne wrote:
I'd like to confirm that Cameron's interpretation of email is the
intended one. He wrote:
"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
technology.
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
authentication.
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.
On Fri, Nov 14, 2008 at 8:58 AM, Ed Finkler <[EMAIL PROTECTED]>
wrote:
On Fri, Nov 14, 2008 at 11:20 AM, Dossy Shiobara
<[EMAIL PROTECTED]> wrote:
Ed Finkler wrote:
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.
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.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x
