Re: alpha test of a new service: Tweetpass
But won't OAuth put an end to this requirement anyway? --Swap On Jan 8, 6:04 am, Brian Hendrickson br...@openmicroblogger.com wrote: On Jan 7, 1:00 pm, Chad Etzel jazzyc...@gmail.com wrote: By logging intohttp://tweetpass.com/api/doyou automatically store the password somewhere? If so, how is it stored? encrypted? Yes, each user's twitter password is encrypted and stored in the SQL database. It's not on dreamhost, though :-) the server is physically controlled, in a high-end co-location facility in Portland. When an API call comes in with a disposable password, the twitter password is fetched from the database and used to make the call to the twitter.com API Also, the first time a disposable password is used, it is labeled with the incoming hostname and will only be good for that host. API events for that password are visible in the control panel. -- Brian
Re: alpha test of a new service: Tweetpass
Ideally, yes. On Thu, Jan 8, 2009 at 04:10, Swap rh.swar...@gmail.com wrote: But won't OAuth put an end to this requirement anyway? --Swap On Jan 8, 6:04 am, Brian Hendrickson br...@openmicroblogger.com wrote: On Jan 7, 1:00 pm, Chad Etzel jazzyc...@gmail.com wrote: By logging intohttp://tweetpass.com/api/doyou automatically store the password somewhere? If so, how is it stored? encrypted? Yes, each user's twitter password is encrypted and stored in the SQL database. It's not on dreamhost, though :-) the server is physically controlled, in a high-end co-location facility in Portland. When an API call comes in with a disposable password, the twitter password is fetched from the database and used to make the call to the twitter.com API Also, the first time a disposable password is used, it is labeled with the incoming hostname and will only be good for that host. API events for that password are visible in the control panel. -- Brian -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: alpha test of a new service: Tweetpass
By logging into http://tweetpass.com/api/ do you automatically store the password somewhere? If so, how is it stored? encrypted? You should really tell the users what is happening (even tho it is in alpha stage). Also, the /api/ page does not appear to have htmlbody tags? It also doesn't appear that I am able to change anything on my homepage or save it... am I missing something? or is this still in implementation phase? Logging Out did not actually log me out as I was able to return to /api/ without needing to re-enter any user/pass info... This site sounds like a good idea (until we see what Twitter's OAuth looks like), but looks like it still needs some work before it is usable? I apologize if my tone seems critical, but this seems like one of those services you have to get right the first time or risk total user abandonment. -Chad On Wed, Jan 7, 2009 at 2:58 PM, Brian Hendrickson br...@openmicroblogger.com wrote: Hi Twitter-dev-talk, I would appreciate your feedback on a new service I've been working on, it's called Tweetpass. I was motivated to get it working after I wrote a comment about Twitter API security on Rahsheen's blog this past weekend. http://sheenonline.biz/ -- I decided that instead of complaining I should try to make a difference of some kind. Tweetpass makes fresh, disposable Twitter passwords, which can be used at (compatible) 3rd-party Twitter services. (there are none, yet) Also, it makes it simple for the end user to delete the passwords individually, and toggle the API methods individually. It works like this: Twitter microbloggers: a) submit their nicknames at http://tweetpass.com b) look in their Replies tab and click a link c) do Basic Authentication against twitter.com d) receive Tweetpass passwords to use at (compatible) 3rd-party Twitter services e) turn API methods on/off per-password f) delete passwords anytime Developers: a) change their code to (conditionally) call the tweetpass.com API (see below) b) put the Tweetpass logo on their site Twitter API methods: twitter.com/statuses/update.json twitter.com/statuses/friends_timeline.json twitter.com/statuses/user_timeline.json twitter.com/statuses/show/ID.json twitter.com/USERNAME twitter.com/USERNAME/statuses/STATUS search.twitter.com/search?q=HASHTAG Tweetpass API methods (so far): tweetpass.com/statuses/update.json tweetpass.com/statuses/friends_timeline.json tweetpass.com/statuses/user_timeline.json tweetpass.com/statuses/show/ID.json tweetpass.com/USERNAME tweetpass.com/USERNAME/statuses/STATUS search.tweetpass.com/search?q=HASHTAG How you can help: If you're a developer who happens to use only these few API methods, you can test your service against the Tweetpass API. The simplest thing to do is search and replace twitter.com/ with tweetpass.com/ in your code. Then you can proceed to http://tweetpass.com to get your disposable passwords. Thanks for your feedback and ideas about Tweetpass. -- Brian http://tweetpass.com 503.358.7501
Re: alpha test of a new service: Tweetpass
Hi Brian, Happy to provide feedback. A couple more questions inline, see [CBE] On Wed, Jan 7, 2009 at 7:37 PM, Brian Hendrickson br...@openmicroblogger.com wrote: Hi Chad, Thanks for the feedback! On Jan 7, 1:00 pm, Chad Etzel jazzyc...@gmail.com wrote: By logging intohttp://tweetpass.com/api/do you automatically store the password somewhere? If so, how is it stored? encrypted? You should really tell the users what is happening (even tho it is in alpha stage). I created this rough draft of the Tweetpass service so that developers can test the proxy API, it doesn't have much end-user-friendly documentation yet. [CBE] That may be, but I am now curious as to the fate of the twitter password I entered to your site to test it out... I am assuming it must be stored somehow to make the proxy API calls effective? So, what happens to those passwords? Also, the /api/ page does not appear to have htmlbody tags? It also doesn't appear that I am able to change anything on my homepage or save it... am I missing something? or is this still in implementation phase? That's because the first password you see is not active until you make an API call against it. The Activity box is empty, and the Host says not in use. Those will light up when you hit the API. [CBE] Ah, makes sense, tho not immediately intuitive.. I think this may be why people haven't tried out the proxy API yet, as they did not know they had to use the API first in order to make their homepage active so to speak. Is the idea, though, to limit the activity that can occur from a given host? If so, how do you limit that activity with the checkboxes? Or do they become available once you actually use that particular disposable password...? If that's the case, what's to stop the 3rd party app from abusing that password before I have a chance to go back to tweetpass and configure the usage rights? Logging Out did not actually log me out as I was able to return to /api/ without needing to re-enter any user/pass info... That appears to be affecting some browsers and not others, quitting the browser should complete the logout. Seems to be related to my latest mod_rewrite addition, fixing now... This site sounds like a good idea (until we see what Twitter's OAuth looks like), but looks like it still needs some work before it is usable? Exactly, yes. It's a rough draft to see if the idea is sound while gauging interest I apologize if my tone seems critical, but this seems like one of those services you have to get right the first time or risk total user abandonment. Totally agree with this sentiment I can see that many of you have authenticated and created disposable passwords in my database, but not many hits on the API yet. That will allow you to see the full service at work, and you could make use of that disposable password. Don't let it go to waste! :-) Thanks again Chad for sharing your ideas. [CBE] Glad to help, -Chad -- Brian -Chad On Wed, Jan 7, 2009 at 2:58 PM, Brian Hendrickson br...@openmicroblogger.com wrote: Hi Twitter-dev-talk, I would appreciate your feedback on a new service I've been working on, it's called Tweetpass. I was motivated to get it working after I wrote a comment about Twitter API security on Rahsheen's blog this past weekend.http://sheenonline.biz/-- I decided that instead of complaining I should try to make a difference of some kind. Tweetpass makes fresh, disposable Twitter passwords, which can be used at (compatible) 3rd-party Twitter services. (there are none, yet) Also, it makes it simple for the end user to delete the passwords individually, and toggle the API methods individually. It works like this: Twitter microbloggers: a) submit their nicknames athttp://tweetpass.com b) look in their Replies tab and click a link c) do Basic Authentication against twitter.com d) receive Tweetpass passwords to use at (compatible) 3rd-party Twitter services e) turn API methods on/off per-password f) delete passwords anytime Developers: a) change their code to (conditionally) call the tweetpass.com API (see below) b) put the Tweetpass logo on their site Twitter API methods: twitter.com/statuses/update.json twitter.com/statuses/friends_timeline.json twitter.com/statuses/user_timeline.json twitter.com/statuses/show/ID.json twitter.com/USERNAME twitter.com/USERNAME/statuses/STATUS search.twitter.com/search?q=HASHTAG Tweetpass API methods (so far): tweetpass.com/statuses/update.json tweetpass.com/statuses/friends_timeline.json tweetpass.com/statuses/user_timeline.json tweetpass.com/statuses/show/ID.json tweetpass.com/USERNAME tweetpass.com/USERNAME/statuses/STATUS search.tweetpass.com/search?q=HASHTAG How you can help: If you're a developer who happens to use only these few API methods, you can test your
Re: alpha test of a new service: Tweetpass
On Jan 7, 5:12 pm, Chad Etzel jazzyc...@gmail.com wrote: [CBE] That may be, but I am now curious as to the fate of the twitter password I entered to your site to test it out... mysql delete from passes where nick = 'chazzyjad'; Query OK, 1 row affected (0.00 sec) I didn't mean to not-answer your encryption question! I guess I shouldn't be surprised about suspicion of a new service (and personality), given twply's recent shenanigans. But if you look at the technical aspects, it should be clear that i'm not talking about another me-too service like Twitterrank, instead it's an actual security architectural innovation for the Twitter API ecosystem. One that will allow users to try out services much more safely, and to have total control over how services use their account. [CBE] Ah, makes sense, tho not immediately intuitive.. I think this may be why people haven't tried out the proxy API yet, as they did not know they had to use the API first in order to make their homepage active so to speak. Developers also need to figure out whether their app uses Twitter API methods beyond what i've provided so far. If it is a good fit then they can try switching their API URLs to try the service. Is the idea, though, to limit the activity that can occur from a given host? If so, how do you limit that activity with the checkboxes? Or do they become available once you actually use that particular disposable password...? If that's the case, what's to stop the 3rd party app from abusing that password before I have a chance to go back to tweetpass and configure the usage rights? Yes, that's the idea, it's granular API control per-host and per- password. Right now it allows all API features (checks all the boxes) by default, I didn't want to do the opposite because it would be a usability problem, but that would be a good firewall-like setup. Ultimately you would want to set your own defaults. Also, it's not set that way right now, but I will make it possible to set the API permissions [[before]] a 3rd party uses a given password. -- Brian
Re: alpha test of a new service: Tweetpass
On Jan 7, 1:00 pm, Chad Etzel jazzyc...@gmail.com wrote: By logging intohttp://tweetpass.com/api/do you automatically store the password somewhere? If so, how is it stored? encrypted? Yes, each user's twitter password is encrypted and stored in the SQL database. It's not on dreamhost, though :-) the server is physically controlled, in a high-end co-location facility in Portland. When an API call comes in with a disposable password, the twitter password is fetched from the database and used to make the call to the twitter.com API Also, the first time a disposable password is used, it is labeled with the incoming hostname and will only be good for that host. API events for that password are visible in the control panel. -- Brian
