Jumat, November 24, 2017
Text Size

Search

Update Berita

SSL to secure from hacker attacks

Open-source software developer Kai Engert has proposed an overhaul to the Internet's SSL...

Cara Menghemat Bandwidth Internet, mempercepat browsing

Ada situasi ketika menggunakan internet kita harus benar-benar hemat dengan penggunaan bandwidth ...

Istana Merespons Aksi 313 Berhentikan Ahok

Juru Bicara Presiden Joko Widodo, Johan Budi Sapto Pribowo menegaskan, Presiden Jokowi sangat...

Twitter Bakal Sediakan Layanan Berbayar?

KOMPAS.com - Setelah selama ini hanya meyediakan layanan gratis yang didukung iklan, Twitter...

Megawati: Ahok, Sudahlah Jangan Cerewet

.   Kompas.com - Megawati menasihati Ahok agar tidak terlalu banyak bicara. Mengingat kondi...

Butuh kеrjа? Cоbа cеk di Jооblе

Butuh kеrjа? Cоbа cеk di Jооblе.       Pаdа zаmаn yаng sаngаt k...

  • Tips mengatasi bosen dalam pekerjaan

    Kamis, 01 November 2012 07:48
  • Grunt Mars probe stranded in Earth orbit

    Kamis, 10 November 2011 09:40
  • SSL to secure from hacker attacks

    Senin, 27 Februari 2012 21:09
  • Cara Menghemat Bandwidth Internet, mempercepat browsing

    Minggu, 23 September 2012 18:03
  • Istana Merespons Aksi 313 Berhentikan Ahok

    Kamis, 30 Maret 2017 19:45
  • Twitter Bakal Sediakan Layanan Berbayar?

    Kamis, 30 Maret 2017 19:49
  • Megawati: Ahok, Sudahlah Jangan Cerewet

    Kamis, 30 Maret 2017 19:54
  • Butuh kеrjа? Cоbа cеk di Jооblе

    Kamis, 30 Maret 2017 20:09
Internet Friendly Twitter permission change hurts third-party mobile apps
SocialTwist Tell-a-Friend

Twitter permission change hurts third-party mobile apps

Penilaian Pengunjung: / 0
KurangTerbaik 

Twitter is updating its authentication system to give users more control over how third-party applications can access their accounts. Applications will now have to explicitly request additional permission from the user during the authentication process in order to send and receive direct messages on behalf of the user.

At first glance, the change seems like a welcome improvement to the Twitter APIs. Support for granular permission tiers is one of the technical advantages of authority delegation systems like OAuth. There are also already a number of other social networking services—particularly Facebook—that use tiered permissions in a similar manner. Despite the potential advantages for the end user, Twitter's approach to implementing the feature comes with some serious problems for third-party client implementors.

A brief explanation of OAuth

The OAuth standard was originally intended to enable server-to-server authentication for limited third-party access to non-public APIs. It is poorly suited for open APIs with an arbitrary number of independent third-party applications. More significantly, it doesn't address the needs of desktop and mobile authentication at all. Despite the significant limitations of the standard, it is being adopted and mandated by a number of social networking services, including Twitter.

The OAuth authentication process must be carried out in a Web browser and involves a series of redirects: a third-party site sends the user to the Twitter website to log in and approve access and then Twitter redirects the user back to the initiating third-party site and appends a token that the third-party site can extract and use to identify the user to Twitter. The advantage of this system is that the third-party site never gets the user's actual password, just a revokeble token.

The obvious problem with this system is that the redirect dance doesn't work for native non-web applications. The OAuth standard defines a separate flow for those situations. Instead of using redirection, the user gets a link to copy and paste into their browser to start the authentication process on Twitter's website. After authentication is completed on the Web, Twitter will spit out a pin number that the user has to manually copy and paste into the application.

The pin system poses some enormous technical and usability challenges for application developers, especially on mobile and embedded systems where multitasking and copy/paste features aren't available. Some developers choose instead to embed an HTML renderer in the application and then scrape the pin out during the authentication process. Even that is problematic on many different levels.

Twitter addressed the issue by implementing xAuth, an OAuth variant for native applications. In the xAuth authentication process, the user simply types in their username and password and then the application relays those to Twitter and gets back a revokeable authentication token. This made it possible to have the same security advantages—because the application does't have to retain the user's login credentials or send it on subsequent requests—but it offers the usability advantages of conventional logins. Twitter individually vets the applications that use xAuth and doesn't make xAuth-enabled keys freely available through an automated system.

Unfortunately, it looks like xAuth—and the Twitter applications that rely on it—are getting thrown under the bus by Twitter as part of the new round of authentication system changes.

How the changes will impact xAuth

The new granular permission system will only work with the Web-based OAuth authorization flow, which means that it won't be accessible to third-party Twitter applications that rely on xAuth. Such applications will have to either be rewritten to use a Web-based authentication flow with exceptionally poor usability or they will have to forgo the use of direct message APIs.

