Re: [twitter-dev] How is this a solution?
We're continuing to experiment with the feasibility of this feature, and SSL support is one gating factor among a few others. There are future solutions that we can envision that would obviate the need for this less-than-friendly model. Taylor On Sat, Jul 17, 2010 at 12:35 PM, Abraham Williams 4bra...@gmail.comwrote: There is an open issue for SSL support on dev.twitter.com - http://code.google.com/p/twitter-api/issues/detail?id=1665 Abraham - Abraham Williams | Hacker Advocate | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Fri, Jul 16, 2010 at 06:41, Decklin Foster deck...@red-bean.comwrote: Excerpts from Cameron Kaiser's message of Fri Jul 16 01:00:55 -0400 2010: Actually, no. The process creates a completely new app key and secret cloned from the original one. They do not have anything in common with each other apart from the name and branding (and the user can change it later; it's just a regular old app key). You can see this in action by looking at TTYtter, which uses the process. They are not the same key and secret at all. When was this process turned on? (I just checked out TTYtter and indeed, it works.) I asked for an update a couple weeks ago but I hadn't seen anything here or on the announce list, so I assumed other things had taken priority. -- things change. deck...@red-bean.com
Re: [twitter-dev] How is this a solution?
There is an open issue for SSL support on dev.twitter.com - http://code.google.com/p/twitter-api/issues/detail?id=1665 Abraham - Abraham Williams | Hacker Advocate | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Fri, Jul 16, 2010 at 06:41, Decklin Foster deck...@red-bean.com wrote: Excerpts from Cameron Kaiser's message of Fri Jul 16 01:00:55 -0400 2010: Actually, no. The process creates a completely new app key and secret cloned from the original one. They do not have anything in common with each other apart from the name and branding (and the user can change it later; it's just a regular old app key). You can see this in action by looking at TTYtter, which uses the process. They are not the same key and secret at all. When was this process turned on? (I just checked out TTYtter and indeed, it works.) I asked for an update a couple weeks ago but I hadn't seen anything here or on the announce list, so I assumed other things had taken priority. -- things change. deck...@red-bean.com
Re: [twitter-dev] How is this a solution?
Excerpts from Cameron Kaiser's message of Fri Jul 16 01:00:55 -0400 2010: Actually, no. The process creates a completely new app key and secret cloned from the original one. They do not have anything in common with each other apart from the name and branding (and the user can change it later; it's just a regular old app key). You can see this in action by looking at TTYtter, which uses the process. They are not the same key and secret at all. When was this process turned on? (I just checked out TTYtter and indeed, it works.) I asked for an update a couple weeks ago but I hadn't seen anything here or on the announce list, so I assumed other things had taken priority. -- things change. deck...@red-bean.com
[twitter-dev] How is this a solution?
So basically Twitter's solution to keep consumer keys out of oss apps code base is: - to require a hard coded url, which will be easily found in any apps source( or by simply scanning one's network traffic ). - this uri than responds by displaying the consumer key, consumer secret, and even more information in plan text(which can also be easily sniffed from network traffic). - than these credentials are displayed in plain text which the user has to copy paste back into my app i have further issues but i'll start here. with the apps oauth credentials all being displayed in plain text after a user grants an oss application access to their account. so how does this remotely rationally solve anything? so now instead of a cracker needing to dig through my code to find my consumer secret they can simply run my, or any open source app, and grant this app access to my, i.e. the cracker's account, and now the cracker has my app's consumer key, consumer secret, even more. and once they have this they need not even paste it into my app, or have looked through, even one line, of my open source code. so how does this do anything but make my apps oauth credentials even easier for a cracker to get a hold of? now they can grep/search my code base for the uri and use a simple curl/wget script to get my apps key secret. What's being solved here? an oauth access problem, twitter's lack of awareness, or complete disregard for open source apps using your service? And now even supposing that my app gets this uri pasted back into it: my apps going to have to store these credentials. Now what? Whether i store this information in GConf, a ini/conf file, or even an encrypted storage system, e.g.: gnome-keyring/a ggp locked data file. no matter what i do there are three glaring wholes in the solution, 1st) even at this point, my process of storing retrieving twitter's precious oauth credentials *has* to be viewable in my source code, 2nd) once my app is running sending request to form twitter these credentials are now sitting in ram again easily accessible to any cracker who'll spend 5minutes looking for it(any decent debugger, or countless other methods, will grant them access to this information). 3rd) its all still easily accessible by sniffing network traffic. now if an ssl connection where to be *required* this would solve the networking sniffing issue - but none of the others. There are other issues which are more fundamental short comings in oauth itself, which i've already mentioned in my original xauth request support ticket else where online. by any logical evaluation: implement require oauth is a mistake. if only Twitter could stand up and be technically competent enough to just admit it. thankfully statusnet/identica other open source micro-blogging platforms will learn from twitter's mistake. the only truly depressing part of this situation is that i am no going to be loosing my primary social connection. especially as a disabled open source artist: this is incredibly sad i can honest say that i will miss more of my twitter friends than i can even count... all because i create use open source applications. i wish i weren't being force to say good bye to so many beautiful friends who've become corner-stones of my personal support network But that's what i get for having made so many friends who rely on a closed sourced 3rd party. At least i can say that, for a time, twitter truly did improve my quality of life. ~alas~ now my only choice left is to say goodbye. thankfully many of my friends have joined statusnet. and of course i can always keep holding out hope that twitter will reverse this mistake. a hope i'll hold on to until the day when my own open source app can no longer access twitter. hopefully hope may prove to be powerful enough. sincerely hopefully, kaity g.b. - get2gnow's artist, author, code, creator. http://uberChicGeekChick.com/?projects=get2gnow.
Re: [twitter-dev] How is this a solution?
So basically Twitter's solution to keep consumer keys out of oss apps code base is: - to require a hard coded url, which will be easily found in any apps source( or by simply scanning one's network traffic ). - this uri than responds by displaying the consumer key, consumer secret, and even more information in plan text(which can also be easily sniffed from network traffic). - than these credentials are displayed in plain text which the user has to copy paste back into my app i have further issues but i'll start here. with the apps oauth credentials all being displayed in plain text after a user grants an oss application access to their account. so how does this remotely rationally solve anything? so now instead of a cracker needing to dig through my code to find my consumer secret they can simply run my, or any open source app, and grant this app access to my, i.e. the cracker's account, and now the cracker has my app's consumer key, consumer secret, even more. and once they have this they need not even paste it into my app, or have looked through, even one line, of my open source code. Actually, no. The process creates a completely new app key and secret cloned from the original one. They do not have anything in common with each other apart from the name and branding (and the user can change it later; it's just a regular old app key). You can see this in action by looking at TTYtter, which uses the process. They are not the same key and secret at all. I do agree that it should be passed over SSL rather than in the clear, and Taylor was looking into this, last I spoke with him about it. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- What you don't know won't help you much either. -- D. Bennett --
