a security problem puzzled me about using oauth in Desktop Client

[ShellEx Well]

if a twitter App's Consumer key and secret were leak out, is it
possible to gain a user's access token without a user authentication
process ?

I am writing a opensource desktop client and has implemented OAuth for
it. However, I don't know is it suitable to put my key and secret in
the source? Are there any risks if i do that?

Thx :)

[Raffi Krikorian]

the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention).

however - do not put the consumer key and secret in the source of your code and distribute it.  instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one.

hope that helps.

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[ShellEx Well]

Some project (like dabr) put key and secret in config files.
But I think it really suck for users who want to use my client with
OAuth. Because they have to get a pair of key/secret and do configure
themselves, and the this is not convenience for users.

So I doubt that is it a good way to use OAuth in Desktop Client.

On Jan 30, 1:35 am, Raffi Krikorian <ra...@twitter.com> wrote:
> the leak of a consumer secret will not result in the compromising of user
> accounts (the consumer secret is needed to get user secrets, but to get user
> secrets require the user's intervention).
>
> however - do not put the consumer key and secret in the source of your code
> and distribute it.  instead, make it possible for your source to read the
> consumer key and secret from a configuration, and distribute, with your
> source code, a sample configuration file or a README that details how to
> create one.
>
> hope that helps.
>

[Raffi Krikorian]

what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple "wizard" that they can cut and paste the consumer token and secret into.

[Abraham Williams]

I assume you have 2 versions: 

1) the opensource code that developers can use and modify. You would not include your consumer key/secret and have instructions on how to get their own. Although you could include your consumer values as defaults and get free publicity from any projects that don't create and use their own. 

2) the compiled version that end users will download and expect to just work. In these include your consumer key/secret but be aware that use them for limited nefarious purposes. Applications could take your consumer information and if they convince users to go through the authentication process make requests to the API that appear to be from your application.

Abraham

--
Abraham Williams | Community Advocate | http://abrah.am
Project | Out Loud | http://outloud.labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Seattle, WA, United States

[funkatron]

Not to be a complete pill, but that is a terrible, terrible initial
experience for the average desktop app user. There is no way I would
or could reasonably ask one of my users to register an app themselves,
then fill in obscure hashes.

The OAuth secret is simply impossible to use securely with open
source, end-user-oriented applications. My only option with Spaz, when
Twitter decides to take away basic auth, is to pray someone doesn't
decide to steal my "secret" hash.

Compiling does make getting the key more difficult, but assuming that
desktop apps are compiled isn't a good idea -- Spaz isn't, for
example. I could obscure the code for the end user, I suppose, but
doing so seems contrary to open source philosophy, and probably just
presents a challenge.

OAuth as-is just wasn't designed for desktop apps, period. Square peg,
round hole. If Twitter is insisting on it, I'd rather this was
portrayed as a trade-off for increased user security, than a solvable
problem -- I don't think it is.

On Jan 30, 2:22 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> what i would do is just make it clear to people who are using your open
> source client that they need to register their downloaded application with

> Twitter -- send them tohttp://twitter.com/apps/new, instruct them to fill

[Josh Roesslein]

I suppose the only other way to make the UX good and to keep the consumer secret
absolutely hidden is to proxy all requests through a hosted server.
This does come as a cost
of having to pay for a server to perform the proxy work. But it's
really the only option
at the moment I can think of that's 100% safe.

Josh

[Cameron Kaiser]

> OAuth as-is just wasn't designed for desktop apps, period. Square peg,
> round hole. If Twitter is insisting on it, I'd rather this was
> portrayed as a trade-off for increased user security, than a solvable
> problem -- I don't think it is.

+1

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I'd love to go out with you, but I'm in perpetual denial." ----------------

[scott.a...@googlemail.com]

Why not check for the presence of the keys on start-up, if they are missing re-direct the user (open a browser window) to the new apps page and/or a step-by-step guide on you site. then store the keys as normal

