Twitter Gets Strict with Official API v1.1 Release

Twitter has officially released version 1.1 of its API. Initially announced in August, the updated API has stricter authentication policies and developer rules of the road, among other new features.

Twitter Toughens Up

In version 1.1, Twitter is requiring applications to authenticate all of their requests with the API. Twitter says this step will prevent abusive behavior and help it to further understand how categories of applications are using the API so it can better meet the needs of developers.

At this time, all authentication requires user context, but in the coming weeks Twitter says it will release support for a form of authentication not requiring a user context.

Twitter also updated its developer rules of the road, placing regulations against activities such as publishing private user information, resyndicating data and performing “surprise” actions not initiated by users. And all applications replicating the core Twitter experience, usually called "clients," will have some new restrictions placed on them, including a 100,000 user token limit.

There are also new display requirements (which were previously suggested guidelines), dictating things like display of the tweet author avatar and how text is displayed. Other changes include support for JSON only, discontinuing support for XML, Atom and RSS, which Twitter says are “infrequently” used.

Rate limits in version 1.1 of the API are divided into 15 minute intervals, which is a change from the 60 minute blocks in version 1.0. Additionally, all 1.1 endpoints require authentication, so no longer will there be a concept of unauthenticated calls and rate limits. Search will be rate limited at 180 queries per 15 minute window for the time being, but Twitter says it may adjust that over time. According to Twitter, developers will “now be able to query the API on a per endpoint basis a lot more than (they) previously could.” 

Show Me the Money

Although Twitter is stressing that the new changes will help eliminate abuses and make Twitter app development a more structured and orderly process, not all observers are convinced its motives are entirely pure. Last month, CMSWire columnist Stephen Fishman wrote that,

Twitter really does not care whether (solo developers) make money. Twitter cares whether Twitter makes money. In order for Twitter to make money, Twitter needs consumers to engage with Twitter on the Twitter site as much as possible. Twitter's value prop to developers is a free, functional and highly available micro-bloging platform that can easily be integrated into your site.”

Fishman also said the new API is directly aimed at “data scrapers” whose primary goal is to extract Twitter data for their own benefit.

Resyndication Rules Could Cause Problems

According to Mashabale Tech, new restrictions on resyndicating data appear to mean that information contained within a tweet — such as a URL — cannot be sent to another service using a third-party client. Mashable says this “could be problematic for social news aggregators such as paper.li, Postano and RebelMouse” and “have a much larger impact on the entire Twitter ecosystem,” including mainstream applications as well as third-party developers and power users.

Ultimately, Twitter is probably in a position to enact whatever API rules it likes and ride out any developer backlash. As Fishman states in his article, “If (Twitter’s value proposition) is not good enough, build and market your own platform and see how much money that makes you.”

 

 

Source : cmswire[dot]com

Dropbox Tests Two-Factor Authentication

Following a well-publicized security breach that was discovered last month, document sharing service Dropbox is launching a beta test of two-factor authentication with some users. The new security feature, made available on Friday, August 24 to early Dropbox adopters using Windows, Mac OS X, or Linux PC, sends users a one-time mobile security code they must enter in addition to their standard password.

Early Results Suggest Two-Factor Authentication Has Kinks

As reported by Information Week, two-factor authentication has already been previewed by Dropbox VP of Engineering Aditya Agarwal. It comes as a response to the discovery that spam being sent to user email accounts only used for Dropbox originated from hackers who had stolen passwords they had reused from other sites (see more detail below). In addition, an internal Dropbox investigation revealed that hackers stole unencrypted user passwords that were improperly stored in a Dropbox employee’s account.

Dropbox users can receive mobile security codes via text message or mobile app. Information Week reports that early public commentary on the beta test suggests it needs some fine-tuning. For example, one user posted in an online Dropbox forum that despite signing up for two-factor authentication, he could still log into his Dropbox account only using his password.

Another complaint posted online by more than one user is that currently there is no backup option if a mobile phone or the 16-digit mobile security code is lost.

Two-Factor Authentication One of Several Promised Security Fixes

In a public statement on its website, Dropbox previously said it would start requiring two-factor identification. In addition, Dropbox pledged to offer security fixes including a new page that will let users see all logins to their account, and possibly periodically ask users to change their passwords. Internally, Dropbox intends to add automated mechanisms for detecting suspicious activity.

Obviously, it will take some time for Dropbox to launch fully operational versions of all these new and improved security features (and internal features may not be publicized), but considering how quickly the company rolled out a beta test of two-factor authentication, Dropbox seems committed to rectifying the problems caused by this embarrassing security breach.

Dropbox users themselves should also take some steps to help protect not just their Dropbox accounts, but all of their various online accounts. The IT Security Office at Duke University offers some helpful tips on how to select a strong password that will not be easy for a hacker to guess. These include using at least eight characters (some systems allow up to 63), mixing upper and lower-case characters, interspersing punctuation marks and symbols, and using modified versions of words from favorite childhood nursery rhymes or foods. Duke IT Security also advises to never use the same password on more than one account and to avoid dictionary words, phone numbers and anything associated with a name.

 

 

Source : cmswire[dot]com

A Little Birdie Told me Twitter was Doing Product Strategy via API

