Reinstate 'from app' for Basic Auth desktop apps until OAuth is fixed

[SM]

I'd like for Twitter to reinstate granting 'from app' links for
desktop apps that use Basic Auth.

As it stands, developers who have relatively new desktop apps are
penalized by having updates from their app say 'from web'. Older Basic
Auth desktop clients continue to enjoy a link back to the client web
site with a 'from app' link.

This link is an important way for an app to get noticed. The policy
regarding this link should be applied uniformly to all developers who
make Twitter clients.

I understand Twitter is trying to force people to use OAuth, but that
won't happen in a meaningful way until OAuth is reliable, has a truly
usable workflow (PIN method isn't it), and can work well with other
services (Twitpic, yfrog, etc). We aren't there yet.

New apps that benefit Twitter by expanding the Twitter ecosystem are
being unfairly penalized for using an authentication method that
actually works well and is used by the majority of apps available.

Please apply the policy regarding the 'from' link uniformly. Please
reinstate it for desktop Basic Auth apps until it's possible for
everyone to transition to OAuth in a way that makes sense.

Thank you.

Sanjay
itsyapp (at) gmail
http://mowglii.com/itsy

[Raffi Krikorian]

As it stands, developers who have relatively new desktop apps are
penalized by having updates from their app say 'from web'. Older Basic
Auth desktop clients continue to enjoy a link back to the client web
site with a 'from app' link.

... 

 

I understand Twitter is trying to force people to use OAuth, but that
won't happen in a meaningful way until OAuth is reliable, has a truly
usable workflow (PIN method isn't it), and can work well with other
services (Twitpic, yfrog, etc). We aren't there yet.

i'm trying to gather use cases around OAuth to help it make sense for more people to use it -- as it stands, we are not going to allow the source parameter to be set in new applications unless they come from OAuth.  so, please help me out!

is the reliability of OAuth an actual concern?  do you have a suggestion as to what you would like to see other than the PIN workflow?  additionally, we're actively working on a "delegation" method for integration with other services.

 

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[M. Edward (Ed) Borasky]

I'm doing desktop apps and I think the PIN workflow is just fine as
is. If there are security reasons why something else is needed, I can
see changing it. But it's no big deal for me to fire up a browser,
push the "allow" button, double-click on a PIN, and then CTL-C / CTL-
SHIFT-V into a Konsole window. ;-)

[András Bártházi]

Hi,

What about this?
  http://code.google.com/p/twitter-api/issues/detail?id=1233

I'm not interested in passwords at all, but it's not possible using oAuth for the streaming API. You have suggested mixing the streaming API and REST API for providing the best experience for users, but this way I have no choice but using username/password authentication to be able to use the streaming API.

Bye,
  Andras

[SM]

Hi Raffi,

What is the reason for no longer allowing the source parameter for
Basic Auth desktop apps?

The issue is this: The policy is blatantly unfair. The current policy
benefits some desktop apps that use Basic Auth while penalizing
others. The policy should either remove the source parameter from all
Basic Auth desktop apps or allow it for all. It's unfair and hurts a
subset of devs while benefiting another subset.

I can't believe there is still debate about whether the PIN workflow
for *desktop* apps is better from a usability standpoint than simply
using username/password. I'm looking forward to the adoption of the
new browserless api that exchanges username/password for an access
token.

In addition, as you stated, you are currently working on a delegation
method for integration with other apps. Since it isn't available yet,
how can you penalize devs for not adopting it?

In many ways, the Twitter api and documentation are quite nice. But
this is one area where the company has gone far astray. This arbitrary
and unfair policy feels punitive and ham-handed compared with the many
well thought out aspects of the Twitter api.

For my app, I've had many feature requests including people wanting
their tweets to say 'from Itsy' rather than 'from web'. They don't
understand why some apps do this and some don't. I've had exactly zero
people asking for OAuth or anything like it. No one wants a more
convoluted login procedure. They do want new apps to work like
Tweetie, Twitterrific and the many other apps they are used to.

Please reinstate the source parameter for Basic Auth desktop apps
until OAuth for desktop is fully ready and a reasonable transition
period has elapsed.

The policy should be uniformly applied so that it's fair. Not allowing
the source parameter isn't going to coerce devs who have thought
through the legitimate issues with Twitter's current incomplete OAuth
implementation. It just creates a situation where users and devs are
hurt due to an arbitrary and unfair policy.

Thank you.

Sanjay
itsyapp (at) gmail
http://mowglii.com/itsy

On Jan 11, 11:01 pm, Raffi Krikorian <ra...@twitter.com> wrote:

[Raffi Krikorian]

What is the reason for no longer allowing the source parameter for
Basic Auth desktop apps?

the ability to "forge" the source parameter is too easy when simply using basic auth.

[Isaiah Carew]

The OAuth discussion and call for uses cases has been asked for before by the API team.  

Specifically 11 months ago by Alex.  Here's the link to that discussion:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/655a8425e1e5e045?show_docid=655a8425e1e5e045

It's a good thread that deserves reading as it has contributions from Loren, Blaine, Chris Messina, and Alex.  It's pretty much the who's who of desktop/auth/twitter-api.  Many of the things that people have put in this thread are some of the same things that were discussed then.

Also note that Alex specifically asked for the the community to set up a Wiki about this topic to collect feedback:

http://groups.google.com/group/twitter-development-talk/msg/afda4fdf52f78fe3?dmode=source

Loren did that and here it is:

http://twitter.pbworks.com/oauth-desktop-discussion

Just thought I'd post it to this discussion in case someone forgot.

isaiah

http://twitter.com/isaiah

[SM]

> > What is the reason for no longer allowing the source parameter for
> > Basic Auth desktop apps?
>
> the ability to "forge" the source parameter is too easy when simply using
> basic auth.

Hi Raffi,

Why not disallow it for all apps then? Would the users of Tweetie,
Twitterrific, etc like that? Would the devs? This reason doesn't seem
to make any sense.

The issue is about applying a rule fairly and uniformly to all devs.
This issue hasn't been addressed. The currently policy hurts devs and
users who reasonably choose not to adopt a system that that doesn't
work well yet.

None of the issues I brought up have been addressed.

As Twitter matures, how you treat the devs and users who make your
ecosystem successful will be increasingly important.

Please reinstate the source parameter so that all devs and users are
treated equally. It doesn't cost Twitter much (anything?) to do the
right thing here.

Thanks,

Sanjay

[SM]

Hi Raffi,

If that is the reason for disallowing the source param, why is this
policy not being applied uniformly? How would users of Tweetie,
Twitterrific, etc. feel if all their updates now said 'from web'? How
would the developers of those apps feel?

You've stated yourself that issues with OAuth are being worked on. So
why are you hurting a subset of developers and users who aren't using
a system that isn't ready to be used? At the same time, you are
benefiting another subset that made the same reasonable decision?

Twitter is now a mature, massively funded corporation. The way you
treat your developer and user ecosystem and handle situations in which
corporate policy is uneven and unfair will matter more. This is one of
those situations.

Please do the right (and easy) thing and reinstate the source param so
that all developers and users are treated equally. It is simply a
matter of fairness.

Thanks,

Sanjay

[Raffi Krikorian]

If that is the reason for disallowing the source param, why is this
policy not being applied uniformly? How would users of Tweetie,
Twitterrific, etc. feel if all their updates now said 'from web'? How
would the developers of those apps feel?

those applications have been grandfathered in -- requiring oauth to set the source parameter applies to newer applications.

[SM]

Obviously they've been grandfathered in, but you haven't addressed the
fact that the policy makes no sense and simply hurts developers and
users who are using the *only system that currently fully works*.

It's clearly a policy intended to coerce devs into Twitter's
incomplete OAuth implementation for the sole benefit of Twitter, Inc.

I can see this is going no where and says a lot about how Twitter
operates now.

[Dewald Pretorius]

Raffi,

As I have noted before, the reliability of OAuth is an actual concern.
Also the availability of that easy one-time migration method (getting
the OAuth stuff when you have the username and password).

Twitter OAuth is still in beta. Ryan said that migration to OAuth will
become mandatory this year. That cannot be done until you move Twitter
OAuth into stable production mode. If you do not have the necessary
confidence in your OAuth implementation to do that, then you cannot
force anyone to use it.

[ryan alford]

I've been using OAuth for more than 3 months now, about 8 hours a day during the week while at work, using my own library and my own twitter client.  I've never had an issue with stability.  Now the desktop implementation is crappy(been posted about 50 billion times), but other than that, I've never run into issues with OAuth.

Now I don't use search or streaming, though I don't even know if those use OAuth.

Is there a specific stability issue?  

Ryan

[M. Edward (Ed) Borasky]

On Jan 13, 1:52 pm, ryan alford <ryanalford...@gmail.com> wrote:
> I've been using OAuth for more than 3 months now, about 8 hours a day during
> the week while at work, using my own library and my own twitter client.
>  I've never had an issue with stability.  Now the desktop implementation is
> crappy(been posted about 50 billion times), but other than that, I've never
> run into issues with OAuth.
>
> Now I don't use search or streaming, though I don't even know if those use
> OAuth.
>
> Is there a specific stability issue?
>
> Ryan

It seems to be stable here. I've ported all my desktop apps to oAuth
without any problems. I've said this before, but I'll repeat it - I
don't see why people are complaining about the desktop "PIN workflow".

--
M. Edward (Ed) Borasky
http://borasky-research.net/smart-at-znmeb

"I've always regarded nature as the clothing of God." ~Alan Hovhaness

[Tim Haines]

On Thu, Jan 14, 2010 at 10:52 AM, ryan alford <ryanal...@gmail.com> wrote:

I've been using OAuth for more than 3 months now, about 8 hours a day during the week while at work, using my own library and my own twitter client.  I've never had an issue with stability.  Now the desktop implementation is crappy(been posted about 50 billion times), but other than that, I've never run into issues with OAuth.

Now I don't use search or streaming, though I don't even know if those use OAuth.

Is there a specific stability issue?  

Ryan

I've found it just as stable as the rest of the API.  It's not perfect, but is generally pretty good.  My main concern is that I'd like the mobile pages to be formatted for mobile devices.

Oh - and the ability to delegate between apps.  Sooo looking forward to that.

Tim.

[ryan alford]

I agree.  I believe OAuth for mobile and the delegation between apps are the biggest concerns that need to be addressed before the depreciation of basic oauth in June.  Both of these have been beaten to a pulp.  However, these issues certainly do not push OAuth into an unstable beta state that couldn't be used in production apps.

Ryan

Sent from my DROID

On Jan 13, 2010 5:46 PM, "Tim Haines" <tmha...@gmail.com> wrote:

On Thu, Jan 14, 2010 at 10:52 AM, ryan alford <ryanal...@gmail.com> wrote: > > I've been using O...

[Josh Roesslein]

Not sure I agree with twitter discission to give the current
applications a break, yet force new apps to conform. Come on its been
like 6 months, pull the plug already and stop babying these old apps.
So new apps should have to deal with the headaches, while these guys
get to sit back and relax until things cool down?? Heh.

>> the ability to "forge" the source parameter is too easy when simply using basic auth.

That's a pretty lame excuse. Desktop apps using oauth are just as
susceptible to this as basic apps. You must distribute your consumer
credentials with the app. A hacker can strip these and use them for
forging. So OAuth provides no protection there.
Only safety to be had with oauth is with server based apps that can
keep their credentials safe.

Josh

[Proxdeveloper]

As an User Experience designer, It is more complicated for first time
users as the process
is longer, I mean think about it what's more simple than open the app,
enter username/password
Done!, rather than open the app, go to twitter, sign in, copy pin,
paste pin, Done!, I believe the fewer
steps in the process is better.

On Jan 13, 4:37 pm, "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
> On Jan 13, 1:52 pm, ryan alford <ryanalford...@gmail.com> wrote:
>
> > I've been using OAuth for more than 3 months now, about 8 hours a day during
> > the week while at work, using my own library and my own twitter client.
> >  I've never had an issue with stability.  Now the desktop implementation is
> > crappy(been posted about 50 billion times), but other than that, I've never
> > run into issues with OAuth.
>
> > Now I don't use search or streaming, though I don't even know if those use
> > OAuth.
>
> > Is there a specific stability issue?
>
> > Ryan
>
> It seems to be stable here. I've ported all my desktop apps to oAuth
> without any problems. I've said this before, but I'll repeat it - I
> don't see why people are complaining about the desktop "PIN workflow".
>
> --

> M. Edward (Ed) Boraskyhttp://borasky-research.net/smart-at-znmeb

[Proxdeveloper]

As an User Experience designer, It is more complicated for first time
users as the process
is longer, I mean think about it what's more simple than open the app,
enter username/password
Done!, rather than open the app, go to twitter, sign in, copy pin,
paste pin, Done!, I believe the fewer
steps in the process is better.

I think there's no point for this OAuth method, there are thousands of
apps out there using the basic
Auth system.