Re: a simple workaround for lack of OAuth
My desire for OAuth on Twitter is simple. As a developer of twitter-related utilities, I don't want to store my user's twitter credentials. As has been stated in this thread, even asking for those credentials is creating bad habits amongst Twitter's user base. I would never store a user's password for MY site in cleartext, yet the current API requires me to retrieve an unencrypted credential for twitter access. OAuth won't solve identity security issues. I'm not hoping to fix Twitter's security - just my own practices. The current pressure Twitter is getting is obviously from users who have unrealistic expectations about what a new credential system will mean. But, in spite of the uninformed panic, there really is an urgent need for this.
Re: a simple workaround for lack of OAuth
On Jan 2, 11:31 pm, Jesse Stay jesses...@gmail.com wrote: Well put Chris - I had forgotten about that. I just want something - I don't care what, but I need it soon, as it's starting to make it really difficult to market my App and keep users feeling secure. I *hate* knowing my users Twitter passwords (I have over 5,000 of them - it's really scary that I do). I sincerely hope this is top priority for Twitter right now - it should have been implemented last year so long as they have an API in place. On my App, it took about 2 hours max to write, test, and implement a very simple API key system like this for the API I'm providing. I don't get why it's taking Twitter so long. John Adams from Twitter's operations team replied to my post on this subject: The plan is to support Basic Auth and OAuth concurrently, for at least 6 months, if not more. We can’t completely turn off the Basic Auth API without having a large impact to many APIs and clients. http://factoryjoe.com/blog/2009/01/02/twitter-and-the-password-anti-pattern/comment-page-1/#comment-103431 So, you will be given an option (no telling when) to use OAuth instead of the plaintext username/password combo. Of course it means many folks will still use the lowest common denominator (and the most insecure method available) for some time, but at least there will be a good transitional time period where developers who want to use OAuth can do so, paving a path for those who will need to migrate later. Heck if Flickr could get its user base to move over to Yahoo accounts, I imagine Twitter will be able to get app developers and users to move over to OAuth in six months. Chris
Re: a simple workaround for lack of OAuth
We'll certainly be doing our utmost to incentivize developers to move to OAuth. The next major version of the API will be OAuth-only, for example. This is where I get antsy, and maybe Chris can point out some ways to deal with this, but from my perspective as a desktop client author OAuth is a lot of hurt without a lot of benefit to me the developer (other than it's the only way in so love it or lump it), and I think even the user's benefits are nebulous. If you don't trust an application, you shouldn't be running it. Isn't that where Trojan horses come in? But let's say that there is (a) good reason for a desktop application to use OAuth as its primary method; now I have a technical question. The way I'm reading http://oauth.net/core/1.0/ is that I go and get a request token (A.2), but I need to redirect a user to a service provider's login page (ouch) for her to authorize that token (A.3), then provide a callback URL (double ouch) (A.3). At best this is turning my application into not only a Twitter client, but also a web server (to accept the callback). At worst this isn't possible because the Service provider *can't* call me back due to network restrictions on the desktop machine. Also, since TTYtter is text based, I *really* don't want to be opening up a browser to get logins (or if I do, I want it to be Lynx, and fat chance I bet). Clearly OAuth is the way to go for standalone web sites talking to Twitter, but I get nervous about hearing OAuth will be the only method of access while trying to work through the issues unique to a desktop client. I would appreciate hearing from someone knowledgeable about the best way to overcome these issues, or if there is a special way that I missed where an application can authenticate itself by just asking the user for their OAuth credentials and proxy everything to the service provider, which would also suck, but less, from a developer standpoint. (But that would also probably defeat the purpose of OAuth.) -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Blanket statements are always wrong. ---
Re: a simple workaround for lack of OAuth
Anecdotally, you can look at most any Flickr app to see how they handle an auth system that's very similar to OAuth. It does often involve bouncing to the browser, but that's the intended workflow. That's what I mean. This would definitely be UX hurt for a standalone application, and it still doesn't solve the callback problem. Chris? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- This message will self-destruct in five seconds. Good luck, Jim. -- M:I
Re: a simple workaround for lack of OAuth
Anecdotally, you can look at most any Flickr app to see how they handle an auth system that's very similar to OAuth. It does often involve bouncing to the browser, but that's the intended workflow. That's what I mean. This would definitely be UX hurt for a standalone application, and it still doesn't solve the callback problem. Chris? And one more followup is how Google tried to deal with this, which I just found. Some of these issues would be very difficult to overcome in practice. http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- When the going gets weird, the weird turn pro. -- Hunter S. Thompson ---
Re: a simple workaround for lack of OAuth
Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. I agree completely with your post, Ed. I put forward my thoughts on OAuth and phishing in April last year: http://log.lachstock.com.au/past/2008/4/1/phishing-fools/ Basically, I think OAuth is awesome, but the idea that it's going to somehow stop phishing is extreme. Lachlan Hardy
Re: a simple workaround for lack of OAuth
On Sun, Jan 4, 2009 at 5:20 PM, Lachlan Hardy lach...@lachstock.com.auwrote: Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. I agree completely with your post, Ed. I put forward my thoughts on OAuth and phishing in April last year: http://log.lachstock.com.au/past/2008/4/1/phishing-fools/ Basically, I think OAuth is awesome, but the idea that it's going to somehow stop phishing is extreme. I don't get how it won't help fight phishing. Right now the worm is being spread via an App. (if it's not, then Twitter really needs a Captcha on the Twitter login page) At the moment all Twitter can do is chase down IPs to kill the App. With OAuth it would be as simple as killing the API key itself and the worm would be dead. Could they go in and create another one? Probably, but it makes it a whole lot harder for someone to create such a worm. This is the reason most of the Facebook worms right now are spreading through simple screen scraping and not the App platform. It's too much work to do it on the App platform there because Facebook would just shut you down each time their alarms went off. Jesse
Re: a simple workaround for lack of OAuth
On Sun, Jan 4, 2009 at 7:32 PM, Jesse Stay jesses...@gmail.com wrote: On Sun, Jan 4, 2009 at 5:20 PM, Lachlan Hardy lach...@lachstock.com.au wrote: Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. I agree completely with your post, Ed. I put forward my thoughts on OAuth and phishing in April last year: http://log.lachstock.com.au/past/2008/4/1/phishing-fools/ Basically, I think OAuth is awesome, but the idea that it's going to somehow stop phishing is extreme. I don't get how it won't help fight phishing. Right now the worm is being spread via an App. Help us out here with what worm you mean -- there are lots of them 8) (if it's not, then Twitter really needs a Captcha on the Twitter login page) At the moment all Twitter can do is chase down IPs to kill the App. Sure. With OAuth it would be as simple as killing the API key itself and the worm would be dead. If the malicious application uses OAuth via Twitter, yes. Could they go in and create another one? Probably, but it makes it a whole lot harder for someone to create such a worm. This is the reason most of the Facebook worms right now are spreading through simple screen scraping and not the App platform. It's too much work to do it on the App platform there because Facebook would just shut you down each time their alarms went off. I'd note that it used to be too much work to spam Google Groups because of CAPTCHAs too, but almost all CAPTCHAs can be defeated now programatically and via mechanical turk-style attacks. I and a few others have to review posts from all new users for this reason. Also, why do you assume that phishing attacks would have to come via Twitter messages, though? Most come via email or web content on other sites. Twitter currently uses email notifications for several events -- faking those would be quite easy to do, for example. OAuth may have mitigated (not blocked) *one* particular worm that was sending messages directing people to a phishing site. And yes, removing everyone's shoes does stop the shoe bombing attack. Whether or not this actually makes you *safer* is something we should very carefully consider. Personally, I'd say it helps, but only a little -- far less than most of our Thought Leaders claim. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: a simple workaround for lack of OAuth
On Sun, Jan 4, 2009 at 8:55 PM, Jesse Stay jesses...@gmail.com wrote: So what do *you* recommend Ed (that goes for everyone that is criticizing OAuth, including Alex)? I see a lot of criticism against OAuth, but I see no suggestions for a solution. Perhaps you're mistaking criticism with an attempt to make for realistic expectations, and temper an artificial urgency. Generally I think OAuth is a Good Idea, and I think it's probably a good step for Twitter to take. I think I can say Alex agrees, or he and the rest of the API team wouldn't be implementing it. It's not really my job to tell Twitter what to do – first off, I think they have people with very good security backgrounds in place, and secondly I'm not on their payroll. But if you actually want to hear a few things, I'll toss them out. I don't have time or motiviation atm for a lot of detail (we just lost a family friend tonight to cancer), but I'm happy to talk about them another day in detail if you want. - immediately cease the development of any web-based applications that require user credentials. I generally don't think that you're keeping your user's best interests in mind when you do this. - educate users about risk acceptance: what it means to trust a web application with your credentials (or OAuth permissions), and what the consequences could be if trust is broken. - educate users about how to identify phishing attacks - possibly implement some personal site ID techniques on the Twitter homepage, like user-chosen identifier images Even if you do a great job on all of these, though, you will always have some people who fall for it. Right now, I think it's a step in the right direction - I see a lot of theories here, but not a lot of urgency to fix the problem. As I said, I don't care what the solution is - I just need something, other than requiring my users to enter their plain text usernames and passwords. There's huge urgency here - what's the solution to the problem? There is no solution. Really. There isn't. People who work in security will tell you this. The security industry spends millions and millions of dollars on application trust issues, and there is no solution. There are things you can do, but you can't solve the problem. You can only *mitigate* risk. People clamoring for OAuth -- this is the urgency you refer to -- are participating in security theater. They want it implemented not because it will make things a little better, but because they have been whipped up into a frenzy by ye olde Thought Leaders and want *something* to be done. I was completely serious about my shoe bomb analogy, because it's a classic security theater – oh shit, you could put a bomb in your shoe! better check everyone's shoes! It's a temporary PR fix, but it doesn't solve the problem other than making people feel better -- until the next security flavor of the week comes around. If you seriously want to study this kind of thing further, I think starting off with Schneier's Beyond Fear: Thinking Sensibly About Security in an Uncertain World would be a good idea. As a developer, you should also dig into all the security info you can, and make security a first-level concern. If you're a PHP dev (I know a lot of folks here are), I'd probably start out with Chris Shiflett's Essential PHP Security. Rails devs should keep an eye on http://www.rorsecurity.info/. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: a simple workaround for lack of OAuth
2009/1/2 Dharmesh dharme...@gmail.com: Nicely done. Thanks. Quick question: How are you ensuring that you see *all* posts in the public timeline? I didn't think that was quite possible yet with the Twitter API. It's actually using the search API not the public timeline. -Stuart -- http://stut.net/
Re: a simple workaround for lack of OAuth
I think Scoble likes to hear himself talk, and loves to stir up drama. It's how he keeps people paying attention to him. I'd find more reputable sources for that argument. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Fri, Jan 2, 2009 at 12:44 AM, Richie rocketeer.so...@gmail.com wrote: I think it's getting more urgent day by day: http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/ Richie http://twitter.com/RMetzler On 8 Dez. 2008, 18:09, Alex Payne a...@twitter.com wrote: It won't be available for testing this week, but should be available before the end of the month. I'd definitely encourage you not to launch on it, though, as it will be a beta. On Mon, Dec 8, 2008 at 08:16,Richierocketeer.so...@gmail.com wrote: Hi Alex, do you have any updates on whenOAuthis available? Currently I'm doing the finishing touches on a new service and would love to let the users chooseOAuthfor authentication instead of requiere them to give me their secret pw. I'm experienced in using OAuthso I expect to get it working in a couple of hours. Do you think Twitter will enableOAuththis week or should I start my service with user/pw-authentication first? Richard On Nov 27, 12:38 am, Alex Payne a...@twitter.com wrote: As I don't know the entire schedule of our UX team, I can't. I would say less than a month and closer to a week by far, but please don't hold me to that. On Wed, Nov 26, 2008 at 15:41, Amir Michail amich...@gmail.com wrote: On Nov 24, 5:05 pm, Alex Payne a...@twitter.com wrote: We're currently waiting on our User Experience team to put the final touches on a BETA release of ourOAuthsupport. It's going to have bugs, to be sure, but we should have it out there soon. Could you give us a time estimate? In a week? A month? Amir On Mon, Nov 24, 2008 at 12:53, Stut stut...@gmail.com wrote: On 24 Nov 2008, at 15:13, fastest963 wrote: A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key? This is far less secure thanOAuthand is actually not much better than requiring a username and password. One of the core benefits ofOAuthis the ability to be very specific regarding what each authorised application is allowed to do, on a per application basis. It also allows you to selectively revoke the permissions of any specific application without needing to ask or even tell the application about it. To do this with the API key system you effectively need to re-authorise every app you use when you want to block just one of them. No real difference between this and having to change your password. I would much prefer that the guys (and gals) at Twitter concentrate on gettingOAuthproperly implemented (which is harder than it sounds) than their attention gets diverted by developers too impatient to wait for the right solution to the problem. -Stut -- http://stut.net/ -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: a simple workaround for lack of OAuth
2009/1/2 Ed Finkler funkat...@gmail.com: I think Scoble likes to hear himself talk, and loves to stir up drama. It's how he keeps people paying attention to him. I'd find more reputable sources for that argument. Whilst there's an element of truth in your statement (just about all of the prominent tech bloggers remain prominent by stirring up drama), lots of people have been saying similar things for a long time. Ad hominem attacks don't change the fact that the message is right. You could start here : http://adactio.com/journal/1357 . I think we all understand, however, that the twitter engineering team first needed to make twitter stable before they could add features like this one. Now that they've largely done that, it appears they're responding to demand for features like this one, which is great news. Mark
Re: a simple workaround for lack of OAuth
I think Scoble likes to hear himself talk, and loves to stir up drama. It's how he keeps people paying attention to him. I'd find more reputable sources for that argument. Whilst there's an element of truth in your statement (just about all of the prominent tech bloggers remain prominent by stirring up drama), lots of people have been saying similar things for a long time. Ad hominem attacks don't change the fact that the message is right. You could start here : http://adactio.com/journal/1357 . So let's say Scoble is right. How, in fact, does OAuth prevent a bad actor from using credentials to act badly? OAuth solves many problems; it doesn't solve this one. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- BOND THEME NOW PLAYING: The Man With the Golden Gun --
Re: a simple workaround for lack of OAuth
On Fri, Jan 2, 2009 at 1:36 PM, Mark Ng ng.mar...@gmail.com wrote: Whilst there's an element of truth in your statement (just about all of the prominent tech bloggers remain prominent by stirring up drama), lots of people have been saying similar things for a long time. Ad hominem attacks don't change the fact that the message is right. You could start here : http://adactio.com/journal/1357 . Agreed, and that's a much better source. I think we all understand, however, that the twitter engineering team first needed to make twitter stable before they could add features like this one. Now that they've largely done that, it appears they're responding to demand for features like this one, which is great news. Yep. So not really a lot of point in continuing the oh boy, this is a big problem! thing, I think, when they're on it and have given many updates here recently. That's not a criticism of you in particular, but of folks who apparently don't search the archives before posting something along the lines of Scoble said this is a big deal, so you'd better do it! It doesn't help in any way. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: a simple workaround for lack of OAuth
On Fri, Jan 2, 2009 at 1:41 PM, Cameron Kaiser spec...@floodgap.com wrote: So let's say Scoble is right. How, in fact, does OAuth prevent a bad actor from using credentials to act badly? OAuth solves many problems; it doesn't solve this one. And this.
Re: a simple workaround for lack of OAuth
On Thu, Jan 1, 2009 at 10:44 PM, Richie rocketeer.so...@gmail.com wrote: I think it's getting more urgent day by day: http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/ Richie http://twitter.com/RMetzler It's true, OAuth doesn't really solve this problem, but the general public thinks it does. Having some solution is better than none, and sometimes the feeling of security is better for marketing apps than no security at all. I'd say the attention it's getting, and an entire app with open-text passwords being sold to a third party (which, who knows - maybe next time it's a spammer???) for a small price makes this pretty dang urgent. Jesse
Re: a simple workaround for lack of OAuth
http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/ It's true, OAuth doesn't really solve this problem, but the general public thinks it does. Having some solution is better than none, and sometimes the feeling of security is better for marketing apps than no security at all. Maybe for apps, but not for users. A user that thinks he's secure and is not is far worse off than a user who's insecure and knows he isn't. If this makes people think about who they give credentials to -- OAuth or no -- then the experience will be a painful but useful lesson. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- BOND THEME NOW PLAYING: The World is Not Enough --
Re: a simple workaround for lack of OAuth
2009/1/2 Cameron Kaiser spec...@floodgap.com: So let's say Scoble is right. How, in fact, does OAuth prevent a bad actor from using credentials to act badly? OAuth solves many problems; it doesn't solve this one. There are several problems to be solved, though. The first is a malicious actor with access to a single system (in this case, twitter) spamming. OAuth doesn't solve the problem of someone using an account to spam using messages from that user (unless that app doesn't need to message, and twitters OAuth implementation has granular permissions). The second is a malicious actor with access to a single system gaining control of other systems that user has access to because they've used the same username and/or password. Whilst this is bad practice on the part of the user, we'd be silly to pretend that this isn't a large problem. OAuth *does* solve that problem, which is one of the problems in this scenario. The third is a malicious actor with access to a single system locking the user out of their own account (by changing their password) and claiming the account for themselves (which has been known to happen with gmail accounts, for example). Twitter, so far as I'm aware, doesn't allow changes of passwords via the API, and I would assume that an OAuth implementation would only allow access to the API, and not the web interface. Even were these things not the case, it wouldn't make sense to allow an OAuth client to change the user password. So OAuth does solve this problem, also. Mark
Re: a simple workaround for lack of OAuth
So let's say Scoble is right. How, in fact, does OAuth prevent a bad actor from using credentials to act badly? OAuth solves many problems; it doesn't solve this one. There are several problems to be solved, though. Clearly. But the point I'm making is that *this* particular situation isn't solved by OAuth. You're absolutely right about the rest of the similar issues it *does* improve -- no one is contesting OAuth's utility -- but it wouldn't help this particular hypothetical situation. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Friends don't let friends use Windows. -
Re: a simple workaround for lack of OAuth
I think it's getting more urgent day by day: http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/ Richie http://twitter.com/RMetzler On 8 Dez. 2008, 18:09, Alex Payne a...@twitter.com wrote: It won't be available for testing this week, but should be available before the end of the month. I'd definitely encourage you not to launch on it, though, as it will be a beta. On Mon, Dec 8, 2008 at 08:16,Richierocketeer.so...@gmail.com wrote: Hi Alex, do you have any updates on whenOAuthis available? Currently I'm doing the finishing touches on a new service and would love to let the users chooseOAuthfor authentication instead of requiere them to give me their secret pw. I'm experienced in using OAuthso I expect to get it working in a couple of hours. Do you think Twitter will enableOAuththis week or should I start my service with user/pw-authentication first? Richard On Nov 27, 12:38 am, Alex Payne a...@twitter.com wrote: As I don't know the entire schedule of our UX team, I can't. I would say less than a month and closer to a week by far, but please don't hold me to that. On Wed, Nov 26, 2008 at 15:41, Amir Michail amich...@gmail.com wrote: On Nov 24, 5:05 pm, Alex Payne a...@twitter.com wrote: We're currently waiting on our User Experience team to put the final touches on a BETA release of ourOAuthsupport. It's going to have bugs, to be sure, but we should have it out there soon. Could you give us a time estimate? In a week? A month? Amir On Mon, Nov 24, 2008 at 12:53, Stut stut...@gmail.com wrote: On 24 Nov 2008, at 15:13, fastest963 wrote: A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key? This is far less secure thanOAuthand is actually not much better than requiring a username and password. One of the core benefits ofOAuthis the ability to be very specific regarding what each authorised application is allowed to do, on a per application basis. It also allows you to selectively revoke the permissions of any specific application without needing to ask or even tell the application about it. To do this with the API key system you effectively need to re-authorise every app you use when you want to block just one of them. No real difference between this and having to change your password. I would much prefer that the guys (and gals) at Twitter concentrate on gettingOAuthproperly implemented (which is harder than it sounds) than their attention gets diverted by developers too impatient to wait for the right solution to the problem. -Stut -- http://stut.net/ -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: a simple workaround for lack of OAuth
I think it's getting more urgent day by day: http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/ Truly OAuth is needed, and is a priority to the Twitter team (they've said so). However, there is nothing in the link that Scoble has up saying directly that the buyer is planning to use the information Twply has harvested (namely usernames and passwords) for nefarious purposes other than to continue running the site. They certainly could, but Scoble needs to chill out a little. More to the point, there is nothing about OAuth that prevents a similar bad actor from behaving badly. This older post puts it in perspective very succinctly: http://groups.google.com/group/twitter-development-talk/msg/16bf699d39c7f804 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- 10% of computer users [use] Mac ... the top 10 percent. -- Douglas Adams ---
Re: a simple workaround for lack of OAuth
2009/1/2 Richie rocketeer.so...@gmail.com: I think it's getting more urgent day by day: http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/ I agree that OAuth can't arrive too soon, but this episode sucks mainly because there is no need for something like twply to need your password. This annoyed me so much that I spent this afternoon coding up a site to prove that point. Feedback greatly appreciated: http://replies.twitapps.com/ -Stuart -- http://stut.net/
Re: a simple workaround for lack of OAuth
I agree that OAuth can't arrive too soon, but this episode sucks mainly because there is no need for something like twply to need your password. This annoyed me so much that I spent this afternoon coding up a site to prove that point. Feedback greatly appreciated: http://replies.twitapps.com/ That's pretty clever. Nice work. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Shady business do not make for sunny life. -- Charlie Chan -
Re: a simple workaround for lack of OAuth
It won't be available for testing this week, but should be available before the end of the month. I'd definitely encourage you not to launch on it, though, as it will be a beta. On Mon, Dec 8, 2008 at 08:16, Richie [EMAIL PROTECTED] wrote: Hi Alex, do you have any updates on when OAuth is available? Currently I'm doing the finishing touches on a new service and would love to let the users choose OAuth for authentication instead of requiere them to give me their secret pw. I'm experienced in using OAuth so I expect to get it working in a couple of hours. Do you think Twitter will enable OAuth this week or should I start my service with user/pw-authentication first? Richard On Nov 27, 12:38 am, Alex Payne [EMAIL PROTECTED] wrote: As I don't know the entire schedule of our UX team, I can't. I would say less than a month and closer to a week by far, but please don't hold me to that. On Wed, Nov 26, 2008 at 15:41, Amir Michail [EMAIL PROTECTED] wrote: On Nov 24, 5:05 pm, Alex Payne [EMAIL PROTECTED] wrote: We're currently waiting on our User Experience team to put the final touches on a BETA release of ourOAuthsupport. It's going to have bugs, to be sure, but we should have it out there soon. Could you give us a time estimate? In a week? A month? Amir On Mon, Nov 24, 2008 at 12:53, Stut [EMAIL PROTECTED] wrote: On 24 Nov 2008, at 15:13, fastest963 wrote: A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key? This is far less secure thanOAuthand is actually not much better than requiring a username and password. One of the core benefits ofOAuthis the ability to be very specific regarding what each authorised application is allowed to do, on a per application basis. It also allows you to selectively revoke the permissions of any specific application without needing to ask or even tell the application about it. To do this with the API key system you effectively need to re-authorise every app you use when you want to block just one of them. No real difference between this and having to change your password. I would much prefer that the guys (and gals) at Twitter concentrate on gettingOAuthproperly implemented (which is harder than it sounds) than their attention gets diverted by developers too impatient to wait for the right solution to the problem. -Stut -- http://stut.net/ -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: a simple workaround for lack of OAuth
On Nov 24, 5:05 pm, Alex Payne [EMAIL PROTECTED] wrote: We're currently waiting on our User Experience team to put the final touches on a BETA release of ourOAuthsupport. It's going to have bugs, to be sure, but we should have it out there soon. Could you give us a time estimate? In a week? A month? Amir On Mon, Nov 24, 2008 at 12:53, Stut [EMAIL PROTECTED] wrote: On 24 Nov 2008, at 15:13, fastest963 wrote: A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key? This is far less secure thanOAuthand is actually not much better than requiring a username and password. One of the core benefits ofOAuthis the ability to be very specific regarding what each authorised application is allowed to do, on a per application basis. It also allows you to selectively revoke the permissions of any specific application without needing to ask or even tell the application about it. To do this with the API key system you effectively need to re-authorise every app you use when you want to block just one of them. No real difference between this and having to change your password. I would much prefer that the guys (and gals) at Twitter concentrate on gettingOAuthproperly implemented (which is harder than it sounds) than their attention gets diverted by developers too impatient to wait for the right solution to the problem. -Stut -- http://stut.net/ -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: a simple workaround for lack of OAuth
On Nov 24, 10:13 am, fastest963 [EMAIL PROTECTED] wrote: @Amir That is not a very relevant question. Why do you want to make multiple accounts? So users would follow an account with the same name as the service? Anyway, I found out that creating multiple accounts is fine. Amir @al3x A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key?
Re: a simple workaround for lack of OAuth
On 24 Nov 2008, at 15:13, fastest963 wrote: A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key? This is far less secure than OAuth and is actually not much better than requiring a username and password. One of the core benefits of OAuth is the ability to be very specific regarding what each authorised application is allowed to do, on a per application basis. It also allows you to selectively revoke the permissions of any specific application without needing to ask or even tell the application about it. To do this with the API key system you effectively need to re-authorise every app you use when you want to block just one of them. No real difference between this and having to change your password. I would much prefer that the guys (and gals) at Twitter concentrate on getting OAuth properly implemented (which is harder than it sounds) than their attention gets diverted by developers too impatient to wait for the right solution to the problem. -Stut -- http://stut.net/
Re: a simple workaround for lack of OAuth
We're currently waiting on our User Experience team to put the final touches on a BETA release of our OAuth support. It's going to have bugs, to be sure, but we should have it out there soon. On Mon, Nov 24, 2008 at 12:53, Stut [EMAIL PROTECTED] wrote: On 24 Nov 2008, at 15:13, fastest963 wrote: A better alternative would be to just create an API key for every user. Instead of entering username/password, they would enter their secret API key? This is far less secure than OAuth and is actually not much better than requiring a username and password. One of the core benefits of OAuth is the ability to be very specific regarding what each authorised application is allowed to do, on a per application basis. It also allows you to selectively revoke the permissions of any specific application without needing to ask or even tell the application about it. To do this with the API key system you effectively need to re-authorise every app you use when you want to block just one of them. No real difference between this and having to change your password. I would much prefer that the guys (and gals) at Twitter concentrate on getting OAuth properly implemented (which is harder than it sounds) than their attention gets diverted by developers too impatient to wait for the right solution to the problem. -Stut -- http://stut.net/ -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: a simple workaround for lack of OAuth
I find it better to get users to follow your account and then send them a DM with a URL. Builds followers and eliminates errors from user side. R On Nov 22, 11:30 am, Amir Michail [EMAIL PROTECTED] wrote: On Nov 22, 12:26 pm, Chad Etzel [EMAIL PROTECTED] wrote: This is a good method to verify (claim) an account, yes... but if you wanted them to be able to do any sort of authenticated request (like tweeting or sending a direct message), you'd still need their password. That is, unless you are asking twitter to change the way their API works. By future logins, do you mean to twitter? or to your service? -Chad It would simplify future logins to my service over even OAuth. The problem for me though is that without user-specific authentication (i.e., I use authentication under my account always), IP-based rate limiting is a severe problem making this at best a temporary solution. Amir On Sat, Nov 22, 2008 at 12:22 PM, Amir Michail [EMAIL PROTECTED] wrote: Hi, One could just have the user enter an assigned code into the bio/url or even in a post (which would also help promote your service). Doing so would allow the user to claim the twitter account and associate it with his/her account in your service. Unlike OAuth, this would even make future logins simpler. Is this a reasonable way to go? Amir
Re: a simple workaround for lack of OAuth
This is a good method to verify (claim) an account, yes... but if you wanted them to be able to do any sort of authenticated request (like tweeting or sending a direct message), you'd still need their password. That is, unless you are asking twitter to change the way their API works. By future logins, do you mean to twitter? or to your service? -Chad On Sat, Nov 22, 2008 at 12:22 PM, Amir Michail [EMAIL PROTECTED] wrote: Hi, One could just have the user enter an assigned code into the bio/url or even in a post (which would also help promote your service). Doing so would allow the user to claim the twitter account and associate it with his/her account in your service. Unlike OAuth, this would even make future logins simpler. Is this a reasonable way to go? Amir
Re: a simple workaround for lack of OAuth
On Nov 22, 12:26 pm, Chad Etzel [EMAIL PROTECTED] wrote: This is a good method to verify (claim) an account, yes... but if you wanted them to be able to do any sort of authenticated request (like tweeting or sending a direct message), you'd still need their password. That is, unless you are asking twitter to change the way their API works. By future logins, do you mean to twitter? or to your service? -Chad It would simplify future logins to my service over even OAuth. The problem for me though is that without user-specific authentication (i.e., I use authentication under my account always), IP-based rate limiting is a severe problem making this at best a temporary solution. Amir On Sat, Nov 22, 2008 at 12:22 PM, Amir Michail [EMAIL PROTECTED] wrote: Hi, One could just have the user enter an assigned code into the bio/url or even in a post (which would also help promote your service). Doing so would allow the user to claim the twitter account and associate it with his/her account in your service. Unlike OAuth, this would even make future logins simpler. Is this a reasonable way to go? Amir
