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 Neil http://www.peepwl.com 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"? >> >
