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
* 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
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
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
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
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
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
this is an interesting idea -- what twitter could do is keep key
hierarchies mapping a master consumer key to subsidiary consumer keys...?
On Sun, Jan 31, 2010 at 8:04 AM, Josh Roesslein jroessl...@gmail.comwrote:
I wonder if Twitter could provide developers with an URL for
dynamically
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
-Original Message-
From: Cameron Kaiser spec...@floodgap.com
Date: Sat, 30 Jan 2010 23:02:18
To: twitter-development-talk@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
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
...@floodgap.com
Date: Sat, 30 Jan 2010 23:02:18
To: twitter-development-talk@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
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
On Sun, Jan 31, 2010 at 08:04, Josh Roesslein jroessl...@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
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)
On Mon, Feb 1, 2010 at 12:39 AM, srikanth reddy
...@floodgap.com
Date: Sat, 30 Jan 2010 23:02:18
To: twitter-development-talk@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
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
BlackBerry® from Orange
-Original Message-
From: Cameron Kaiser spec...@floodgap.com
Date: Sat, 30 Jan 2010 23:02:18
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
oauth
in Desktop Client
OAuth
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
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, sh! The bad guys are stupid and will never
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-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
oauth
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
On Sun, Jan 31, 2010 at 5:30 PM, funkatron funkat...@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
On Sun, Jan 31, 2010 at 8:26 PM, Cameron Kaiser spec...@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
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
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
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
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
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
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:
Krikorian ra...@twitter.com
Date: Sat, 30 Jan 2010 11:22:13
To: twitter-development-talktwitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth
in Desktop Client
what i would do is just make it clear to people who are using your
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
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
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
34 matches
Mail list logo
