Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will?
In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. JD On Thu, Feb 5, 2009 at 12:02 PM, jstrellner <jstrell...@urltrends.com>wrote: > > Stuart , > > In my first reply to this subject, I indicated that it could be a paid > model for them, and I still think it could. > > Either way, I see them needing to use a key of some sort for desktop > applications. Twitter would still need to be involved though, if you > want to prevent sharing of said key and you want the user to be able > to revoke it. > > -Joel > > On Feb 5, 11:48 am, Stuart <stut...@gmail.com> wrote: > > 2009/2/5 jstrellner <jstrell...@urltrends.com>: > > > > > > > > > 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. > > > > For a free service? Not very likely. It would be prohibitively > > expensive for Twitter to implement something where they underwrite a > > trust relationship between users and application developers. If > > application developers had to pay for it then maybe there is scope for > > that to be put in place, but doing so would exclude the vast majority > > of devs working with the API. > > > > Personally I'd vote for users being able to manually request a token > > which they then provide to the application. That effectively bypasses > > the OAuth authorisation mechanism while still providing many of the > > same benefits. Each key would need to be tied to the application in > > some way so it couldn't be shared, but I'm sure there's a solution in > > there somewhere. > > > > -Stuart > > > > > > > > > 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/ >
