On Mon, Feb 1, 2010 at 7:36 AM, Raffi Krikorian 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 wan
* Raffi Krikorian [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
> kno
>
> 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 environme
On Sun, Jan 31, 2010 at 8:26 PM, Cameron Kaiser 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
>>
>>
> 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 mobi
On Sun, Jan 31, 2010 at 5:30 PM, funkatron 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 d
On Sun, Jan 31, 2010 at 1:36 PM, Isaiah Carew 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'
; > > 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.
>
&g
>
> 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 nev
>
> 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/co
; 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
>> >
>&g
ll be secure.
>
> > > Sent using BlackBerry® from Orange
>
> > > -Original Message-
> > > From: Cameron Kaiser
> > > Date: Sat, 30 Jan 2010 23:02:18
> > > To:
> > > Subject: Re: [twitter-dev] Re: a security problem puzzled me abou
ent using BlackBerry® from Orange
> >
> > -----Original Message-----
> > From: Cameron Kaiser
> > Date: Sat, 30 Jan 2010 23:02:18
> > To:
> > Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
> oauth
> >in Desktop Client
&
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
wro
On Sun, Jan 31, 2010 at 08:04, Josh Roesslein 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 c
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 d
Message-
> From: Cameron Kaiser
> Date: Sat, 30 Jan 2010 23:02:18
> To:
> 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,
> 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 wit
-Original Message-
From: Cameron Kaiser
Date: Sat, 30 Jan 2010 23:02:18
To:
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
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 appli
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 wrote:
> I wonder if Twitter could provide developers with an URL for
> dynamically generating additional co
> 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 i
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
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,
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 ma
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 matt
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 ri
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
Krikorian
Date: Sat, 30 Jan 2010 11:22:13
To: twitter-development-talk
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 open
source client that they need to register their
> 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:
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
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 op
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 crea
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
con
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 OAut
35 matches
Mail list logo