Late last week, Twitter announced a series of API changes that it plans to launch in the upcoming weeks. The changes covered several different areas including changes to authentication requirements, changes to number of calls an end-point can make to Twitter in an hour (both up and down) and creating a series of binding agreements that developers and applications must adhere to. While the API will be released shortly, developers will have a migration period of 6 months before the old API is retired.

We Are The Knights Who Say Tweet!

While the individual changes themselves are indeed interesting, the fun stuff lies just beyond the surface in what the changes mean to both Twitter's business strategy and to its overall approach to product strategy and development as well. These changes are not random demands for "shrubberies" but rather a fully acknowledged attempt to encourage and discourage specific partner and developer behaviors when integrating with and leveraging Twitter's platform. In other words, Twitter has fully embraced the idea that its API is a product to be designed for a specific set of consumers along with a specific strategy in mind (something predicted in these pages earlier this year).

Twitter is still in the throes of figuring out how to fully monetize its immensely popular micro-blogging platform and has made these changes with an eye towards furthering its profitability goals. By throttling smaller apps and unleashing larger ones, twitter has furthered its ability to charge enterprise media partners for access to the firehose of tweets in search results and also for trending topics.

The authentication, partnering and rate limiting changes will directly go after data scrapers in two ways (also predicted in these pages earlier this year):

1. The lower rate limit (more than five times less than its current amount) will make it harder to do mass scraping and will force any programmatic scrapers to identify themselves with a license key.
2. The upper rate limit (just over twice the currently supported amount) will give scrapers a legitimate opportunity to abandon scraping and legitimize their use of twitter data.

No One Expects The Twitter Inquisition!

Another big shift is Twitter's move from display guidelines to display requirements along with a certification requirement for certain Twitter apps. Twitter will now require its developers to adhere to a specific set of rules to standardize appearance and functionality. Twitter has justified this change by citing that it will give a better, and more standard, interface to its end users and has reserved the right to revoke license keys from any non-conformists. Some developers have cried foul citing that this will limit the individual Twitter-client developers ability to differentiate their user experience and their overall ability to make money. Well duh! Twitter basically said that in its blog post by specifically saying that it was trying to discourage developers from making new differentiated client apps for consumers.

In case it is not obvious to the solo developer community, Twitter really does not care whether you make money. Twitter cares whether Twitter makes money. In order for Twitter to make money, Twitter needs consumers to engage with Twitter on the Twitter site as much as possible. Twitter's value prop to developers is a free, functional and highly available micro-bloging platform that can easily be integrated into your site. If that is not good enough, build and market your own platform and see how much money that makes you.

 

Continue reading this article:

1 2 Next Page >

 

 

Source : cmswire[dot]com

Twitter Tightens API Rules: Increases Authentication, Decreases Requests Per Hour

Twitter plans to release version 1.1 of the Twitter API in the coming weeks, and it involves a number of new user restrictions. Changes will include required authentication on every API endpoint, a new per-endpoint rate-limiting methodology, and tighter “Developer Rules of the Road,” especially around applications that are traditional Twitter clients.

Seeking Authenticity

In version 1.0 of the Twitter API developers have access to certain API endpoints without requiring their applications to authenticate, essentially enabling them to access public information from the Twitter API without Twitter knowing who they are other than their IP addresses. To prevent what Twitter calls “malicious” use of the Twitter API and to gain an understanding of what types of applications are accessing the API, in version 1.1 the company will require every request to the API to be authenticated.

For developers who are already using OAuth when making API requests, Twitter says all authentication tokens will transition seamlessly from v1.0 to v1.1. If an application is currently using the Twitter API without using OAuth, developers will need to update it before March 2013.

Rate-Limiting Endpoints

Twitter will cut the number of authenticated requests applications can make from the current 350 calls per hour to 60 calls per hour per-endpoint. According to Twitter, analysis of current use of its API shows this rate limit “will be well above the needs of most applications built against the Twitter API, while protecting our systems from abusive applications.”

There will also be a set of high-volume endpoints related to Tweet display, profile display, user lookup and user search where applications will be able to make up to 720 calls per hour per endpoint.

The Rules of the Road

Changes to Twitter’s official developer “Rules of the Road” will include a shift from display guidelines to display requirements (such as linking @usernames to the appropriate Twitter profile), requiring developers that are building client applications that are pre-installed on consumer electronics devices to have their application certified by Twitter and requiring developers to work with Twitter directly if they need a large amount of user tokens.

Bloggers Voice Displeasure

In addition to preventing misuse and gaining a better understanding of the API environment, Twitter says its new API guidelines are designed to encourage application development activity in areas such as social CRM, social analytics and social influence ranking, while limiting certain use cases for traditional Twitter cases and syndication.

However, not all observers are quite so positive about these planned changes. Computerworld compiled a list of negative postings from IT bloggers about the changes. Comments included: “[It's] disappointing to see Twitter turning its back on the…community that played such a large role in its…expansion”; “the new requirements…may make it more difficult for third-party clients to differentiate themselves” and a “translation” of Twitter’s “weaselese” that boiled down to “We look forward to forcing you to build a service, then destroy any chance of making money from it.”

Not every blogger was negative, however. One blogger wrote, “I was left thinking a lot of the changes were reasonable and made sense…With concrete rules we can always ensure we are in compliance.” There was a caveat of “My only request to Twitter is that they keep the lines of communication…very open.”

 

Continue reading this article:

1 2 Next Page >

 

 

Source : cmswire[dot]com