On top of that, every single user of every single third-party Twitter application will have to go through the authentication process again in order to continue using direct messaging functionality. Rather than grandfathering in applications that have access to direct messages today, Twitter is going to universally revoke access to the feature for third-party clients and make users explicitly grant it through the new permission system.

Twitter initially intended to make the transition on June 1—which would have made it impossible for the vast majority of third-party mobile Twitter applications to be updated and go through various mobile app store approval processes. Applications that can't be updated in time would end up showing authentication errors when users try to access their direct messages.

In summary, Twitter is: 1) making the authentication system that it has traditionally endorsed for native applications untenable for use by actual Twitter clients, 2) is going to force all users of third-party Twitter clients to reauthorize the applications they use, and 3) is refusing to give third-party developers enough time to adapt their applications to accommodate these changes.

Unsurprisingly, the response from the third-party developer community has not been positive. Responses range from frustrated confusion to anger. In response to the overwhelmingly negative feedback from developers regarding the June 1 deadline, Twitter has pushed it back out to June 14—which will still probably not be enough in some cases.

Adding insult to injury, Twitter's own first-party client applications will be exempt from the new policy. What this means is that Twitter alone will be able to use xAuth for fully-featured mobile client applications. This move will significantly expand the artificial advantage that Twitter's own client applications have over third-party alternatives.

A few months ago, Twitter issued a statement publicly discouraging third-party developers from building Twitter clients. The company made it clear that it wants complete control over the Twitter client experience and that the longtime supporters who made Twitter accessible on a diverse number of platforms are no longer wanted.

That campaign to disenfranchise third-party developers started shortly after a controversy erupted regarding undesirable user interface changes in Twitter's own native iPhone application. Twitter clearly felt threatened by the ease with which users were able to switch to alternative clients when Twitter tried to inject intrusive ad-like elements in its own application.

The recent changes to the permission system are being touted by Twitter as a security improvement, but it's just an attempt to spin perception and obscure the blatantly anti-competitive and developer-hostile underpinnings of the transition. The current xAuth-enabled applications have been individually vetted by Twiter and are all native programs that users deliberately installed on their devices to use as Twitter clients—with the knowledge that the application would have access to their direct messages. As such, there isn't really any logic to Twitter's handling of these applications from a technical or security perspective.

Many third-party Twitter client developers posted a message in the Twitter developer discussion group to voice objections to the changes, but the following is one that I think best captures the essence of the situation:

"Users do not need protection from their personal mobile Twitter clients any more than they do from their browsers. It's their app running on their device accessing their account at their direction. Requiring separate authentication for DMs for a mobile client app is like requiring separate cars keys for ignition, gas pedal, and breaks. Millions of mobile Twitter users are going to get really ticked off when they can no longer use their favorite apps. So let's be honest. When it comes to Twitter mobile clients, this isn't about user security. It's about pruning client competition from the market."

What happens now?

The bottom line is that Twitter doesn't want to compete with third-party client applications. They created open APIs in order to see what kind of innovations other developers could produce by using Twitter as a platform. Now that they have seen what works and what doesn't, they are going to gradually elbow out the third party developers and take control of the whole ecosystem themselves.

Twitter is probably taking this opportunity to cut the legs out from under xAuth in order to disrupt the growing popularity of some prominent third-party iOS clients, such as TapBot's much-praised Tweetbot.

If Twitter succeeds in bullying all of the third-party client developers out of the market, it is going to be a major loss for users who have benefited from the availability of diverse third-party clients. It is going to be especially problematic on platforms where Twitter doesn't provide its own client.

In the short term, it means that users who don't run Twitter's own applications are going to get a seriously suboptimal authentication user experience after the transition. Applications that can't be updated in time will appear to be broken because they will be unable to access direct message functionality. It's going to be enough of a pain point for some users that it will likely serve to encourage adoption of Twitter's own clients.

Comments
Add New Search
Write comment
Name:
Email:
 
Website:
Title:
 
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch:
:(:shock::X:side::):P:unsure::woohoo::huh::whistle:;):s
:!::?::idea::arrow:
 
Please input the anti-spam code that you can read in the image.

3.25 Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved."

Advertisement Site




Ads - World Friend

Ads - World Friend

Berita lain-lainnya

Tablet Bakal Jadi Hits Dengan 9 Keunggulan
03/02/2010 | Indra Febria Widy
article thumbnail

  Apple Tablet kabarnya segera dirilis. Produk teranyar dengan kemungkinan nama iSlate atau iPad ini diproyeksi akan langsung meledak di pasaran dengan sembilan alasan. Apa saja?

Seperti d [ ... ]


lighttpd
03/11/2009 |
article thumbnail

Kembali pada bulan Februari 2003 saya (Jan) telah menyelesaikan tesis. Writing a thesis is as far as I can say the most frustrating job you can do. Menulis tesis adalah sebagai Sejauh yang saya dapat  [ ... ]