Source parameter request for mobile Twitter app ignored (and issues with Twitter's policy toward oAuth on mobile/desktop)

[Aral Balkan]

Dear Twitter peeps,

I sent you an email 13 days ago to ask for a source parameter/token for the mobile Twitter app that I'm developing for the iPhone. Since that time I've had no response whatsoever to my email (which I'm including at the end of this one). Not even a auto-response to say, "hey, we got your email – we'll get back to you" or even, "no way, Jose!"  

I really don't understand Twitter's current strategy toward mobile and desktop apps. Are you guys actually _trying_ to say to developers: "don't build new mobile/desktop apps because you won't be able to compete with existing ones?"

What I mean by that is this: Existing desktop and mobile apps do _not_ have to use oAuth _and_ get to keep their source parameter. The source parameter is probably the best means of organic marketing a Twitter app could have. OTOH, since these apps aren't using oAuth they don't have to worry about giving their apps a UX handicap (try setting up multiple Twitter accounts in a mobile/desktop app with oAuth, or using picture upload services and delegating your token... there are problems that haven't been solved yet.) 

Even though oAuth is not ready for mobile/desktop, Twitter is penalizing mobile/desktop applications that don't use it for UX reasons by not letting them take advantage of the organic marketing provided by the source parameter.

I find this hugely unfair.

As I stated in my original email, I will not sacrifice the UX of the app I literally slaved over every pixel on due to this misguided policy.

I would _really_ love it if someone from Twitter could look into this. The message you are currently giving to mobile/desktop app developers is that they shouldn't bother creating new Twitter apps because they will either have a UX or marketing disadvantage when compared to existing apps. Something tells me that's not the message you are trying to send out. 

I'm finishing off my app today and I'm hoping to submit it to the App Store tomorrow. It would _really_ make my day if someone could get back to me on this (hopefully with a token that I can use to set the source parameter). 

It _is_ a really nifty little app and I really feel you guys are going to love it. It is an app, furthermore, that could really benefit from having the source parameter set. 

I apologize if any of ranting comes off as too strong: it's just that I'm _really_ anal when it comes to the UX of the apps that I build. :) 

All the best,

Aral

PS. Really excited about Chirp + hope to see some of you there! :) 

* * *

Original email, sent 13 days ago, follows:

Hi guys,

I've got a new iPhone app – one that I think you guys will find quite original and fun – that I need to register the source parameter for. However, my app doesn't use oAuth. 

As I stated earlier, it's a _mobile_ app. And currently oAuth on mobile is a user experience nightmare and I've been slaving over the UX of this app to the point where I will not diminish it by implementing oAuth. I don't think it does my app or Twitter any favors to do so.

Mobile and desktop apps are not the same as web apps. They run in a trusted context (the user's mobile phone or PC) and the decision to trust the app or not is made when the app is installed. If the app is malicious, the user has far worse issues to worry about than what it's going to do with their Twitter username and password (e.g., a desktop app could format their hard-drive, etc.) I really feel that punishing mobile and desktop app developers like this for not implementing a system that works like a charm on the web but isn't suited to mobile/desktop is unjust.

I'm very excited about this new app and I really hope that I can register the source parameter for it even though I have made a UX decision to not use oAuth for it. I'm sure you'll agree when you see it that it is an app that will cause quite a bit of interest and the source parameter will not only benefit me but users who want to find the app that the tweets were authored in.

Thank you for your time and I hope I'll hear from you soon.

All the best,

Aral

--

Aral Balkan

http://aralbalkan.com

http://twitterformats.org

http://osflash.org

http://avitapp.com

[Raffi Krikorian]

hey aral.

sorry you didn't get an e-mail back yet!  however, like it has been mentioned before on the mailing list, documented on the faq on our wiki, etc., we're unfortunately not allowing new registrations of source parameters.  sorry.

it too has been all over the list, but i'm actively taking comments, etc. on how we can try to improve the oauth experience - just drop me a line personally.

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

[Aral Balkan]

Raffi,

Would you mind engaging me on this part of my email: 

I really don't understand Twitter's current strategy toward mobile and desktop apps. Are you guys actually _trying_ to say to developers: "don't build new mobile/desktop apps because you won't be able to compete with existing ones?"

What I mean by that is this: Existing desktop and mobile apps do _not_ have to use oAuth _and_ get to keep their source parameter. The source parameter is probably the best means of organic marketing a Twitter app could have. OTOH, since these apps aren't using oAuth they don't have to worry about giving their apps a UX handicap (try setting up multiple Twitter accounts in a mobile/desktop app with oAuth, or using picture upload services and delegating your token... there are problems that haven't been solved yet.) 

Even though oAuth is not ready for mobile/desktop, Twitter is penalizing mobile/desktop applications that don't use it for UX reasons by not letting them take advantage of the organic marketing provided by the source parameter.

I find this hugely unfair.

I would really love to have a comment on from you guys for the blog post I'm writing: is Twitter actively discouraging the creation of new mobile and desktop apps?

Personally, I am _not_ going to implement oAuth in my mobile app. This is not because I lack the skills to do so or an understanding of exactly how oAuth works and what it brings to the table. It's because I will not sacrifice the UX of my iPhone application by sending people to a barely legible, unusable, and not-optimized-for-iPhone oAuth page on Twitter.com as part of their flow (the other objections I listed – which are harder to tackle than making a mobile-friendly version of the oAuth page, which I cannot believe Twitter still hasn't done – do not apply to my application.)

Sending a user to Twitter's oAuth page after having slaved over every pixel in your iPhone app is like giving someone a ride in a Ferrari and then throwing them in a mud puddle before pulling them back in for the remainder of their ride.

I _really_ hope you can reconsider this as I see no logic whatsoever behind this policy. 

Regardless, my app goes to Apple tomorrow; source parameter or no.

All the best,

Aral

[Dewald Pretorius]

Aral,

Not sure how in-depth you've been following developments and
announcements of the Twitter API, but come this June you will have no
choice but to put ScotchGuard on your Ferrari's seats. In other words,
come June timeframe, usage of OAuth will become mandatory and Basic
Auth will be deprecated.

I'm sure Twitter is working on a more seamless mobile experience for
their OAuth implementation. A lot of folks have already thrown their
penalty flags onto the playing field over that issue.

Dewald

[Aral Balkan]

Thanks for the additional info, Dewald, I appreciate it. I haven't been following very closely since my app only really uses a tiny bit of the Twitter API.

From the recent @twitterapi tweets, it's clear that Twitter is working on oAuth WRAP (which is a great step forward) and I'm sure they're working on making the flow as easy as possible. My gripe is that none of that is ready _right now_. My app gets submitted to Apple tomorrow and – unless there's some miracle – will get submitted without the source parameter token. This policy is going to hurt my app and the reason is because I won't compromise on UX given the _current state_ of Twitter's mobile oAuth experience.

I _know_, given the nature of my app, that not having the source parameter _will_ hurt its sales. It just feels unfair.

I also can't understand how Ev Williamis cool with all this given his recent quotes on how important user experience is ("User Experience is everything"). I agree with Ev. This policy doesn't.

Aral

[scott.a...@googlemail.com]

No two ways about it oAuth on desktop's sucks and I imagan it's even worse on mobiles.

Twitter can add new source prams to their database for non-oAuth users however when I tryed they where unable to do so.

I'm currently developing a different .net desktop app (think Hootsuite for desktops) and am useing oAuth, and makeing it clear just why the user has to enter a PIN number into a textbox.

The way I figure it if we developers explain to our users why the login sucks maybe they will pester twitter for us, and since a social network (like twitter) lives or dies by it's users then that will force their hand...

Well I can hope...

Sent using BlackBerry® from Orange

---

From: Aral Balkan <aralb...@gmail.com>

Date: Mon, 1 Feb 2010 20:29:18 +0000

To: <twitter-deve...@googlegroups.com>

Subject: Re: [twitter-dev] Source parameter request for mobile Twitter app ignored (and issues with Twitter's policy toward oAuth on mobile/desktop)

Raffi,

Would you mind engaging me on this part of my email: 

I really don't understand Twitter's current strategy toward mobile and desktop apps. Are you guys actually_trying_ to say to developers: "don't build new mobile/desktop apps because you won't be able to compete with existing ones?"

What I mean by that is this: Existing desktop and mobile apps do_not_ have to use oAuth_and_ get to keep their source parameter. The source parameter is probably the best means of organic marketing a Twitter app could have. OTOH, since these apps aren't using oAuth they don't have to worry about giving their apps a UX handicap (try setting up multiple Twitter accounts in a mobile/desktop app with oAuth, or using picture upload services and delegating your token... there are problems that haven't been solved yet.) 

Even though oAuth is not ready for mobile/desktop, Twitter is penalizing mobile/desktop applications that don't use it for UX reasons by not letting them take advantage of the organic marketing provided by the source parameter.

I find this hugely unfair.

I would really love to have a comment on from you guys for the blog post I'm writing: is Twitter actively discouraging the creation of new mobile and desktop apps?

Personally, I am_not_ going to implement oAuth in my mobile app. This is not because I lack the skills to do so or an understanding of exactly how oAuth works and what it brings to the table. It's because I will not sacrifice the UX of my iPhone application by sending people to a barely legible, unusable, and not-optimized-for-iPhone oAuth page on Twitter.com as part of their flow (the other objections I listed – which are harder to tackle than making a mobile-friendly version of the oAuth page, which I cannot believe Twitter still hasn't done – do not apply to my application.)

Sending a user to Twitter's oAuth page after having slaved over every pixel in your iPhone app is like giving someone a ride in a Ferrari and then throwing them in a mud puddle before pulling them back in for the remainder of their ride.

I_really_ hope you can reconsider this as I see no logic whatsoever behind this policy. 

Regardless, my app goes to Apple tomorrow; source parameter or no.

All the best,

Aral

On Mon, Feb 1, 2010 at 8:14 PM, Raffi Krikorian <ra...@twitter.com> wrote:

hey aral.

sorry you didn't get an e-mail back yet!  however, like it has been mentioned before on the mailing list, documented on the faq on our wiki, etc., we're unfortunately not allowing new registrations of source parameters.  sorry.

it too has been all over the list, but i'm actively taking comments, etc. on how we can try to improve the oauth experience - just drop me a line personally.

On Mon, Feb 1, 2010 at 12:04 PM, Aral Balkan <aralb...@gmail.com> wrote:

Dear Twitter peeps,

I sent you an email 13 days ago to ask for a source parameter/token for the mobile Twitter app that I'm developing for the iPhone. Since that time I've had no response whatsoever to my email (which I'm including at the end of this one). Not even a auto-response to say, "hey, we got your email – we'll get back to you" or even, "no way, Jose!"  

I really don't understand Twitter's current strategy toward mobile and desktop apps. Are you guys actually_trying_ to say to developers: "don't build new mobile/desktop apps because you won't be able to compete with existing ones?"

What I mean by that is this: Existing desktop and mobile apps do_not_ have to use oAuth_and_ get to keep their source parameter. The source parameter is probably the best means of organic marketing a Twitter app could have. OTOH, since these apps aren't using oAuth they don't have to worry about giving their apps a UX handicap (try setting up multiple Twitter accounts in a mobile/desktop app with oAuth, or using picture upload services and delegating your token... there are problems that haven't been solved yet.) 

Even though oAuth is not ready for mobile/desktop, Twitter is penalizing mobile/desktop applications that don't use it for UX reasons by not letting them take advantage of the organic marketing provided by the source parameter.

I find this hugely unfair.

As I stated in my original email, I will not sacrifice the UX of the app I literally slaved over every pixel on due to this misguided policy.

I would_really_ love it if someone from Twitter could look into this. The message you are currently giving to mobile/desktop app developers is that they shouldn't bother creating new Twitter apps because they will either have a UX or marketing disadvantage when compared to existing apps. Something tells me that's not the message you are trying to send out. 

I'm finishing off my app today and I'm hoping to submit it to the App Store tomorrow. It would_really_ make my day if someone could get back to me on this (hopefully with a token that I can use to set the source parameter). 

It_is_ a really nifty little app and I really feel you guys are going to love it. It is an app, furthermore, that could really benefit from having the source parameter set. 

I apologize if any of ranting comes off as too strong: it's just that I'm_really_ anal when it comes to the UX of the apps that I build. :) 

All the best,

Aral

PS. Really excited about Chirp + hope to see some of you there! :) 

* * *

Original email, sent 13 days ago, follows:

Hi guys,

I've got a new iPhone app – one that I think you guys will find quite original and fun – that I need to register the source parameter for. However, my app doesn't use oAuth. 

As I stated earlier, it's a_mobile_ app. And currently oAuth on mobile is a user experience nightmare and I've been slaving over the UX of this app to the point where I will not diminish it by implementing oAuth. I don't think it does my app or Twitter any favors to do so.

Mobile and desktop apps are not the same as web apps. They run in a trusted context (the user's mobile phone or PC) and the decision to trust the app or not is made when the app is installed. If the app is malicious, the user has far worse issues to worry about than what it's going to do with their Twitter username and password (e.g., a desktop app could format their hard-drive, etc.) I really feel that punishing mobile and desktop app developers like this for not implementing a system that works like a charm on the web but isn't suited to mobile/desktop is unjust.

I'm very excited about this new app and I really hope that I can register the source parameter for it even though I have made a UX decision to not use oAuth for it. I'm sure you'll agree when you see it that it is an app that will cause quite a bit of interest and the source parameter will not only benefit me but users who want to find the app that the tweets were authored in.

Thank you for your time and I hope I'll hear from you soon.

All the best,

Aral

--

Aral Balkan

http://aralbalkan.com

http://twitterformats.org

http://osflash.org

http://avitapp.com

[Aral Balkan]

(And, of course, I meant to write "Ev Williams is" – way to make a
poignant closing remark!) :P

[Dave Sherohman]

On Mon, Feb 01, 2010 at 08:29:18PM +0000, Aral Balkan wrote:
> I would really love to have a comment on from you guys for the blog post I'm
> writing: is Twitter actively discouraging the creation of new mobile and
> desktop apps?

I'm not Raffi. I don't even work for Twitter. But I am very confident
that the purpose of their policy regarding source params has nothing to
do with penalizing anyone or actively discouraging the creation of new
applications.

> I _really_ hope you can reconsider this as I see no logic whatsoever behind
> this policy.

The logic is very simple:

OAuth provides Twitter with the ability to identify the sending
application.

Basic Auth does not.

Therefore, Basic Auth source params are easily forged, allowing apps to
trivially impersonate each other, which is clearly undesirable.

(Unfortunately, this logic is not watertight, in that desktop/mobile
apps are vulnerable to having their OAuth keys extracted from them, in
which case they could still be impersonated, but that's the reasoning
I've seen given previously for the policy.)

--
Dave Sherohman

[Aral Balkan]

Here's an idea: let's reverse engineer the top desktop and mobile
Twitter apps and use their oAuth keys to... Oh, wait, my bad: the top
desktop/mobile apps _don't_ use oAuth and boy will they take a UX
beating when they start.

But one day... :)

oAuth for desktop and mobile: making security through obscurity fun
again.

Aral

Sent from my iPhone

[Raffi Krikorian]

Here's an idea: let's reverse engineer the top desktop and mobile Twitter apps and use their oAuth keys to... Oh, wait, my bad: the top desktop/mobile apps _don't_ use oAuth and boy will they take a UX beating when they start.

But one day... :)

maybe call me naive, but i for one, am not convinced the oauth experience has to suck.

as mentioned before, i'm really open to having a discussion on how to make the oauth UX better.  many people have already, and i encourage others to just drop me a line if you have ideas...

[John Meyer]

On 2/2/2010 5:31 AM, Raffi Krikorian wrote:
> Here's an idea: let's reverse engineer the top desktop and mobile
> Twitter apps and use their oAuth keys to... Oh, wait, my bad: the
> top desktop/mobile apps _don't_ use oAuth and boy will they take a
> UX beating when they start.
>
> But one day... :)
>
>
> maybe call me naive, but i for one, am not convinced the oauth
> experience has to suck.
>
> as mentioned before, i'm really open to having a discussion on how to
> make the oauth UX better. many people have already, and i encourage
> others to just drop me a line if you have ideas...
>

Given the large number of Twitter desktop clients out there, and I have
yet to see one on a mass scale that uses oAuth yet, is the depreciation
of Basic auth going to go off when planned?

[Kevin Marshall]

Really, on Twitter's side, the oAuth bits of the process are just a
couple of variations of forms...so why not just let each application
define templates for those forms (and just give details on what fields
are required to be there and what placeholders need to be present so
Twitter can replace the values in-line as needed when displaying the
template)....

This would let anyone/everyone design a look and feel that fit best
with their application (and therefore becomes less confusing for the
average end user too)..but doesn't actually change the oauth flow at
all...

It ads a bit of processing and storage to Twitter's side of
things...but otherwise, I think it would appease most people ;-)

- Kevin

[Aral Balkan]

Hi Raffi,

maybe call me naive, but i for one, am not convinced the oauth experience has to suck.

as mentioned before, i'm really open to having a discussion on how to make the oauth UX better.  many people have already, and i encourage others to just drop me a line if you have ideas...

I think you're missing the issue here. It's not whether or not oAuth has to suck in the future for desktop/mobile apps. It's that oAuth sucks _today_ for desktop/mobile apps. And _today_ matters because it's today that Twitter is penalizing new desktop and mobile apps that don't use oAuth by withholding the source parameter (and thus the best form of organic marketing possible for a Twitter app) from them.

So, yes, please let's keep on working on making oAuth better but, here's the key thing: do not punish mobile and desktop developers today for not using the current half-baked and solution that oAuth represents for desktop and mobile apps.

My app is not going to sell as well because I cannot get the source parameter because I will not use a technology that is not ready for prime time on my mobile app. 

This is not fair. 

Talking about oAuth, getting suggestions, etc., is great. In the meanwhile, please stop punishing new mobile/desktop apps and creating a terribly uneven playing field with existing apps that can continue to integrate different Twitter-related services seamlessly and take advantage of the organic marketing that the source parameter provides without using oAuth.

Your call for an open discussion would be great under different circumstances, but, in the face of the current penalty that that my app has to live with, it just feels like a slap in the face. 

Aral 

[Ed Costello]

On Feb 2, 2010, at 8:14 AM, Aral Balkan wrote:

> My app is not going to sell as well because I cannot get the source
> parameter because I will not use a technology that is not ready for
> prime time on my mobile app.

You’re complaining that your app will not sell well because the
twitter API, which you use for free, will not provide you with a
blessed source parameter? I think there are other problems with your
business plan than whether or not you can convince the API guys to
choose horribly-bad-security over inconvenient-and-not-really-
practical-for-desktop-but-there-you-go security.

Look, twitter have made a business decision to kill basic auth. Basic
Auth has been the source of numerous attacks on twitter’s users which,
because of the way it works and psychology it promotes, twitter have
no serious way to prevent.

Criticize oAuth, sure. Suggest improvements to the experience,
certainly. Find, document and demonstrate alternatives that are at
least as good if not better than oAuth, fantastic. But continuing to
beat up the API guys here is unlikely to win you support or alter
twitter’s API to suit your business needs.

--
-ed costello

[Cameron Kaiser]

> Given the large number of Twitter desktop clients out there, and I have
> yet to see one on a mass scale that uses oAuth yet, is the depreciation
> of Basic auth going to go off when planned?

Indeed. I know I'm waiting for the browser-less API before I make an
OAuth TTYtter.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- This message will self-destruct in five seconds. Good luck, Jim. -- M:I ----

[Cameron Kaiser]

> Really, on Twitter's side, the oAuth bits of the process are just a
> couple of variations of forms...so why not just let each application
> define templates for those forms (and just give details on what fields
> are required to be there and what placeholders need to be present so
> Twitter can replace the values in-line as needed when displaying the
> template)....
>
> This would let anyone/everyone design a look and feel that fit best
> with their application (and therefore becomes less confusing for the
> average end user too)..but doesn't actually change the oauth flow at
> all...
>
> It ads a bit of processing and storage to Twitter's side of
> things...but otherwise, I think it would appease most people ;-)