Sent using BlackBerry® from Orange

---

From: Raffi Krikorian <ra...@twitter.com>

Date: Sat, 30 Jan 2010 11:22:13 -0800

To: twitter-development-talk<twitter-deve...@googlegroups.com>

Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client

[Isaiah Carew]

So, in simple language:  Twitter's policy is that every user of every open source client register as a new twitter application?

Or, have I misinterpreted something?  And if so, could you explain further what mean?

Thanks,

Isaiah

what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple "wizard" that they can cut and paste the consumer token and secret into.

isaiah

http://twitter.com/isaiah

[ShellEx Well]

Well, I use python to write my application. Although I can distribute
it with '.pyo' files which only contain bytecode, it's really not hard
to obtain the key/secret for a end user. Decompiling is always able
to succeed for the people who want to discover the secrets in the
program. Yes you are right.

[ShellEx Well]

I have considered this matter. But to use a proxy handle all request
is not my intention... I will go to write a online version if i have
to do that :D.

What I want to know is that: in my distributed version, should I
include the key/secret in the config file(or hardcode in source, it
doesn't matter)?

[srikanth reddy]

Using a proxy to handle all requests is not that simple. You need both consumer and access secrets to sign the request.

http://groups.google.co.in/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297/851d9b34ecc9126f?q=#851d9b34ecc9126f

You have to handle the burden of securely mapping user request from your desktop app to get his access token with in the proxy.
I would rather prefer distributing them either as obfuscated or through secure proxy (just to fetch consumer key/secret once). None of them is 100% safe but it is slightly better than simply giving away your keys in plain text.

[Michael Ekstrand]

On 01/30/2010 02:43 PM, Isaiah Carew wrote:

So, in simple language:  Twitter's policy is that every user of every open source client register as a new twitter application?

Or, have I misinterpreted something?  And if so, could you explain further what mean?

If that were the case, then it would be the requirement for all desktop apps.  Open source just makes it easier to grab the key; if you stick your keys in your Air or .NET app, they can still be grabbed.

Basically, if you're doing a desktop app (of any kind) with OAuth, there is a risk that your consumer key will be misappropriated.  The OAuth spec explicitly acknowledges this, stating that the consumer key/secret is cannot necessarily be trusted to securely identify the consumer.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[Josh Roesslein]

I wonder if Twitter could provide developers with an URL for
dynamically generating additional consumer tokens for their
applications. When the user installs a new application it will contact
the developer's server to download its own consumer key/secret. The
developer's server will use its "master" consumer key/secret to post
to the Twitter URL to fetch a new consumer key/secret. The consumer
pair will then be sent to the application via a secure channel
(HTTPS?) to prevent man in the middle attacks. The application will
then use this new consumer pair to perform all signing of requests.
Another option is to package the dynamically generated consumer pair
in the application download package. Each new download will have its
own unique consumer pair ready for use once the user has downloaded
the application.

This still requires the developer maintain a server to perform the
consumer pair generation, but it does keep the "master" pair secure
and each application gets its own pair. But applications that are
willing to make this trade off can keep the UX good, control what
application instances can authorize on the application's behalf, and
the "master" pair is never shared. You can always still distribute the
"master" pair with each application if these security gains are not
that important to you. Or you can require your users to generate their
own consumer pair if UX is not much of an issue (example: distributed
server applications) where an advance users is at the wheel and won't
have issues figuring this out.

Josh

[Cameron Kaiser]

> I wonder if Twitter could provide developers with an URL for
> dynamically generating additional consumer tokens for their
> applications. When the user installs a new application it will contact
> the developer's server to download its own consumer key/secret. The
> developer's server will use its "master" consumer key/secret to post
> to the Twitter URL to fetch a new consumer key/secret. The consumer
> pair will then be sent to the application via a secure channel
> (HTTPS?) to prevent man in the middle attacks. The application will
> then use this new consumer pair to perform all signing of requests.
> Another option is to package the dynamically generated consumer pair
> in the application download package. Each new download will have its
> own unique consumer pair ready for use once the user has downloaded
> the application.

I like those ideas. They match up maintaining a consistent application
identity with better key security. The first one seems more workable.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- I couldn't care less about apathy. -----------------------------------------

[Raffi Krikorian]

this is an interesting idea -- what twitter could do is keep "key hierarchies" mapping a master consumer key to subsidiary consumer keys...?

[Josh Roesslein]

Yeah basically twitter can allow developers to generate children keys
from their master key they received during application registration.
The developer is then free to delegate the generated "children" to
whom ever they wish. This gives us freedom to then pick who can sign
requests using our application name. We can be very open with this
(basically a hidden, public API for the desktop applications) or
restrictive (password/secret guarded API) on our end.

Josh

[scott.a...@googlemail.com]

I 100% agree.

But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their.

You lose some of the open source nature of the app but it will be secure.

Sent using BlackBerry® from Orange

-----Original Message-----
From: Cameron Kaiser <spe...@floodgap.com>
Date: Sat, 30 Jan 2010 23:02:18
To: <twitter-deve...@googlegroups.com>
Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth
in Desktop Client

[Cameron Kaiser]

> But another idea just struck me, why not put the OAuth part of your app in a
> DLL (at lest the authentication and communication with twitter part) and
> hard code it their.

If you include the key, sooner or later it will be found. Just ask Jon
Lech Johansen.

It may not be worth it for apps with small user bases, but that's not much
security.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- In Computer Science, we stand on each other's feet. -- Brian Reid ----------

[Josh Roesslein]

That's not all that secure, eventually it will be loaded into memory
and can be found by any hacker with some patience. As soon as you
distribute any sort of data it is no longer private. You're average
Joe might not be able to find it, but any skilled hacker will. And
after all the average Joe does not care anyways about OAuth tokens
("what's oauth?"), but hackers do. So you're kind of blocking the
wrong person, it's the hacker you want to stop.

Josh

[srikanth reddy]

Interesting.This is more or less similar to each user registering their own app. But twitter may have better control with this hierarchy.

Just wondering if twitter could actually replace 'PIN'  part with those key/secret pair i.e when  the user clicks 'Download app' link in apps webpage  it will do all the initial oauth stuff i.e generating req tokens etc and redirect the user to twitter (https) and (authenticate if required)  twitter will generate the new key/secret pair and it will either
1) redirect these values back to the apps download page so that app can embed these values in the download pkg and push this pkg to user or
2) just display those key/secret in twitter page and ask user to manually enter those details after they download the pkg

