On a completely separate note, your website is stunning, did you  
design it yourself? If not may I ask who were your designers.

All the best

On 1 Jul 2009, at 20:22, Support wrote:

> Matt,
> Thanks for weighing in and hopefully taming this snarl.  As the  
> person who might have posed the question originally, I figured I at  
> least owed a bit of constructive critique.
>> What can we change about OAuth that would make this better?
> 1) User experience - it's been echoed a number of times in this  
> board, so i won't beat the dead horse...   much...    but basic auth  
> *is* much simpler for the user.
> The reason is obvious:  oauth requires a browser. In many platforms  
> (especially mobile) that's a painful burden.
> The PIN code seems to be ignoring the elephant in the room.  It  
> solves some problems, but at a further cost to the user experience,  
> giving an even larger advantage to existing basic-auth apps.
> You've made the pill even more effective, but so bitter that your  
> patients can't swallow it.
> Providing a scheme that does not require a browser is an obvious way  
> to cut this gordian knot.
> 2) Application authentication - if your goal is to *identify* each  
> open source application in a *trusted* way, then I think you could  
> be in for an uphill battle.  There are obvious technical challenges,  
> however the larger problem is that in OSS there is no way to define  
> "each application."  There will be many binaries for different  
> platforms and people will fork it on github just because they can.   
> You cannot identify each of these variants as the same when they  
> could be different.
> And that places a burden on the user experience.  When a user grants  
> access to "application x" -- what does that mean exactly?  Just that  
> binary?  Just this release?  Only from a specific trusted company?   
> How do you explain to the user where this subtle line is drawn in a  
> box he'll click through in less than a second?
> I personally don't see an obvious solution to this problem.  It  
> seems to be a UI challenge and a technical challenge.  In cases like  
> that it seems prudent to question your goals and check feasibility.
> Isaiah
> YourHead Software
> supp...@yourhead.com
> http://www.yourhead.com
> On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote:
>> Hello again,
>>    I do not recommend having individual end users register for  
>> consumer keys/secrets [1] under any circumstances. So, with that  
>> out of the way, let us focus the discussion a bit more. What can we  
>> change about OAuth that would make this better? A complete  
>> technical [2][3] discussion on what we could add that would make  
>> this better is welcomed. More than welcome, it's pretty much  
>> required before we can help.
>>    The PIN flow was the first addition to address the inherent  
>> insecurity of the consumer key/secret all desktop applications [3].  
>> This stopped applications from being able to collect tokens by  
>> using the consumer key/secret and a confidence scam (phishing like  
>> "GoodApp needs you to re-approve us"). It sounds like there is a  
>> fervent need for something more … what do people suggest? We're  
>> working hard on the problem but many of you are working from the  
>> consumer standpoint and probably have great feedback.
>>    Please, take your time and write a well thought out reply. One- 
>> line snarky comments, while fun to write and sometimes to read,  
>> steal time from everyone reading the list, including all of the  
>> Twitter API engineers. They also make the list look less inviting  
>> to new comers.
>> Thanks;
>> – Matt Sanford / @mzsanford
>>     Twitter Dev
>> [1] - People installing an instance of your server-side app are not  
>> 'end users', but other developers
>> [2] - Not open-source hand waving.
>> [3] - Closed source desktop apps have the same problem. Reverse  
>> engineering is not stopped when you don't include the source.
>> On Jul 1, 2009, at 9:33 AM, DWRoelands wrote:
>>> Actually, since Twitter has said that Basic Auth will eventually go
>>> away, OAuth is going to be the only choice for authentication.
>>> Twitter has forced the choice by implementing OAuth in the way that
>>> they did.
>>> Why should a user who chooses to support open source by using an  
>>> open-
>>> source Twitter client be punished by having to go through extra  
>>> hoops
>>> that users of closed-source clients don't have to endure?
>>> Forcing users of open source Twitter clients to register their
>>> individual installations as Twitter applications is not a viable
>>> solution.  Matt Sanford has even said so.
>>> No one is asking for "easy".  I just want open source Twitter  
>>> desktop
>>> clients to be able to compete with closed-source versions when it
>>> comes to security.  Right now, that's not possible because of
>>> Twitter's implementation of OAuth.
>>> Regards,
>>> Duane
>>> On Jul 1, 11:23 am, Andrew Badera <and...@badera.us> wrote:
>>>> But that's the choice you're forced to make by OAuth, not  
>>>> Twitter. And
>>>> it is YOUR choice. Personally, I would probably use the  
>>>> conventional
>>>> mechanisms of open source: mailing lists, special interest and user
>>>> groups. Pound the pavement and promote yourself. Who said it was  
>>>> going
>>>> to be "easy"?

Reply via email to