No OAuth Support just made Techmeme

7 views
Skip to first unread message

Jesse Stay

unread,
Nov 13, 2008, 4:52:42 PM11/13/08
to twitter-deve...@googlegroups.com
I'm sure you're aware of this, but the lack of OAuth or secure login
support just got really public as it made Techmeme. IMO, for my App
at least, this would be first priority if I were to ask for anything.
Anyone else agree? Here's the Meme:

http://www.techmeme.com/081113/p38#a081113p38

Jesse

Ed Finkler

unread,
Nov 13, 2008, 9:30:45 PM11/13/08
to twitter-deve...@googlegroups.com
I think we know this already, and allowing a flavor of the day story
to influence things unduly would be overreaction.

I trust Alex, Matt and co. to make the proper decisions in regards to
what takes precedence.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Alex Payne

unread,
Nov 13, 2008, 9:50:37 PM11/13/08
to twitter-deve...@googlegroups.com
For what it's worth, and in the spirit of open communication, Matt
just showed me a prototype of an OAuth-enabled Twitter this afternoon.
I'd done a similar project a few months back, and found that while it
was easy to get up and running as an OAuth provider, the quality of
the libraries at the time was quite poor. It seems they've improved
in the interim, as Matt is is pretty happy with what he's got so far.

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
later.

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
improved.

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

Jesse Stay

unread,
Nov 14, 2008, 12:53:15 AM11/14/08
to twitter-deve...@googlegroups.com
Thanks for being open about it Alex - it helps us plan better, and
it's comforting to know it is a priority.

Jesse

Dossy Shiobara

unread,
Nov 14, 2008, 7:33:16 AM11/14/08
to twitter-deve...@googlegroups.com
Alex Payne wrote:
> 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
> improved.

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"
to implement.

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

Dossy Shiobara

unread,
Nov 14, 2008, 7:52:28 AM11/14/08
to twitter-deve...@googlegroups.com
Jesse Stay wrote:
>
> Thanks for being open about it Alex - it helps us plan better, and it's
> comforting to know it is a priority.

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
is forbidden".

It could be a long wait ...

Cameron Kaiser

unread,
Nov 14, 2008, 8:40:43 AM11/14/08
to twitter-deve...@googlegroups.com
> > Thanks for being open about it Alex - it helps us plan better, and it's
> > comforting to know it is a priority.
>
> 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?

1) You can't derive internal policy from a small set of relative bug
priorities.

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. ----------------------------------------------------------------

Dossy Shiobara

unread,
Nov 14, 2008, 8:50:17 AM11/14/08
to twitter-deve...@googlegroups.com
Cameron Kaiser wrote:
> 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.

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.

Stephen Carpenter

unread,
Nov 14, 2008, 9:01:27 AM11/14/08
to twitter-deve...@googlegroups.com
We are working on a members website.
Users will join create a profile and add things like youtube feeds,
images etc,

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?

Thanks


Stephen

Christopher St John

unread,
Nov 14, 2008, 10:24:52 AM11/14/08
to twitter-deve...@googlegroups.com
On Fri, Nov 14, 2008 at 6:52 AM, Dossy Shiobara <do...@panoptic.com> wrote:
>
> 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.
>

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.

-cks

--
Christopher St. John
http://artofsystems.blogspot.com

Ed Finkler

unread,
Nov 14, 2008, 10:42:55 AM11/14/08
to twitter-deve...@googlegroups.com
Why are you still watching, then?

Dossy Shiobara

unread,
Nov 14, 2008, 10:54:12 AM11/14/08
to twitter-deve...@googlegroups.com
Ed Finkler wrote:
> Why are you still watching, then?

Because it's free?

Ed Finkler

unread,
Nov 14, 2008, 11:00:30 AM11/14/08
to twitter-deve...@googlegroups.com
I love free stuff! But hard to get disappointed when it doesn't work
out the way we hope, yes?

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.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Dossy Shiobara

unread,
Nov 14, 2008, 11:20:16 AM11/14/08
to twitter-deve...@googlegroups.com
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.

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
indicate.

