I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data.
@Cameron, I would also agree that an app key would be required in this case, specifically so that Twitter could revoke Basic Auth logins from that app if they were found to be violating the terms of the contract. If that key was disabled, no one would be able to use Twitter from that app, and thus, the app maker would make sure that they were in compliance. -Joel On Feb 5, 8:48 am, Stuart <stut...@gmail.com> wrote: > 2009/2/5 jstrellner <jstrell...@urltrends.com>: > > > I was just thinking this, and then I read your post. It would be good > > to see a "trusted apps" section somewhere on your site, and those > > application could use Basic Auth. If they don't want to go through > > the process of being a trusted app, then they can use OAuth. > > > Just something to think about. Could earn twitter some $$$ too. > > Could also land them in a world of pain. I wouldn't want Twitter to > endorse any product that wasn't theirs, and I doubt they would want to > either. Too risky. > > -Stuart > > > > > On Feb 4, 8:57 pm, Alex Payne <a...@twitter.com> wrote: > >> Thanks for the feedback, guys. We'll consider extending Basic Auth's > >> life, or maybe granting a "stay of execution" to known-good apps. At the > >> very least, we'll try not to pull the rug out from under anyone. > > >> funkatron wrote: > >> > Agreed. I do believe that the use of HTTP Basic Auth was key to the > >> > quick growth of the 3rd-party app community of Twitter, as the auth > >> > scheme is so well-understood and supported. This may or may not be as > >> > important at this point business-wise, as I suspect the Twitter > >> > userbase is large enough to overcome a fair bit of lazy user intertia. > >> > I wonder if we will see a lot less interesting API hacking (the good > >> > kind), though, and I think that would be a shame. > > >> > While OAuth makes a ton of sense for website-based apps, it's kind of > >> > another kettle of fish for locally-hosted apps (desktop and mobile). > >> > Moving to OAuth-only is problematic for us for these reasons: > > >> > 1. it complicates (and confuses) the process for users: instead of > >> > entering a username and password -- a well-understood, common process > >> > -- now the app has to push the user to a web site which hopefully > >> > explains what's going on decently. This works okay for web dorks like > >> > us, but I guarantee your avg user is going to find this confusing. > >> > Maybe not as confusing as OpenID, though. > > >> > 2. updating locally-hosted apps to use a new authentication system is > >> > an issue of getting thousands (or higher orders) of users to upgrade. > >> > 6 months may not be enough, even for currently active applications. > >> > Stuff in development *cough*like mine*cough* now could find themselves > >> > having to toss out a ton of code they're knee-deep in right now. > >> > Yucky. > > >> > My preference would be to *not* see HTTP Basic Auth go away in the > >> > foreseeable future. If that's not reasonable or possible, the 6-month > >> > window (even given that the "countdown" may not start for a few > >> > months) is pretty tight for comfort, and extending it would be much > >> > preferred. > > >> > Note: One might wonder why I only mention these issues in the context > >> > of local apps rather than web apps. I think the expectations and user > >> > behavior tendencies are fairly different in the desktop and mobile app > >> > space, and there are a number of ways malware is detected and > >> > contained in this area. The web app space is a lot more open and easy > >> > to exploit, and likely will be unless the whole paradigm changes. > > >> > -- > >> > Ed Finkler > >> >http://funkatron.com > >> > AIM: funka7ron > >> > ICQ: 3922133 > >> > Skype: funka7ron > > >> > On Feb 4, 10:03 pm, Cameron Kaiser<spec...@floodgap.com> wrote: > > >> >> I'm still (softly) repeating the hope that this will be extended, even > >> >> if > >> >> the Basic Auth API remains deprecated and static. An OAuth workflow is > >> >> constrained for desktop apps, and for apps that aren't or can't use a > >> >> web > >> >> browser (in my case, text-mode twitter clients; other cases include all > >> >> those > >> >> little curl scripts posting monitoring information, task status, etc.), > >> >> OAuth > >> >> won't work at all. > > >> >> I fully support OAuth, but where appropriate. I think Ed Finkler said it > >> >> best when he said the breadth of Twitter applications currently extant > >> >> wouldn't exist were it not for a low barrier to entry. OAuth makes sense > >> >> in many places, but it doesn't make sense everywhere, and I hope > >> >> alternate > >> >> methods of authentication remain possible even if they are intentionally > >> >> limited to steer preferred traffic to an OAuth workflow. Otherwise I > >> >> suspect > >> >> the ecosystem "outside the browser" will be greatly reduced. > > >> >> -- > >> >> ------------------------------------ > >> >> personal:http://www.cameronkaiser.com/-- > >> >> Cameron Kaiser * Floodgap Systems > >> >> *www.floodgap.com*ckai...@floodgap.com > >> >> -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones > >> >> ----------- > > >> -- > >> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > --http://stut.net/
