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.

Excerpts from Cameron Kaiser's message of Fri Jul 16 01:00:55 -0400 2010:

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.
dec...@red-bean.com

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.

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. 

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 <taylorsinglet...@twitter.com>
wrote:
> >> deck...@red-bean.com

Hi Everyone,

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 <taylorsinglet...@twitter.com>
wrote:
> open source developers & consumers *need* it to be, and the push for a more
> Taylor Singletaryhttp://twitter.com/episod
> <briandunning...@gmail.com>wrote:

What's the approved open source solution to this problem?
--
-ed costello

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

Can't you open source everything *except* a module that deals with
oAuth? Like a proprietary codec or proprietary wireless driver?

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);"
> depressing part of this situation is that iamno going to be loosing
> app can no longer access twitter.  hopefully hopemayprove to be

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

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.

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

Yes, anyone who uses your application gets identified as using your
application. This is not a problem.

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

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.

Quoting Jef Poskanzer <jef.po...@gmail.com>:

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? ;-)