TwitFactory, Twitter, OAuth and FOSS

TwitFactory, my twitter client based on xulrunner, is not far from the attic. Given the recent authentication change in Twitter and the obligation to use now OAuth, I don't see how I could keep the application based on easily readable JavaScript AND preserve the security of an associated OAuth key. Even if TwitFactory is not Open Source, all Open Source applications share the same concern. How can we write Open Source software if a key inside the code is readable, copyable, abusable?

Even if TwitFactory could use a binary component containing an encrypted key, fully free or open source software cannot do that.

On the same topic, I do recommend reading a 3-pages excellent article by Ryan Paul on Ars Technica.


1. On Monday 6 September 2010, 11:41 by michel v

Twitter warned about discontinuating basic auth service MONTHS ago.

Why hasn't this time been used for discussions on how to properly handle this change, between Twitter and the Open Source community?

An example of lack of communication: Canonical managed to get basic auth preserved for Gwibber, but the very announcement that basic auth was going away dates back to before Ubuntu 10.04; Gwibber could have had OAuth support, but its developers choose not to bother. They prefered to have Shuttleworth make a deal that's app-specific and doesn't benefit anyone else.
This is not a victory for OSS.

2. On Monday 6 September 2010, 12:23 by Danny Moules (Rushyo)

As the arstechnica reporter notes, he's been trying to handle this for a while and has been stalled and ignored by Twitter at every turn. His attempts at responsible disclosure tell on deaf ears. That's Twitter's issue.

"but [Twitter] believes that such attacks will largely be deterred if developers take basic steps to obscure and obfuscate their keys in their source code."

Security by obscurity is worthless. Ripping Twitter OAuth keys is going to become a sport until the press pick up on it enough that Twitter feel the need to backtrack.

3. On Monday 6 September 2010, 14:01 by Blair McBride

Its not just Twitter - its OAuth in general. I've come up against the same thing a couple of times now, and came to the same conclusions: There's no decent way to protect your secret key in an open source application. Which, sadly, means that if you want to use OAuth effectively, you need to disallow open source applications.

4. On Monday 6 September 2010, 14:38 by Benoit

Maybe the solution is to make the application key a configurable setting in your software, and ask the user to register his own instance at Twitter on first use.

That's what I had to do to set up a web-based client (dabr) on my personal server.

5. On Monday 6 September 2010, 16:28 by karl

There is a thread about it on twitter-dev list. (I have no idea if it solves part of your issues).


6. On Monday 6 September 2010, 16:54 by Danny Moules (Rushyo)

@karl Nice find. Shame Twitter don't seem to want to talk about it... how 'soon' is 'soon' I wonder?

7. On Monday 6 September 2010, 19:05 by Mark

Does Firefox face a similar issue with encryption? If so, how do they deal with it?

8. On Monday 6 September 2010, 21:36 by mat

Blair: See http://getsatisfaction.com/oauth/to...

When you steal a consumer key/secret from an opensource application using OAuth, you get... nothing. You still need the access tokens...

At best, you can impersonate the application, it's a problem, but not the one OAuth is trying to solve (which is: not giving out your real password) - you still shouldn't use applications you don't know you can trust!

It's a real problem with Twitter implementation though, because they use the consumer key when they ban misbehaving applications.

9. On Wednesday 8 September 2010, 11:11 by chomp

Ou comment mettre 15€ à la poubelle…