Re: No OAuth Support just made Techmeme
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 [EMAIL PROTECTED] wrote: 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. -- Dossy Shiobara | [EMAIL PROTECTED] |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)
Re: No OAuth Support just made Techmeme
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 | [EMAIL PROTECTED] | 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)
Re: No OAuth Support just made Techmeme
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
Re: No OAuth Support just made Techmeme
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
Re: No OAuth Support just made Techmeme
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
Re: No OAuth Support just made Techmeme
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. -- Dossy Shiobara | [EMAIL PROTECTED] | 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)
Re: No OAuth Support just made Techmeme
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 On Thu, Nov 13, 2008 at 4:52 PM, Jesse Stay [EMAIL PROTECTED] 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: http://www.techmeme.com/081113/p38#a081113p38 Jesse
