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:
On Thu, Nov 13, 2008 at 4:52 PM, Jesse Stay <jesses...@gmail.com> wrote:
> 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:
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.
> On Thu, Nov 13, 2008 at 4:52 PM, Jesse Stay <jesses...@gmail.com> wrote:
>> 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:
> 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.
> On Thu, Nov 13, 2008 at 6:30 PM, Ed Finkler <funkat...@gmail.com> > wrote:
>> 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.
>> On Thu, Nov 13, 2008 at 4:52 PM, Jesse Stay <jesses...@gmail.com> >> wrote:
>>> 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:
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)
> 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 ...
-- 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)
> > 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 * ckai...@floodgap.com -- Bowl angry. ----------------------------------------------------------------
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.
-- 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)
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?
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.
On Fri, Nov 14, 2008 at 8:50 AM, Dossy Shiobara <do...@panoptic.com> wrote:
> 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.
> -- > 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)
Ed Finkler wrote: > Why are you still watching, then?
Because it's free?
-- 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)
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.
On Fri, Nov 14, 2008 at 10:54 AM, Dossy Shiobara <do...@panoptic.com> wrote:
> Ed Finkler wrote: >> Why are you still watching, then?
> Because it's free?
> -- > 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)
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.
-- 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)
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.
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
On Nov 14, 2008, at 9:20 AM, Dossy Shiobara 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.
> 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.
> -- > 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)
On Fri, Nov 14, 2008 at 1:20 PM, Jesse Stay <jesses...@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.
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 <funkat...@gmail.com> wrote:
> 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.
> 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 <funkat...@gmail.com> > wrote:
>> 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.
> 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.
-- 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)
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
On Nov 14, 5:35 pm, Dossy Shiobara <do...@panoptic.com> 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.
> --
> 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)
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:
> 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:
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). > curl http://twitter.com/statuses/friends/jack.xml > ... dumps a list of jack's followers without any need to authenticate. > Is this a bug, or a feature? :-) > - Michael
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-development-talk@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). > curl http://twitter.com/statuses/friends/jack.xml > ... dumps a list of jack's followers without any need to authenticate. > Is this a bug, or a feature? :-) > - Michael
|