This certainly has possibilities. The page could reference a style sheet
and images on the app's "home" server to reduce the impact on Twitter's
network, but still be 'served' by Twitter.

Combined with the "subkeys" suggestion Josh made, this would cover most
of my personal concerns about OAuth.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Flat text is just *never* what you want. -- stephen p spackman -------------

[Dewald Pretorius]

Leveling the playing field is "elephant in the room" easy:

Immediately ignore the source parameter on all Basic Auth calls. Right
now. It's a 5-second coding job.

If Tweetie, TweetDeck, et al want their app name back in the tweets,
sure, they can have it by all means. As soon as they've converted
their apps over to OAuth.

[Isaiah Carew]

Leveling the playing field is "elephant in the room" easy:

Immediately ignore the source parameter on all Basic Auth calls. Right
now. It's a 5-second coding job.

Twitter has announced plans (see @ev's announcement in Dec.) to do almost exactly that come June.  Not quite instant gratification, but June is sooner than you think.

But two big questions remain:

1.  Will Twitter add OAuth additions that allow for alternative credential exchange?  (in plain English:  username/password on desktop) Raffi has hinted at this previously (source: details ), but few details have emerged.

2.  Will Twitter overlook less-than-perfect implementations that improve UX?  (i.e. screen scraping the PIN, internal browsers, etc.)  So far these practices seem to be flying under the radar in a few clients, but will that change when the big guys enter the game?

We'll know the answers in June.  It should be fun to watch and make for some lively forum threads.  Bring popcorn and stand clear of the flames.  ;-)

isaiah

http://twitter.com/isaiah

[M. Edward (Ed) Borasky]

Actually, we'll know the answers at Chirp or before. Chirp is the
watershed for Twitter and the developer ecosystem. Time as we know it
will be reckoned B.C. (Before Chirp) and A.D. (After Disclosures). ;-)

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

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

[Abraham Williams]

Aral,

What about the OAuth process do you see as sucking? And please answer with two assumptions: 1) the environment is the iPhone and 2) the Twitter OAuth page is optimized for mobile experiences.

Abraham

--
Abraham Williams | Community Advocate | http://abrah.am
Project | Out Loud | http://outloud.labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Seattle, WA, United States

[Isaiah Carew]

How so?  What do you think will be the significance of chirp for desktop OAuth?  Was there an announcement that I missed?

isaiah

http://twitter.com/isaiah

[M. Edward (Ed) Borasky]

There's a whole chunk of the hacking session devoted to oAuth.