What's the official stance towards oAuth and desktop apps: will all
apps, *including desktop apps* be required to implement oAuth?
I'm asking 'cos of the old usability chestnut.
And, at which point do you actually begin to trust an app that you've
installed onto your system with all sorts of other rights like
deleting files off of your machine or sending info from your machine
to the Net. At which point does user beware come into it?
The real benefit of oAuth, as I see it; being able to revoke access,
is as simple as uninstalling the app. Then again, of course, the app
could send your details to a site. But, again, this is a desktop app
you've installed -- if it's that malicious, it could be doing all
sorts of trojany things that are far worse.
Eventually, once we've got user experience solutions that work for the 80% case, we'll be moving off of Basic Auth entirely. But not before desktop app developers are happy. It's going to take some experimenting, but I'm sure that we can find some good solutions between the smart folks in this community and those in the greater OAuth/web standards community.
OAuth doesn't prevent evil folks from shipping Twitter apps that might be trojans, but it does allow us here at the Mother Ship to revoke their ability to talk to the Twitter API. That means less spam/"SEO" tools, and a short time-to-live for applications that are discovered to be malicious.
On Tue, Feb 17, 2009 at 10:17, Aral Balkan <aralbal...@gmail.com> wrote:
> Hey @al3x et. al.,
> What's the official stance towards oAuth and desktop apps: will all > apps, *including desktop apps* be required to implement oAuth?
> I'm asking 'cos of the old usability chestnut.
> And, at which point do you actually begin to trust an app that you've > installed onto your system with all sorts of other rights like > deleting files off of your machine or sending info from your machine > to the Net. At which point does user beware come into it?
> The real benefit of oAuth, as I see it; being able to revoke access, > is as simple as uninstalling the app. Then again, of course, the app > could send your details to a site. But, again, this is a desktop app > you've installed -- if it's that malicious, it could be doing all > sorts of trojany things that are far worse.
Another thing I was thinking about was specifically for AIR-based apps
(and I guess, to a larger degree, any desktop app) with regards to the
consumer secret.
If that's included in the desktop app, especially in a SWF for AIR
apps, it's basically open to the world. So another app could use the
consumer secret.
Based on your response, I'm assuming that any new desktop client
should implement oAuth as the only means of auth since the switch will
definitely happen at some point.
Thanks,
Aral
On Feb 17, 8:46 pm, Alex Payne <a...@twitter.com> wrote:
> Eventually, once we've got user experience solutions that work for the
> 80% case, we'll be moving off of Basic Auth entirely. But not before
> desktop app developers are happy. It's going to take some
> experimenting, but I'm sure that we can find some good solutions
> between the smart folks in this community and those in the greater
> OAuth/web standards community.
> OAuth doesn't prevent evil folks from shipping Twitter apps that might
> be trojans, but it does allow us here at the Mother Ship to revoke
> their ability to talk to the Twitter API. That means less spam/"SEO"
> tools, and a short time-to-live for applications that are discovered
> to be malicious.
On Tue, Feb 17, 2009 at 13:51, Aral Balkan <aralbal...@gmail.com> wrote:
> Hey Alex,
> Another thing I was thinking about was specifically for AIR-based apps > (and I guess, to a larger degree, any desktop app) with regards to the > consumer secret.
> If that's included in the desktop app, especially in a SWF for AIR > apps, it's basically open to the world. So another app could use the > consumer secret.
> Based on your response, I'm assuming that any new desktop client > should implement oAuth as the only means of auth since the switch will > definitely happen at some point.
> Thanks, > Aral
> On Feb 17, 8:46 pm, Alex Payne <a...@twitter.com> wrote: >> Eventually, once we've got user experience solutions that work for the >> 80% case, we'll be moving off of Basic Auth entirely. But not before >> desktop app developers are happy. It's going to take some >> experimenting, but I'm sure that we can find some good solutions >> between the smart folks in this community and those in the greater >> OAuth/web standards community.
>> OAuth doesn't prevent evil folks from shipping Twitter apps that might >> be trojans, but it does allow us here at the Mother Ship to revoke >> their ability to talk to the Twitter API. That means less spam/"SEO" >> tools, and a short time-to-live for applications that are discovered >> to be malicious. > <snip>
Would be happy to take part in a brainstorm on that and contribute
however possible.
The UX for setting up multiple accounts on a desktop app where there's
a jarring context change from desktop to browser for each (inc.
possibly logging out/in to different accounts on Twitter) just scares
me.
Aral
On Feb 17, 10:02 pm, Alex Payne <a...@twitter.com> wrote:
> Yes, we need a solution for shipping desktop and open source apps. But
> indeed, new apps should definitely look towards OAuth.
> Thanks for setting up that wiki, I just added a link to some thoughts
I'm putting some of my thoughts on there too. Hopefully others will join in.
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Of course, what I really want is total world domination. -- Linus Torvalds -
I'd also recommend checking out some very successful desktop
applications that use OAuth or OAuth-like flows, including Netflix on
the XBox, iMovie's YouTube integration, and any desktop Flickr
uploaders. In particular, engaging the developers of those
applications and the developers at NetFlix, YouTube, and Flickr, may
produce insights from running production services of this type. All
the relevant parties are on the OAuth lists, but may need some coaxing
to comment. ;-)
cheers,
b.
On Feb 19, 12:27 am, Cameron Kaiser <spec...@floodgap.com> wrote:
> > Thanks for setting up that wiki, I just added a link to some thoughts
> I'm putting some of my thoughts on there too. Hopefully others will join in.
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/-- > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
> -- Of course, what I really want is total world domination. -- Linus Torvalds -
To add to Blaine's comments, we would love to see folks with general
ideas or thoughts about improving OAuth's user experience contribute
to the existing OAuth wiki: http://wiki.oauth.net (also a PBWiki) or
sharing your thoughts on the OAuth mailing list(s).
The iMovie to YouTube flow that Blaine alluded to can be seen here:
> I'd also recommend checking out some very successful desktop
> applications that use OAuth or OAuth-like flows, including Netflix on
> the XBox, iMovie's YouTube integration, and any desktop Flickr
> uploaders. In particular, engaging the developers of those
> applications and the developers at NetFlix, YouTube, and Flickr, may
> produce insights from running production services of this type. All
> the relevant parties are on the OAuth lists, but may need some coaxing
> to comment. ;-)
> cheers,
> b.
> On Feb 19, 12:27 am, Cameron Kaiser <spec...@floodgap.com> wrote:
> > > Thanks for setting up that wiki, I just added a link to some thoughts
> > I'm putting some of my thoughts on there too. Hopefully others will join in.
> > --
> > ------------------------------------ personal:http://www.cameronkaiser.com/-- > > Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com
> > -- Of course, what I really want is total world domination. -- Linus Torvalds -
|