The advantage with the second approach is that the apps providers don't have to implement anything significant other than using the regular oauth stuff (just change the url). Even with the first approach there is no need for any sort of client communication from desktop app to app provider after a pkg is downloaded.

Again this whole scenario is for 'PIN' based desktop flows only(not for browser less systems). Basically the reasoning is that if the users have no issues in entering the PIN then they shouldn't have any issues with entering these key/secret pair either.
If UX is an issue then the first approach may be used.

Any comments on this?

[Abraham Williams]

On Sun, Jan 31, 2010 at 08:04, Josh Roesslein <jroes...@gmail.com> wrote:

I wonder if Twitter could provide developers with an URL for
dynamically generating additional consumer tokens for their
applications. When the user installs a new application it will contact
the developer's server to download its own consumer key/secret. The
developer's server will use its "master" consumer key/secret to post
to the Twitter URL to fetch a new consumer key/secret. The consumer
pair will then be sent to the application via a secure channel
(HTTPS?) to prevent man in the middle attacks. The application will
then use this new consumer pair to perform all signing of requests.
Another option is to package the dynamically generated consumer pair
in the application download package. Each new download will have its
own unique consumer pair ready for use once the user has downloaded
the application.

How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connections then there would be some differentiation but then if users install an application five times it would be listed five times.

