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.
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?
On Sat, Nov 22, 2008 at 12:22 PM, Amir Michail <amich...@gmail.com> 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.
On Nov 22, 12:26 pm, "Chad Etzel" <jazzyc...@gmail.com> 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.
> On Sat, Nov 22, 2008 at 12:22 PM, Amir Michail <amich...@gmail.com> 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.
> On Nov 22, 12:26 pm, "Chad Etzel" <jazzyc...@gmail.com> 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 <amich...@gmail.com> 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.
On Nov 23, 2:33 pm, TCI <ticoconid...@gmail.com> wrote:
> 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
Are we allowed to have multiple accounts on twitter? If so, how many?
> On Nov 22, 11:30 am, Amir Michail <amich...@gmail.com> wrote:
> > On Nov 22, 12:26 pm, "Chad Etzel" <jazzyc...@gmail.com> 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 <amich...@gmail.com> 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.
@Amir That is not a very relevant question. Why do you want to make
multiple accounts?
@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?
> @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?
> 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.
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 <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 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.
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?
> 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.
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.
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" <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.
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 <rocketeer.so...@gmail.com> 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" <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.
> 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<rocketeer.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.
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:
-- ------------------------------------ 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 ---
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.
> 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.
-- ------------------------------------ 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 -----------------
> > 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.
> --
> ------------------------------------ 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 -----------------
> 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.
> 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,Richie<rocketeer.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.
> 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.
> > 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" ----------------------
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.
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.
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.
