Re: [twitter-dev] Re: How is this a solution?
On Mon, Aug 9, 2010 at 10:46 PM, M. Edward (Ed) Borasky wrote: > why not simply build as much of the functionality into > the server as possible and make a browser-based app right from the start? 'Cause that's not what I want. If I wanted a browser based app, I'd write on from start and not start it as a desktop app that can run on 4 different operating systems including one mobile[1]. If I wanted a web app, I'd have to chose a hosting/provider to hold all users accounts deal with all the logistics of giving users all the data they want. Instead, I decided to write a desktop app, where the users have their data whenever they want. But you guys are taking this out of context: OSS apps _need_ a way to expose their keys (as they are part of the application itself) without having to worry about someone getting those keys and ruining the app image by posting trash or using those same keys to get the same rights a user gave to the app. [1] And no, I didn't had to add any hacks or a stupid sequence of #defines. I get all that for free. -- Julio Biason Twitter: http://twitter.com/juliobiason
Re: [twitter-dev] Re: How is this a solution?
Quoting Jef Poskanzer : On Aug 9, 10:48 am, Tom wrote: exactly the same issue as the one which Twitter currently has No. A malfeasor who gets your app key can make any API call pretending to be you, from any IP address, logged in as any user. A malfeasor who goes through your app's signing proxy can only do the calls that your app is willing to sign, which you can restrict by IP address, userid, calls/second throttle, or any way you like. Yep - sooner or later you have to build *some* kind of server to protect your business, even if the majority of your functionality is mobile or desktop. Given that, why not simply build as much of the functionality into the server as possible and make a browser-based app right from the start? ;-) This is that "cloud computing stuff" that they talk about in those expensive trade shows, right? ;-) -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb "A mathematician is a device for turning coffee into theorems." - Paul Erdos
[twitter-dev] Re: How is this a solution?
On Aug 9, 10:48 am, Tom wrote: > exactly the same issue as the one which Twitter currently has No. A malfeasor who gets your app key can make any API call pretending to be you, from any IP address, logged in as any user. A malfeasor who goes through your app's signing proxy can only do the calls that your app is willing to sign, which you can restrict by IP address, userid, calls/second throttle, or any way you like.
[twitter-dev] Re: How is this a solution?
And anyone who manages to find out how your client-server connection works, can act as if they are using your application - exactly the same issue as the one which Twitter currently has, except that it may be a bit easier or harder, depending on the used protocol. Tom On Aug 9, 6:50 pm, Jef Poskanzer wrote: > On Aug 9, 7:44 am, Tom wrote: > > > If you use some kind of server-side proxy, you still have the same > > issue, because you also have to identify your application to your own > > server - which anyone can do, no matter how good the encryption is. > > Yes, anyone who uses your application gets identified as using your > application. This is not a problem.
[twitter-dev] Re: How is this a solution?
On Aug 9, 7:44 am, Tom wrote: > If you use some kind of server-side proxy, you still have the same > issue, because you also have to identify your application to your own > server - which anyone can do, no matter how good the encryption is. Yes, anyone who uses your application gets identified as using your application. This is not a problem.
[twitter-dev] Re: How is this a solution?
> OAuth is a web authentication protocol. It was not designed to > authenticate desktop and mobile apps, and should not be used for that. I have to disagree. I can't think of a single protocol that allows the identification of applications without the possibility of leaking keys - if you have to use a key, it can be stolen, and if you don't have to use a key, you can't identify (or anyone can). If you use some kind of server-side proxy, you still have the same issue, because you also have to identify your application to your own server - which anyone can do, no matter how good the encryption is. Tom On Aug 9, 4:50 am, Jef Poskanzer wrote: > On Aug 7, 10:52 am, "@epc" wrote: > > > What's the approved open source solution to this problem? > > You don't have to make it a full-fledged web app as Ed Borasky says. > You can also use a server-side proxy that holds your API key&secret > and signs API calls. Of course this means all of your application's > traffic will funnel through your server instead of going direct to > twitter, which is obviously not good. > > And I'll also repeat what Julio Biason said, that this is not actually > an open source vs. closed source issue. Closed source desktop & > mobile applications also have their app key&secret built into the > app. Anyone with a debugger can extract them. > > OAuth is a web authentication protocol. It was not designed to > authenticate desktop and mobile apps, and should not be used for that.
[twitter-dev] Re: How is this a solution?
On Aug 7, 10:52 am, "@epc" wrote: > What's the approved open source solution to this problem? You don't have to make it a full-fledged web app as Ed Borasky says. You can also use a server-side proxy that holds your API key&secret and signs API calls. Of course this means all of your application's traffic will funnel through your server instead of going direct to twitter, which is obviously not good. And I'll also repeat what Julio Biason said, that this is not actually an open source vs. closed source issue. Closed source desktop & mobile applications also have their app key&secret built into the app. Anyone with a debugger can extract them. OAuth is a web authentication protocol. It was not designed to authenticate desktop and mobile apps, and should not be used for that.
[twitter-dev] Re: How is this a solution?
I have to admit that you've got a very good point there. However, don't forget that any twitter account can create new API keys, without any kind of review process ;-) The problem is very simple: Twitter needs something to identify the application, and this identification must be sent by the application itself. However, if the application can send it, then so can a person who manages to obtain the keys. And don't forget: no encryption is unbreakable. If you wanted the keys for an application, you could simply write a wrapper for libcrypto and fetch the keys for the application (assuming that it uses libcrypto for the SHA1-HMAC part). Bottom line: there's not really a solution to this issue, and you can't blame Twitter for that. Tom On Aug 8, 2:24 am, marketingmaniac wrote: > twitter did this for 1 reason and only 1 reason,, sucks i know but > they did this because of all the desktop and net applications > that are mass sending messages,, parsing, you name it,, now they have > controll to kill the key,, > > i think its a horrable solution because now all the developers will do > is steal our keys and impliment it in their solution until > the key gets cut off, then they will just move on to the next key they > took. > > hmm,, twitter just doesnt have the staff that knows how these > developers think. > > Mike > > On Jul 15, 9:22 pm, "uberChicGeekChick(*KaityGB);" > > > > > > > > wrote: > > 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 iamno 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 beauti
[twitter-dev] Re: How is this a solution?
twitter did this for 1 reason and only 1 reason,, sucks i know but they did this because of all the desktop and net applications that are mass sending messages,, parsing, you name it,, now they have controll to kill the key,, i think its a horrable solution because now all the developers will do is steal our keys and impliment it in their solution until the key gets cut off, then they will just move on to the next key they took. hmm,, twitter just doesnt have the staff that knows how these developers think. Mike On Jul 15, 9:22 pm, "uberChicGeekChick(*KaityGB);" wrote: > 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 iamno 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 hopemayprove to be > powerful enough. > > sincerely & hopefully, > kaity g.b. - get2gnow's artist, author, code, & creator. > http://uberChicGeekChick.com/?projects=get2gnow.
Re: [twitter-dev] Re: How is this a solution?
Can't you open source everything *except* a module that deals with oAuth? Like a proprietary codec or proprietary wireless driver? -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb "A mathematician is a device for turning coffee into theorems." - Paul Erdos Quoting Julio Biason : On Sat, Aug 7, 2010 at 3:17 PM, M. Edward (Ed) Borasky wrote: Deploy your application as a server-based web application. It's not like that's difficult with frameworks like Rails, Django, CodeIgniter, ... And what if I have a desktop application? Should I just screw my users by either providing a very stupid user experience (making them register a desktop application) or giving the key to their data with my app? How is that a solution? -- Julio Biason Twitter: http://twitter.com/juliobiason
Re: [twitter-dev] Re: How is this a solution?
On Sat, Aug 7, 2010 at 3:17 PM, M. Edward (Ed) Borasky wrote: > Deploy your application as a server-based web application. It's not like > that's difficult with frameworks like Rails, Django, CodeIgniter, ... And what if I have a desktop application? Should I just screw my users by either providing a very stupid user experience (making them register a desktop application) or giving the key to their data with my app? How is that a solution? -- Julio Biason Twitter: http://twitter.com/juliobiason
Re: [twitter-dev] Re: How is this a solution?
Deploy your application as a server-based web application. It's not like that's difficult with frameworks like Rails, Django, CodeIgniter, ... -- M. Edward (Ed) Borasky http://borasky-research.net http://twitter.com/znmeb "A mathematician is a device for turning coffee into theorems." - Paul Erdos Quoting "@epc" : On Aug 6, 2:45 pm, Julio Biason wrote: I may sound pissed and I am: Twitter was build on top of open source apps (like Rails and now Cassandra) and basically you guys are slapping every other open source application that use your APIs in the face. What's the approved open source solution to this problem? -- -ed costello
[twitter-dev] Re: How is this a solution?
On Aug 6, 2:45 pm, Julio Biason wrote: > I may sound pissed and I am: Twitter was build on top of open source > apps (like Rails and now Cassandra) and basically you guys are > slapping every other open source application that use your APIs in the > face. What's the approved open source solution to this problem? -- -ed costello
Re: [twitter-dev] Re: How is this a solution?
On Thu, Aug 5, 2010 at 8:41 PM, Taylor Singletary
wrote:
> We know this isn't ideal.
No, it's not ideal: It's far far FAR from it.
> But we're supporting OAuth 1.0a right now, and for the safety of our users,
> for the ecosystem, and for you: please don't distribute API tokens and
> secrets in your open source projects.
Two wrongs here: First of all, you're saying that closed source apps
are safer for your users ('cause, in theory, the keys are harder to
get). That's false 'cause you can't assure, nor your users and neither
the ecosystem that a certain application will "call home" and send
information it shouldn't. Even worse for the "ecosystem" is that you
guys are forcing applications to be removed from it.
The second wrong is that you're, basically, telling us that we should
punish our users with a more complicated UX because we decided to
provide them with more freedom.
I may sound pissed and I am: Twitter was build on top of open source
apps (like Rails and now Cassandra) and basically you guys are
slapping every other open source application that use your APIs in the
face.
--
Julio Biason
Twitter: http://twitter.com/juliobiason
[twitter-dev] Re: How is this a solution?
Taylor - thanks for the response. it is good to hear it from the horse's mouth. unfortunately, distributing the app without keys/secrets and asking each user to register their own set of keys is not feasible for my app. in lieu of a better solution, i will have to remove Twitter integration for the time being. i look forward to the day when a better solution is in place and i can re-enable the functionality. ps: out of curiosity, how are apps like Spaz planning on handling this situation? i would love to hear any creative ideas. On Aug 5, 4:41 pm, Taylor Singletary wrote: > Hi Everyone, > > The key exchange "solution" will not be ready for the cut > off, unfortunately. > > If you want to distribute an open source application or library, it should > either: > - consume only public resources not requiring authentication > - be distributed without consumer keys and secrets. > > If your API key has been afforded any kind of privileges, such as xAuth, we > ask that you be especially vigilant in not exposing your application secrets > in easily accesible ways. I hope the logic in that is self-evident. > > We know this isn't ideal. This will be easier some day -- we want it to be, > open source developers & consumers *need* it to be, and the push for a more > "frictionless" user experience across platform products demand it to be so. > > But we're supporting OAuth 1.0a right now, and for the safety of our users, > for the ecosystem, and for you: please don't distribute API tokens and > secrets in your open source projects. > > Taylor Singletaryhttp://twitter.com/episod > > On Thu, Aug 5, 2010 at 1:34 PM, briandunnington > wrote: > > > i have seen it stated a few times that this solution is still being > > evaluated and it sounds like it might not see the light of day (which > > is fine by me - it seemed kind of convoluted to begin with). > > > however, the oAuth deadline is fast approaching - what options do open > > source apps have in order to make the switch in time? requests to > > @twitterapi have gone unanswered and there have been no further > > updates as to how to proceed. i will implement whatever alternative > > is offered, but since the key exchange is not publicly available and > > may never be, what is the recommended approach for keeping the > > consumer secret a secret? > > > On Jul 19, 7:21 am, Taylor Singletary > > wrote: > > > 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.com > > >wrote: > > > > > 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 > >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] Re: How is this a solution?
Hi Everyone, The key exchange "solution" will not be ready for the cut off, unfortunately. If you want to distribute an open source application or library, it should either: - consume only public resources not requiring authentication - be distributed without consumer keys and secrets. If your API key has been afforded any kind of privileges, such as xAuth, we ask that you be especially vigilant in not exposing your application secrets in easily accesible ways. I hope the logic in that is self-evident. We know this isn't ideal. This will be easier some day -- we want it to be, open source developers & consumers *need* it to be, and the push for a more "frictionless" user experience across platform products demand it to be so. But we're supporting OAuth 1.0a right now, and for the safety of our users, for the ecosystem, and for you: please don't distribute API tokens and secrets in your open source projects. Taylor Singletary http://twitter.com/episod On Thu, Aug 5, 2010 at 1:34 PM, briandunnington wrote: > i have seen it stated a few times that this solution is still being > evaluated and it sounds like it might not see the light of day (which > is fine by me - it seemed kind of convoluted to begin with). > > however, the oAuth deadline is fast approaching - what options do open > source apps have in order to make the switch in time? requests to > @twitterapi have gone unanswered and there have been no further > updates as to how to proceed. i will implement whatever alternative > is offered, but since the key exchange is not publicly available and > may never be, what is the recommended approach for keeping the > consumer secret a secret? > > > > On Jul 19, 7:21 am, Taylor Singletary > wrote: > > 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.com > >wrote: > > > > > > > > > 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 >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 >
[twitter-dev] Re: How is this a solution?
i have seen it stated a few times that this solution is still being evaluated and it sounds like it might not see the light of day (which is fine by me - it seemed kind of convoluted to begin with). however, the oAuth deadline is fast approaching - what options do open source apps have in order to make the switch in time? requests to @twitterapi have gone unanswered and there have been no further updates as to how to proceed. i will implement whatever alternative is offered, but since the key exchange is not publicly available and may never be, what is the recommended approach for keeping the consumer secret a secret? On Jul 19, 7:21 am, Taylor Singletary wrote: > 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.com>wrote: > > > > > 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 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