Abraham

[srikanth reddy]

Just to add more . There will  always be only one level of sub keys in the hierarchy. Everytime the user downloads the same app the same key pair will be given (like access token/secrets) (a user authentication may be made mandatory in this case)

[Abraham Williams]

I would like to point out the official Flickr Uploadr application that is OAuth and open source. If you download it as a user [1] it includes their official API keys but if you download it as a developer [2] you implement your own API keys.

Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/

Abraham

[1] http://www.flickr.com/tools/uploadr/

[2] http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76

[Dewald Pretorius]

Abraham,

Twitter will have to do something to combat application impersonation.

Let's say your app is MyAppName and your URL is http://www.myappname.com.

Currently, anyone can register an app MyApppName or MyAppnName and
give http://www.myappname.com as the URL for the app, with zero
verification. They can do all kinds of naughty things, and your app is
going to take the blame for it in most users' minds.

On Jan 31, 3:19 pm, Abraham Williams <4bra...@gmail.com> wrote:
> I would like to point out the official Flickr Uploadr application that is
> OAuth and open source. If you download it as a user [1] it includes their
> official API keys but if you download it as a developer [2] you implement
> your own API keys.
>
> Ironically all of these massive threads talking about impersonating
> applications is probably just making more crackers aware that they can do
> this. :-/
>
> Abraham
>
> [1]http://www.flickr.com/tools/uploadr/
> [2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
>
>
>
> On Sun, Jan 31, 2010 at 10:06, Josh Roesslein <jroessl...@gmail.com> wrote:
> > That's not all that secure, eventually it will be loaded into memory
> > and can be found by any hacker with some patience. As soon as you
> > distribute any sort of data it is no longer private. You're average
> > Joe might not be able to find it, but any skilled hacker will. And
> > after all the average Joe does not care anyways about OAuth tokens
> > ("what's oauth?"), but hackers do. So you're kind of blocking the
> > wrong person, it's the hacker you want to stop.
>
> > Josh
>

> > On Sun, Jan 31, 2010 at 2:28 AM,  <scott.a.herb...@googlemail.com> wrote:
> > > I 100% agree.
>
> > > But another idea just struck me, why not put the OAuth part of your app
> > in a DLL (at lest the authentication and communication with twitter part)
> > and hard code it their.
>
> > > You lose some of the open source nature of the app but it will be secure.
>
> > > Sent using BlackBerry® from Orange
>
> > > -----Original Message-----
> > > From: Cameron Kaiser <spec...@floodgap.com>
> > > Date: Sat, 30 Jan 2010 23:02:18
> > > To: <twitter-deve...@googlegroups.com>
> > > Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
> > oauth
> > >        in  Desktop Client
>
> > >> OAuth as-is just wasn't designed for desktop apps, period. Square peg,
> > >> round hole. If Twitter is insisting on it, I'd rather this was
> > >> portrayed as a trade-off for increased user security, than a solvable
> > >> problem -- I don't think it is.
>
> > > +1
>
> > > --
> > > ------------------------------------ personal:
> >http://www.cameronkaiser.com/--
> > >  Cameron Kaiser * Floodgap Systems *www.floodgap.com*

> > ckai...@floodgap.com

[srikanth reddy]

Hmmm. Flickr is a service provider but if a consumer(developer) like Tweetdeck were to implement oauth and if they distribute keys there is always this problem of misusing those and the very first thing twitter would do is ban that application.
Flickr can share it, but developers? i do not know .

[Josh Roesslein]

How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connections then there would be some differentiation but then if users install an application five times it would be listed five times.

Abraham

I am not entirely sure what security benefits there is for having unique consumer pairs per an application instance. One I can think of is during the get access token step w/o HTTPS. A man in the middle could in theory steal the access token and generate valid signatures if the consumer secret is publicly known. If each instance had its own consumer pair then the attacker could do nothing with this access token. There may be other benefits of having a strong consumer secret for the signing process. A person more familiar with crypto would have to weigh in on that issue.

For the connections listing it would probably only be listed once per an application. All access tokens generated from the sub-keys of the master consumer key would be invalidated. This may cause issues if the comprimised account was caused by using a stolen consumer sub-key. Both good and bad access tokens would get killed. Best thing is to make your application resilient and just have the user repeat the OAuth dance if the access tokens you have ever gets invalidated.

Having multiple consumer keys also allows providing both a server and desktop service using the same application name. You don't want to be running the same consumer key you have publicly shared. Here your server and desktop applications would each get their own consumer pair.

There is nothing you can really do to block impersonation of applications. If you grant code that is running on a machine you don't have control over access to a consumer pair linked to your application, it can do what ever it wants. You can play hide and seek the best you can with the hackers, but its a never ending battle of changing consumer pairs after they get leaked over and over again.


I think the big question is how big of a deal is impersonating the "from" attribute? People are going to associate the content of the tweet with the account it was posted with, not the application that delivered it. If its a spam message from "freecomputers3332" account posted by "Tweetapp", people are not going to say "hey that Tweetapp is spamming me". Instead they are going to report "freecomputer3332" as spam and forget it.

[Isaiah Carew]

Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/

You're right!  Openness about security is really going to hurt us all!  Everyone, quick, shhhhh!  The bad guys are stupid and will never figure it out if we just keep quiet!

OK, sorry, I couldn't resist the bait.  ;-)  Especially coming from someone that I know appreciates openness.  No, I don't actually feel that way.  I do actually see your point, but I think the value of discussing threats, so long as the discussions remain unspecific, are probably more valuable than they are detrimental.

Also, I think you have it right, that distribution of the source sans keys and the binary with keys is the way to go.  I completely agree that it's the obvious practical solution.  It's the one that took myself for my OSS OAuth code.

However, it also misses the point.  The point is that the keys not kept safe in any desktop app, and the challenges are double in open source apps.  Up until this point they've probably been safe enough because there have been few targets worth the effort of cracking.  I suspect that will change when the clients with many users enter the picture.  With many more users there are many more reasons why someone might want to spoof as a specific client.

I'd say its a pretty reasonable bet that one of the major desktop clients will be compromised within a year or so of implementing OAuth -- and will probably result in a lot of user frustration.  It seems like their will be ample motivation and little to prevent them.

Only time will tell, you're free to come and laugh at me if it doesn't happen.  Bookmark this email, we'll check back in 18 months.  ;-)

Isaiah

[funkatron]

This isn't a zero-day vuln that hasn't been reported to the vendor, so
I think any suggestion that keeping it on the DL is not helpful. This
is a known issue with application of the OAuth spec. Educating the
developers who read this list, and maybe helping Twitter's engineering
team understand the problems better, should be top priority.

Pointing out what Flickr does is fine, but they're also in more of a
position to address possible abuses of their own API key as both the
consumer and the provider. App devs will have to hope that the API
support team responds quickly to these issues – and without and SLA or
support agreement in most cases, Twitter is under no obligation to
care. I hope it's *not* like that, but I think we've all seen cases
where feedback and response time wasn't what we'd like.

I agree that much of this seems like beating a dead horse, but I'd
also like to see more official response about it, even if it's just
"hey, we know, and this is just the tradeoff we need to make."
Otherwise, I think we're providing feedback as requested on the API in
general, and authentication in particular.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funk...@gmail.com

On Jan 31, 2:19 pm, Abraham Williams <4bra...@gmail.com> wrote:
> I would like to point out the official Flickr Uploadr application that is
> OAuth and open source. If you download it as a user [1] it includes their
> official API keys but if you download it as a developer [2] you implement
> your own API keys.
>
> Ironically all of these massive threads talking about impersonating
> applications is probably just making more crackers aware that they can do
> this. :-/
>
> Abraham
>
> [1]http://www.flickr.com/tools/uploadr/
> [2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
>
>
>
>
>
> On Sun, Jan 31, 2010 at 10:06, Josh Roesslein <jroessl...@gmail.com> wrote:
> > That's not all that secure, eventually it will be loaded into memory
> > and can be found by any hacker with some patience. As soon as you
> > distribute any sort of data it is no longer private. You're average
> > Joe might not be able to find it, but any skilled hacker will. And
> > after all the average Joe does not care anyways about OAuth tokens
> > ("what's oauth?"), but hackers do. So you're kind of blocking the
> > wrong person, it's the hacker you want to stop.
>
> > Josh
>

> > On Sun, Jan 31, 2010 at 2:28 AM,  <scott.a.herb...@googlemail.com> wrote:
> > > I 100% agree.
>
> > > But another idea just struck me, why not put the OAuth part of your app
> > in a DLL (at lest the authentication and communication with twitter part)
> > and hard code it their.
>
> > > You lose some of the open source nature of the app but it will be secure.
>
> > > Sent using BlackBerry® from Orange
>
> > > -----Original Message-----
> > > From: Cameron Kaiser <spec...@floodgap.com>
> > > Date: Sat, 30 Jan 2010 23:02:18
> > > To: <twitter-deve...@googlegroups.com>
> > > Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
> > oauth
> > >        in  Desktop Client
>
> > >> OAuth as-is just wasn't designed for desktop apps, period. Square peg,
> > >> round hole. If Twitter is insisting on it, I'd rather this was
> > >> portrayed as a trade-off for increased user security, than a solvable
> > >> problem -- I don't think it is.
>
> > > +1
>
> > > --
> > > ------------------------------------ personal:
> >http://www.cameronkaiser.com/--
> > >  Cameron Kaiser * Floodgap Systems *www.floodgap.com*

> > ckai...@floodgap.com

[M. Edward (Ed) Borasky]

On Sun, Jan 31, 2010 at 1:36 PM, Isaiah Carew <isa...@me.com> wrote:
> Also, I think you have it right, that distribution of the source sans keys
> and the binary with keys is the way to go.  I completely agree that it's the
> obvious practical solution.  It's the one that took myself for my OSS OAuth
> code.

I'm not convinced that distributing *any* oAuth capability to end
users, even in binary form - even in a form where said binary
interfaces in secure ways with the underlying desktop / mobile ways to
persist the consumer key and secret - is the "way to go". I personally
think the "way to go" is to deploy applications as servers with the
thinnest possible client imaginable. If ChromeOS netbooks actually
existed today, that's what I'd be building - servers that interacted
with Twitter on behalf of users with ChromeOS netbooks.

Given what I know now about oAuth, I'm not planning on releasing any
oAuth desktop applications. I never *was* planning mobile ones - the
kind of processing I have in mind flat out can't be done on a mobile,
so I'd have to have a server anyway to deploy to mobile users.

> I'd say its a pretty reasonable bet that one of the major desktop clients
> will be compromised within a year or so of implementing OAuth -- and will
> probably result in a lot of user frustration.  It seems like their will be
> ample motivation and little to prevent them.
> Only time will tell, you're free to come and laugh at me if it doesn't
> happen.  Bookmark this email, we'll check back in 18 months.  ;-)
> Isaiah

Well ... the motivation is there now, with or without oAuth. And oAuth
doesn't make it *easier* to compromise a desktop application. As far
as desktop "user frustration" is concerned, though, there are so many
other sources of desktop user frustration already - botnets, weekly
virus scans that take hours, browser vulnerabilities, 15-30 minute
waits before the machine is "open for business", and, of course, the
hundreds of dollars one pays per year for just a license to use the
desktop software - that I think a compromised Twitter desktop platform
isn't going to get much attention unless it does something really
nasty, like a DDOS against Twitter.

--
M. Edward (Ed) Borasky
http://borasky-research.net

"I've always regarded nature as the clothing of God." ~Alan Hovhaness

[M. Edward (Ed) Borasky]

On Sun, Jan 31, 2010 at 5:30 PM, funkatron <funk...@gmail.com> wrote:
> ... maybe helping Twitter's engineering

> team understand the problems better, should be top priority.

I think Twitter's engineering team does understand the issues. But I
think the primary responsibility lies with us developers, and I for
one don't see the point in investing effort building desktop Twitter
applications, given

a. They're tough to scale down to mobile platforms, and mobile usage
seems to be where the growth and action are in social media, and

b. oAuth or not, desktop applications are difficult to secure.

c. The Streaming API isn't designed to play well with desktops /
laptops / mobiles.

> I agree that much of this seems like beating a dead horse, but I'd
> also like to see more official response about it, even if it's just
> "hey, we know, and this is just the tradeoff we need to make."
> Otherwise, I think we're providing feedback as requested on the API in
> general, and authentication in particular.

The environment in which Twitter and the Twitter development community
operate is changing rapidly. The *desktop* oAuth tradeoffs may have
made sense a year ago. before the huge growth spurt in awareness and
usage of Twitter in 2009. As I've noted, I think the *server* oAuth
tradeoffs still make sense. I think we need to take the advice of
Wayne Gretzky and "skate to where the puck is going to be."

I should also note that I have never used a "desktop Twitter client".
I installed one once on my Linux workstation, and got frustrated by
the Adobe AIR platform issues. The client wasn't giving me any
functionality I couldn't get from a free server like HootSuite or even
from Firefox, and there wasn't anything else I wanted that used AIR.
So I'm not losing anything if "desktop oAuth" doesn't get "enhanced".

[Cameron Kaiser]

> I think Twitter's engineering team does understand the issues. But I
> think the primary responsibility lies with us developers, and I for
> one don't see the point in investing effort building desktop Twitter
> applications, given
>
> a. They're tough to scale down to mobile platforms, and mobile usage
> seems to be where the growth and action are in social media, and
>
> b. oAuth or not, desktop applications are difficult to secure.
>
> c. The Streaming API isn't designed to play well with desktops /
> laptops / mobiles.

So don't develop one. But, speaking as a dev who eats his own dog food, I
prefer to have a console open running TTYtter than mashing refresh all the
time in Camino. Desktop apps are a useful part of the ecosystem, and I
wouldn't be participating in Twitter anywhere near as much as a user if I
had a much higher barrier to do so or had to trust a third-party service and
add another layer on to do so on my behalf. I assume @funkatron's users
have the same opinion.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- LET'S GO FORWARD ... INTO THE PAST! ----------------------------------------

[M. Edward (Ed) Borasky]

On Sun, Jan 31, 2010 at 8:26 PM, Cameron Kaiser <spe...@floodgap.com> wrote:
>> I think Twitter's engineering team does understand the issues. But I
>> think the primary responsibility lies with us developers, and I for
>> one don't see the point in investing effort building desktop Twitter
>> applications, given
>>
>> a. They're tough to scale down to mobile platforms, and mobile usage
>> seems to be where the growth and action are in social media, and
>>
>> b. oAuth or not, desktop applications are difficult to secure.
>>
>> c. The Streaming API isn't designed to play well with desktops /
>> laptops / mobiles.
>
> So don't develop one. But, speaking as a dev who eats his own dog food, I
> prefer to have a console open running TTYtter than mashing refresh all the
> time in Camino. Desktop apps are a useful part of the ecosystem, and I
> wouldn't be participating in Twitter anywhere near as much as a user if I
> had a much higher barrier to do so or had to trust a third-party service and
> add another layer on to do so on my behalf. I assume @funkatron's users
> have the same opinion.

Yes, I write my own desktop apps too, but I don't distribute them. I
never saw the need to use a desktop client when the browser worked
just fine. Then again, I don't own a Mac and don't use Windows very
often. Maybe a desktop client on a Windows or Mac makes more sense
than it does on Linux. Assuming, of course, that a Linux desktop
itself makes any sense - there aren't a lot of folks who agree with me
on my choice of desktop. ;-)

[Raffi Krikorian]

c. The Streaming API isn't designed to play well with desktops /
laptops / mobiles.

(not to change the direction of the thread) just out of curiosity - why do you think that's the case?  we don't intend it not to play well, and want to know what you think should be fixed.

 

The environment in which Twitter and the Twitter development community

operate is changing rapidly. The *desktop* oAuth tradeoffs may have
made sense a year ago. before the huge growth spurt in awareness and
usage of Twitter in 2009. As I've noted, I think the *server* oAuth
tradeoffs still make sense. I think we need to take the advice of
Wayne Gretzky and "skate to where the puck is going to be."

i just want to really emphasize that we all do energetically read these email threads and try to learn as much as we can from them.  this thread, so far, has been great.

 

[Marc Mims]

* Raffi Krikorian <ra...@twitter.com> [100201 07:36]:

> >
> > c. The Streaming API isn't designed to play well with desktops /
> > laptops / mobiles.
> >
>
> (not to change the direction of the thread) just out of curiosity - why do
> you think that's the case? we don't intend it not to play well, and want to
> know what you think should be fixed.

As I understand it, the Streaming API uses only Basic Authentication
*without* SSL. That frightens me. It means anyone who can sniff
traffic at the hosting site I use can hijack the account I use for
Streaming API access.

Now that the Streaming API is no longer beta, will Twitter be providing
some more secure mechanism for authenticating?

-Marc

[M. Edward (Ed) Borasky]

On Mon, Feb 1, 2010 at 7:36 AM, Raffi Krikorian <ra...@twitter.com> wrote:
>> c. The Streaming API isn't designed to play well with desktops /
>> laptops / mobiles.
>
> (not to change the direction of the thread) just out of curiosity - why do
> you think that's the case?  we don't intend it not to play well, and want to
> know what you think should be fixed.

My choice of words was wrong. I don't remember the exact language - I
can find it if necessary - but when the Streaming API was released to
production status, John Kalucki said that desktop developers should
hold off on production use of Streaming but that it was OK to test
with it.

But Streaming is a steady, hopefully uninterrupted flow of tweets.
Those have to be buffered / persisted for at least some length of time
for them to be useful beyond just "displaying breaking news". Mobiles
don't have the space and have limited memory and processing
capabilities. And if they're going to be always on and always
collecting / processing data, they have to be plugged in.

I can see a case for building a desktop app with Streaming, provided
you have a backup mechanism for data collection in case your desktop
needs to be rebooted. But laptops are essentially the same deal as
mobiles - they aren't always plugged in to a power source.

>> The environment in which Twitter and the Twitter development community
>> operate is changing rapidly. The *desktop* oAuth tradeoffs may have
>> made sense a year ago. before the huge growth spurt in awareness and
>> usage of Twitter in 2009. As I've noted, I think the *server* oAuth
>> tradeoffs still make sense. I think we need to take the advice of
>> Wayne Gretzky and "skate to where the puck is going to be."
>
> i just want to really emphasize that we all do energetically read these
> email threads and try to learn as much as we can from them.  this thread, so
> far, has been great.

I've said this before, but maybe not here. As a developer I've worked
with a number of companies over the years, and I can't think of any
that was easier to work with than Twitter. Part of it is the
simplicity of the API - have a look at Google's or Facebook's some
time. ;-) But a bigger part is that you do understand what our
challenges are.

It's not just oAuth and it's not just Twitter - mobile and desktop
security is a big challenge. Microsoft has been unable to stop the
spread of botnets on Windows, and only the relative rarity of Mac and
Linux desktops has prevented them from becoming botnet targets as
well. Google's idea of a locked-down netbook that can't be compromised
without a screwdriver and a soldering iron is looking very good to me
right now. ;-)