I'm sorry, I was talking about distributing source code. However, I  
wasn't thinking of Open Source (even though I wrote that), I was  
thinking of things like interpreted languages (like PHP) where you  
would distribute an application that can't be compiled in to a binary,  
as, even if you don't release the project as open source, if you can  
download, you have the source code. For example, there is a PHP  
project out there called eyeOS, which does what it sounds like it  
does: creates an Operating System like application that runs in your  
browser. If I were to write a Twitter client for that using OAuth, and  
put that up for download for a user to install, even though I am not  
making it open source, I am still releasing the source code because I  
cannot compile the code into a binary. What would you suggest I do,  
then, to try to hide my consumer key and secret to prevent people from  
using it to spam twitter and (possibly) getting my app shut down?

  - Jason

On Aug 17, 2009, at 4:55 PM, Chris Babcock wrote:

> Silly me. I thought someone was talking about distributing source  
> code.
> Building an enduser distribution is somewhat to entirely different.
> First, there really isn't any point to using OAuth for a client unless
> the client code lives on the network. The whole advantage of the  
> scheme
> is that the user does not have to disclose credentials to one or more
> third parties. An application that doesn't access a third party  
> network
> should use basic authentication over HTTPS.
> If Twitter decides to eliminate basic auth then the correct way  
> (from a
> security stand point) to implement OAuth would be to obtain a separate
> key for each client. I don't see the current OAuth spec as being set  
> up
> to handle bulk key assignments, but you can't distribute a single  
> key to
> multiple clients outside of your network. Whether or not the app is
> Open Source is a non-issue; It's complete FUD-rucking to imply that it
> is any diffent distributing a secret key in a close source app than it
> would be to do so in an open source app.
> What happens if you try to use a screwdriver as a hammer? It's the  
> same
> thing here only someone had to drag Open Source into as if that made
> any kind of a difference. To top it off, the OP had a complete
> misunderstanding of the consequences of key disclosure. "A Spammer
> could use it and get your app banned..." as if that's of any
> consequence compared to the users' accounts getting hijacked by apps
> impersonating your client.
> And what's with keeping score as if Open Auth and basic were a couple
> of talking tools on Disney Channel having some sort of ludicrous
> rivalry?
> Chris Babcock
>> This is interesting Chris, as I have had the same question.  How  
>> would
>> you propose to distribute a usable FLOSS twitter app that uses Oauth
>> to authenticate itself but doesn't include the app's consumer key and
>> consumer secret?  fetch the key and secret at runtime from a secure
>> server somewhere?  that could be trivially intercepted.
>> Joseph Cheek
>> @cheekdotcom
>> Chris Babcock wrote:
>>> On Sun, 16 Aug 2009 18:49:49 -0400
>>> Jason Martin <legos.j...@gmail.com> wrote:
>>>> On another note, how "Open Source friendly" is OAuth? I'm not sure
>>>> if people who write open source software want to be giving out
>>>> their Consumer Secret key in their source code
>>> Reasoning from a faulty premise.
>>> When you know your code is going to be seen you either avoid doing
>>> stupid things like hard coding credentials or you learn fast that
>>> configuration data is not code.
>>> (Now where I did leave my virtual haddock?)
>>> Chris Babcock

Reply via email to