Oh, wait - there is no biz reason. Right.

Ed Finkler

unread,
Nov 14, 2008, 11:58:51 AM11/14/08
to twitter-deve...@googlegroups.com
On Fri, Nov 14, 2008 at 11:20 AM, Dossy Shiobara <do...@panoptic.com> 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.

Jesse Stay

unread,
Nov 14, 2008, 2:20:46 PM11/14/08
to twitter-deve...@googlegroups.com
Frankly, I'm in your boat. I've seen this over and over in the last
year or two - the bug report says it's low priority, which is a
concern for me. All it takes is for some developer (I actually saw
this the other day in a proof of concept by another developer) to
build an app that collects passwords, then all of the sudden they're
signing into Twitter as Robert Scoble, Mike Arrington, or Pete
Cashmore and Twitter has another huge PR mess on their hands, as do
each and every one of us developers who have to store usernames and
passwords plain text. This was the issue with those articles
yesterday - my site was one that was pointed out, as was Twitter
Karma, and others, and there's absolutely nothing we can do about it
because we have no option but to store passwords in plain text. All
we can do is blame Twitter about it, but we get yelled at when we
blame Twitter.

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
effort.

Jesse

Christopher St John

unread,
Nov 14, 2008, 2:56:28 PM11/14/08
to twitter-deve...@googlegroups.com
On Fri, Nov 14, 2008 at 1:20 PM, Jesse Stay <jess...@gmail.com> wrote:
> there's absolutely nothing we can do about it because we have no option
> but to store passwords in plain text.
>

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.

Alex Payne

unread,
Nov 14, 2008, 3:28:31 PM11/14/08
to twitter-deve...@googlegroups.com
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.

--

Jesse Stay

unread,
Nov 14, 2008, 5:12:34 PM11/14/08
to twitter-deve...@googlegroups.com
I'm okay with anything - OAuth or not, so long as we're not forced to
store plain-text credentials.

Jesse

Dossy Shiobara

unread,
Nov 14, 2008, 6:35:58 PM11/14/08
to twitter-deve...@googlegroups.com
Jesse Stay wrote:
>
> I'm okay with anything - OAuth or not, so long as we're not forced to
> store plain-text credentials.

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
security.

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.

TCI

unread,
Nov 15, 2008, 10:21:27 AM11/15/08
to Twitter Development Talk
Let me get this out of my head - I will never implement it and raise
my kids at the same time...
The way I would like this to work if for one to generate a key/
password for the application and specify what things it can do (can
read my followers but cannot change them, cannot read my email, etc) -
and make it revokable.
How about overlaying the API with another API? Some trustable entity
to store my Twitter password and do all this work of keys/Oauth/
whatever and provide the exact same API that Twitter does, so that
interested apps just need to switch to that API to provide the service
and no changes are needed.
Rafa

Sean Sullivan

unread,
Nov 17, 2008, 12:25:20 PM11/17/08
to Twitter Development Talk


On Nov 14, 12:28 pm, "Alex Payne" <a...@twitter.com> wrote:
>
> 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. [...]

I completely agree with Alex on the user experience issue. I've
written two
OAuth Consumer applications this year and the user workflow is
somewhat awkward.
Also, the user experience is especially poor on mobile devices.

These screenshots show what OAuth workflow looks like on an Android
phone:

http://code.google.com/p/jfireeagle/wiki/Android

http://code.google.com/p/jpoco/wiki/Android


> Another downside is that OAuth is a hassle for developers.  BasicAuth
> couldn't be simpler (heck, it's got "basic" in the name).  [...]

Agreed. OAuth has a non-trivial learning curve. Average developers
will
struggle with OAuth.

By the way, MySpace recently rolled out OAuth with it's REST API's.
Check the MySpace Developer forum and you'll see that many developers
are struggling with OAuth:

http://developer.myspace.com/Community/forums/t/5521.aspx

http://developer.myspace.com/Community/forums/t/5464.aspx

http://developer.myspace.com/Community/forums/t/5454.aspx

