yep, just me,
thanks,
isaiah
p.s. subject changed to protect the on-topic folks. @isaiah for
more. ;-)
On Jul 1, 2009, at 12:27 PM, Neil Ellis wrote:
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
[email protected]
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 <[email protected]> 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"?
