{"id":8562,"date":"2010-12-01T17:58:50","date_gmt":"2010-12-02T00:58:50","guid":{"rendered":"http:\/\/blog.wapreview.com\/?p=8562"},"modified":"2010-12-01T17:58:50","modified_gmt":"2010-12-02T00:58:50","slug":"twitter-mobile-webapp-and-browser-oauth-scorecard","status":"publish","type":"post","link":"https:\/\/wapreview.com\/8562\/","title":{"rendered":"Twitter Mobile WebApp and Browser OAuth Scorecard"},"content":{"rendered":"
<\/p>\n
It’s been three months since the “OAuthcalypse” when Twitter started requiring that third party apps use OAuth<\/a> to access the Twitter APIs.<\/p>\n OAuth is generally a good thing, as it means you no longer have to share your Twitter credentials with every app that wants to access Twitter on your behalf, greatly reducing the risk that a rouge app might start spamming or posting malicious tweets in your name. Apps can still misuse\u00a0 your Twitter account but if one does\u00a0 you can easily revoke its access to Twitter at twitter.com\/settings\/connections<\/a> without having to change your Twitter password.<\/p>\n The switchover apparently caused quite a bit of pain for mobile web and app developers. OAuth seems to be a rather cumbersome protocol involving multiple redirection and rather long URLs and cookies; all things that\u00a0 mobile browsers, especially legacy WAP ones, are noted for having issues with.<\/p>\n It’s been three months now, hopefully enough time for things to have shake out, so I tried a bunch of third party mobile web based\u00a0 Twitter clients in several mobile browsers to see how they fared. The results were generally pretty good, as shown in the chart. A yes in a column means that the app was able to navigate through OAuth and the user could fully use the webapp.\u00a0 With all the reasonably modern browsers most of the mobile Twitter sites worked.<\/p>\n
Site<\/td>\n | Android 2.1<\/td>\n | N95 Symbian Browser<\/td>\n | Bolt 2.31<\/td>\n | Opera Mini 5.1<\/td>\n | UC Browser 7.4 Java<\/td>\n | Openwave 7.0<\/td>\n<\/tr>\n |
Dabr<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no**<\/td>\n<\/tr>\n |
Tweete<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n |
Tuitwit<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n | no***<\/td>\n<\/tr>\n |
Twitter<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n |
Twittme<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n |
Tweetgo<\/td>\n | yes<\/td>\n | no*<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n |
Halo<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n |
Slandr<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n |
Twitstat<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | yes<\/td>\n | no<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n * OAuth succeeded but Tweetgo hung displaying “Loading…” where the Tweets should appear in the Symbian browser.<\/em> There were some usability issues.\u00a0 The proxy based browsers, Opera Mini, Bolt and the UC Browser, don’t support meta -refresh, which Twitter uses to re-direct the browser back to the client app after authentication is complete. The browser would\u00a0 hang\u00a0 on the “redirecting you back to <name of app” screen indefinitely.\u00a0 There is a work around, the name of the client on that screen is a link, clicking it takes you back to the calling app and it passes the authentication token. That’s not particularly intuitive and there’s nothing on Twitter’s screen that tells the user to do that. Meta refresh is not treally he best way\u00a0 to redirect mobile browsers. I don’t see any reason why Twitter couldn’t use an HTTP redirect, which is much more reliable.<\/p>\n The Openwave browser was the only one that had serious trouble with all the mobile Twitter clients.\u00a0 It couldn’t handle the complexity of the OAuth hand-offs failing with a variety of errors including “Infinite redirect loop”, Invalid certificate chain received and “Twitter auth failed”.<\/p>\n Openwave is a bit of a ringer in this test, a 2004 era browser that is hopelessly outdated in the modern mobile world. But there are still millions of phones in use today around the world that come with Openwave pre-installed, including several current model handsets\u00a0 from Sprint and Verizon in the US.\u00a0\u00a0 It’s also found on many of the phones available on the BoostMobile and Virgin prepaid plans that come with unlimited Internet.<\/p>\n Should Twitter and mobile web developers go to the trouble of supporting such an old and crippled browser? That’s a hard question to answer. I can’t image legacy browser users drive much advertising revenue to the sites that support them, they certainly don’t to mine. But I still get a fair among traffic on wapreview.com, boostapps.com and especially yeswap.com from Openwave and other legacy browsers like the Motorola Internet Browser and the slightly more capable Netfront, S40 and Obigo embedded browsers.<\/p>\n Before the switch to OAuth, Dabr, Tweete, Twitter Mobile and possibly some of the other Twitter sites did work with the Openwave browser and now none of them do.\u00a0 Twitter users are safer today because of OAuth and I don’t suggest getting rid of it. But I can’t help but wonder if a little fine tuning by Twitter and third party Twitter webapp developers couldn’t get\u00a0 OAuth working with it.<\/p>\n","protected":false},"excerpt":{"rendered":" It’s been three months since the “OAuthcalypse” when Twitter started requiring that third party apps use OAuth to access the Twitter APIs. OAuth is generally a good thing, as it means you no longer have to share your Twitter credentials with every app that wants to access Twitter on your behalf, greatly reducing the risk that a rouge app might start spamming or posting malicious tweets in your name. Apps can still misuse\u00a0 your Twitter account but if one does\u00a0 … Continue reading |