http://developer.myspace.com/Community/forums/t/5205.aspx

Cheers,

Sean

Michael Pelz-Sherman

unread,
Nov 17, 2008, 12:49:55 PM11/17/08
to twitter-deve...@googlegroups.com
Unless I'm mistaken, it appears some of the API methods do not, in fact, require authentication (contrary to the docs).


... dumps a list of jack's followers without any need to authenticate.

Is this a bug, or a feature? :-)

- Michael

Alex Payne

unread,
Nov 17, 2008, 12:51:31 PM11/17/08
to twitter-deve...@googlegroups.com
Feature.

--

Michael Pelz-Sherman

unread,
Nov 17, 2008, 12:57:27 PM11/17/08
to twitter-deve...@googlegroups.com
Thanks. Looks like "user_timeline" also does not require authentication when an id is provided.

That being the case, I don't understand why services like twitterank need my password.


From: Alex Payne <al...@twitter.com>
To: twitter-deve...@googlegroups.com
Sent: Monday, November 17, 2008 12:51:31 PM
Subject: Re: No OAuth Support just made Techmeme

Damon Clinkscales

unread,
Nov 17, 2008, 1:03:49 PM11/17/08
to twitter-deve...@googlegroups.com
On Mon, Nov 17, 2008 at 11:57 AM, Michael Pelz-Sherman
<mpelzs...@gmail.com> wrote:
> Thanks. Looks like "user_timeline" also does not require authentication when
> an id is provided.
> That being the case, I don't understand why services like twitterank need my
> password.

Unauthenticated requests are rate limited by IP. Used to be 100/hr,
unless that's changed.

-damon

Michael Pelz-Sherman

unread,
Nov 17, 2008, 1:07:40 PM11/17/08
to twitter-deve...@googlegroups.com
OK - but you don't have to authenticate as ME to get my friends or updates, right?

So why does twitterank (for example) need my password?


From: Damon Clinkscales <sca...@pobox.com>
To: twitter-deve...@googlegroups.com
Sent: Monday, November 17, 2008 1:03:49 PM

Subject: Re: No OAuth Support just made Techmeme

Cameron Kaiser

unread,
Nov 17, 2008, 11:33:18 PM11/17/08
to twitter-deve...@googlegroups.com
> OK - but you don't have to authenticate as ME to get my friends or updates,
> right?
> So why does twitterank (for example) need my password?

Twitterank uses your password to post porn spam links. I mean, it uses it
to look at your replies:

http://blogs.zdnet.com/collaboration/?p=164

Or rather, it used to:

http://twitterank.wordpress.com/2008/11/16/twitterank-for-the-rest-of-you/

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- I can't complain, but sometimes I still do. -- Joe Walsh -------------------

Mark Armendariz

unread,
Nov 18, 2008, 9:12:45 AM11/18/08
to Twitter Development Talk
From what I've heard, twitterank was using password to viralize their
app. When you signed up for your account (with twitter name and
password) to find out your rank it would automatically tweet something
like "my twitterrank is 7!" with a link to twitterank. I figured
these were automated as I saw the same tweet from 3 people who
wouldn't necessarily tweet something so stupid.

On Nov 17, 12:57 pm, Michael Pelz-Sherman <mpelzsher...@gmail.com>
wrote:
> Thanks. Looks like "user_timeline" also does not require authentication when an id is provided.
>
> That being the case, I don't understand why services like twitterank need my password.
>
> ________________________________
> From: Alex Payne <a...@twitter.com>
> To: twitter-deve...@googlegroups.com
> Sent: Monday, November 17, 2008 12:51:31 PM
> Subject: Re: No OAuth Support just made Techmeme
>
> Feature.
>
> On Mon, Nov 17, 2008 at 09:49, Michael Pelz-Sherman
>
> <mpelzsher...@gmail.com> wrote:
> > Unless I'm mistaken, it appears some of the API methods do not, in fact,
> > require authentication (contrary to the docs).
> > curlhttp://twitter.com/statuses/friends/jack.xml
Reply all
Reply to author
Forward
0 new messages