One of the developer-hostile aspects to Twitter’s announcement of upcoming changes in the 1.1 release of their API, is the imposition of new “user token limits.” Developers of traditional client applications will be limited to 100K tokens, or twice the number currently issued, for apps that already have more than 100K. What’s a user token? It gives a person like you or who downloads the app the ability to actually connect to and work with our Twitter account data. No token? No service.

Suddenly the total number of users any Twitter client developer can expect to support has a hard limit. Limited resources tend to rise in value, and we’re already seeing that play out in the client market. On a recent episode of Core Intuition, we welcomed Twitterrific developer Craig Hockenberry, who spoke candidly about the changes. During the episode, he pointed out that the ad-supported, “freemium” model adopted by Iconfactory and many other developers, may not survive this transition.

Tapbots, the developers of the popular Tweetbot client, announced today that they have pulled their Tweetbot alpha release for Mac, citing the new user token limitations. While exposure to a large number of users is undoubtedly good for testing and promotional purposes, they don’t anticipate it being worth the potential cost in “lost tokens.”

Matthew Panzarino of The Next Web reported on the Tweetbot news, taking care to emphasize that because user tokens don’t expire on any regular schedule, they can be used up even by users who download a client once, connect, and never launch the app again. The total number of oustanding user tokens doesn’t go down unless users log in to Twitter and explicitly revoke access to the client application.

During our conversation on Core Intuition, I pointed out that Twitter’s new policy runs the risk of invoking Apple’s ire, as well. Apple’s App Stores for Mac and iOS are host to dozens if not hundreds of Twitter API clients, many of which meet Twitter’s criteria for “traditional clients.” When a particular app reaches its 100K token limit, what happens to the user who purchases the app from Apple’s App Store a second later? I suppose it will be up to developers to anticipate their proximity to 100K, and start winding down the operation (and their business) by removing the app from the store, etc. But if they don’t? Apple’s just sold an app that, through no fault of theirs or the developers, is useless for connecting to the service it’s meant to support.

A Token Degree Of Control

It’s bad enough that clients will have to contend with a hard limit of 100K active users per application, but what must be particularly infuriating to developers is the knowledge that some of those 100K tokens may not have been used for years, and may never be used again.

The Tapbots announcement included an overt request that users of any Twitter clients should “help 3rd party developers out” and revoke any tokens that you’re not using. This underscores the doubly subservient position developers have been put in by this move: Twitter imposes a hard limit on the number of user tokens, only end-users can free up previously used tokens, and developers, helpless to address any of this on a meaningful level, are left to suffer the worst of the consequences.

At a minimum, Twitter should support developer-driven token expiration. Google, for example, supports an API endpoint for revoking OAuth 1.0 or 2.0 tokens. This gives developers the ability to improve the user’s experience when revoking a token makes most sense: e.g. if a user has opted to “Uninstall” an application. But it also provides some discretion and flexibility for the developer to revoke in other scenarios where it makes sense. A scenario such as the one Twitter is imposing, for example.

With the ability to programmatically revoke tokens, the particulars of doing so would be up to developers. For example, if I were the developer of a 3rd party client such as Twitterrific or Tweetbot, I might arrange for the client application to communicate token usage data to a centralized server. This would theoretically give me the ability to say “expire any user tokens that haven’t been used within the past year” and rest assured that I’ve freed up a bunch of tokens without inadvertenly inconveniencing an active user.

There are security issues at play here, and the unfortunate potential to seriously inconvenience an active user if a user token is revoked prematurely. But given the hard limits being imposed by Twitter, some hard coping mechanisms are due to developers. Tokens are precious, limited resource, and neither users nor developers can take them for granted any longer.

Today I went to launch VMware 4.1.0 on my OS X 10.8.1 Mac and was met with this surprising refusal to open:

Well, that’s interesting. Mac OS X supports the ability for applications to specify in their “Info.plist” files the minimum system version they require, but as far as I know there are no keys for specifying the maximum system version. Mac OS X will display a similar failure when an application is so old that it doesn’t contain code that was compiled for the appropriate CPU on the computer, but the code in this VMware 4.1.0 executable is 64-bit Intel code that my Mac should be able to run.

Now it so happens that VMware 4.1.0 shipped with a bug that many folks have found convenient. Apple officially forbids the virtualization of Mac OS X “client” operating system releases prior to 10.7. If one was inclined to defy this, then having a copy of 4.1.0 around to run virtual machines would be pretty handy.

Knowing that this version of VMware inadvertently defies Apple’s virtualization policy, and believing that there’s no way for the app to be identifying itself as incompatible with the current version of Mac OS X, I immediately jumped to the conclusion that Apple was “blacklisting” the app for political reasons:

Whoah, did Apple blacklist VMware Fusion 4.1.0 as of 10.8.1? skitch.com/danielpunkass/…

— Daniel Jalkut (@danielpunkass) August 24, 2012

Damn you, Apple! I’ll show you, I’ll just jump into the terminal and run it from the command line. Doing so showed me a very fast, very efficient door to the immediate panicking and restarting of my Mac. Wow, they really don’t want me to open this app!

Upon restarting and reviewing the panic log, I realized the crash was actually related to VMware’s kernel extension. So in all likelihood, the app has an incompatibility with 10.8 and Apple is blocking users from casually opening it as a favor and not as punishment to VMware or its users.

How does this kind of “blacklisting” occur on Mac OS X 10.8? I suppose in the future we might see restrictions that tie in to the new Gatekeeper signing system, but that is of no help if the targeted apps are not signed. The current mechanism is in the form of a crude XML file installed by Apple in your System folder:

/System/Library/CoreServices/CoreTypes.bundle/
	Contents/Resources/Exceptions.plist

Take a look, it’s pretty interesting! In this file you’ll find all manner of policy amendments, all based on the bundle ID of the targeted application. Search the file for a section labeled “MinimumVersionRequirements” and you’ll discover a long list of bundle IDs and corresponding version numbers. When you double-click an app to open it in the Finder, among the other checks the system does, it looks for an entry in this list for the appropriate bundle ID and, if found, only allows the app to launch if its bundle version is the same or higher than the value listed.

In the case of VMware Fusion’s entry, it lists 536017 as the minimum. I don’t have it installed, but I suspect this is the bundle version for VMware 4.1.3, the last officially supported version of VMware 4 on 10.8.

But VMware also earns the distinction of being the only app in the file to take advantage of a keyed value “VersionRange”:

<key>VersionRange</key>
<array>
  <string>683826</string>
  <string>683827</string>
</array>

I don’t know exactly how this is interpreted, but I suspect it’s a range of bundle versions that should be considered incompatible with the system. In this case, I suspect Apple has determined that there is a problem with a specific version of VMware Fusion 5. They can’t set the minimum version to the latest version of VMware without cutting out support for 4.1.3, so the VersionRange technique lets them surgically remove support for this specific version.

Elsewhere in the file you will find other interesting policy amendments, including a long list of apps on which the LSFileQuarantineEnabled flag is explicitly turned on. This flag ensures that whatever files are created by these apps, they should be “quarantined” to cause the default protections e.g. for Gatekeeper policies to be enforced. Not surprisingly, the list of bundle IDs are all web browsers and torrent downloaders. Apple’s using the policy amendment here to say: even if the developers of these apps haven’t taken care to set the LSFileQuarantineEnabled on their own, the system should treat any files created by these apps as if they are “files downloaded from the web” and subject them to greater scrutiny than the files created by other apps.

As Apple becomes increasingly involved in the vetting of which software should be sold to, or allowed to run on customers’ computers, it’s worth considering whether they will be tempted to use these powers for less honorable goals. I would not have been surprised if Apple’s blacklisting here had been for non-technical reasons, but in spite of my initial paranoia, the Exceptions.plist file seems to only contain amendments that are genuinely for the good of users and developers.

It’s common to observe in retrospect that a popular band, television show, clothing style, or even a country has outlived its popularity. We internet hipsters refer to this as jumping the shark, in homage to the popular American television series “Happy Days.”

It’s less common to know when some focus of celebrity is at a precise peak of popularity, poised for a sad, gradual decline into the the oblivion of historical footnotes. I didn’t predict Friendster’s demise until it was obvious, in spite of increasingly poor page-load performance that made it impossible for me, as a fan of the site, to visit it as often as I might have liked. When MySpace was at its peak, it seemed as inevitable as Facebook or Twitter is today. Of course you have a MySpace page, otherwise you don’t exist! When I first got involved in blogging, it was on LiveJournal. Where else would you host a blog?

Relevance on the social internet is fleeting. Facebook, Twitter, Tumblr, WordPress, and Google all know this. They’re among the vanguard for the moment, enjoying the same notoriety that MySpace, LiveJournal and Friendster once cherished.

I’m not enough of a business genius to claim, even in retrospect, to know why each of these former social-internet giants fell. But I am enough of a smart-ass to propose that in every case it was a case of a company losing its way. A company loses its way by diverging from the path its customers expect it to follow. For companies like Friendster and MySpace, that happened arguably by standing still while the needs of customers shifted. In other cases, the customer’s sights are in one direction while the company envisions something completely different.

I have often wondered why some people like Facebook while other people like Twitter, and yet other people seem to favor them equally. I should come out and admit now that I “like” both services, but when it comes down to it, I devote the vast majority of my attention to Twitter. I’m not sure I completely “get” Facebook.

That’s a lie.

I get Facebook, but from where I sit, the selling point for Facebook is to be in touch with all the mundane, everyday things that your friends and family have to share. I love my friends and family, and I do love to keep in touch with their mundane activities. But that’s just it, isn’t it? Facebook is for the mundane. Love it or hate it, and sometimes there is an awful lot to love, Facebook is not in the business of providing a venue for punchy, thought-provoking, elevated banter.

That’s where Twitter comes in. The reason I spend the vast majority of my time reading and interacting with friends, acquaintances, and strangers on Twitter, is because the expectation of quality is high. Twitter, like blogging before it, has been broadly ridiculed as being about “what I ate for breakfast.” But in practice, that’s just not the case. The 140-character limit, and certain cultural expectations among the users I interact with, means that cutting humor, philosophical insight, and up-to-the-minute gossip and news, are to be expected. In short? Twitter has cachet.

Among the reasons for Twitter’s cachet is its distance from the tactics of other social networks. While Facebook relishes in trashing up your timeline with mindless games, polls, and other nonsense that distract from the core content of your followers, Twitter has remained relatively pure. I usually connect to Twitter with a desktop or mobile client, but even when I visit the web site, I’m mostly looking at a long list of things people said. And nothing else.

Twitter’s cachet has earned a lot of goodwill, but also a lot of skepticism about how it intends to sustain itself going forward. From day one, it seems, people have criticized the company for its lack of an obvious business model. Now it seems poised to answer that criticism with a vengeance. It has already locked out former partners such as Facebook and Tumblr, and is cracking down unilaterally on 3rd party apps that aim to offer first-class, full-service interfaces to the service.

As Dan Frommer explained in his Understanding Twitter post, Twitter is in a position where, to keep doing what it’s doing, it needs to hunker down and make money. Fast. Recently its actions have revealed that the way it intends to do that is by 1. Owning the core Twitter user experience and 2. Monetizing the ownership of that experience through ads or other means.

The problem with cachet is it’s easy to maintain when you’re giving, but much harder to maintain while you’re begging. Twitter’s new emphasis on earning money will quiet the criticisms of those who mocked them for lacking a business plan. But for customers who were attracted to the service because of its simplicity, for its elevated tone, or for the apparent disregard for the vulgarities of earning money, forfeiting that precious cachet may be the worst business plan of all.

My sympathies go out to Mat Honan who, as he puts it, “was hacked. Hard.” After exploiting his iCloud account, the attackers took over his Gmail account, and proceeded to remote-wipe the contents of his iPhone, iPad and Mac. He states in his recollection of the tragedy that the compromised Apple ID had a 7-character passphrase, and had remained the same for many years. The relative weakness of the passphrase, combined with the long period of time, presumably gave hackers the opportunity to guess the passphrase by brute-force. I hope we will learn more about the specific details of the attack, because it will help inform how the rest of us can better protect ourselves.

Assuming the weak passphrase was indeed the root of the exploit, the obvious way Mat could have protected himself is by choosing a more sophisticated one. But as Michael Rose of TUAW points out, the increased security brings with it significant costs in day-to-day frustration: the Apple ID passphrase is demanded for many user actions involving Apple’s store and syncing services. The particular difficulty of typing complicated phrases on the iPhone has led some folks to intentionally choose simpler passphrases.

Apple and other tech powerhouses such as Google, Facebook, and Twitter, hold increasingly large amounts of power over not only the information we store on their servers, but on other services, to the extent we’ve granted them the privilege of authenticating our identities. An issue in Mat’s case was that once the hacker had his iCloud email, he or she was able to compromise Gmail by following the “forgotten passphrase” for Gmail. Services such as Twitter that don’t host email face similar vulnerabilities: many services, including but not limited to games, offer to use Twitter authentication to log in. In this situation a compromised Twitter account means all the services you’ve entrusted to Twitter are compromised as well.

One way to protect yourself is by declining to delegate authentication to third parties. When enrolling in a new service that offers Twitter or Facebook authentication, I usually go through the nuisance of creating a new account instead. That way I can choose a unique passphrase, and store that in my keychain. I prefer this to allowing numerous items to be implicitly added to my Twitter or Facebook “keychain.” Don’t put all your eggs in one basket, as they say. (Well, that’s what I’m doing with my keychain, but I am empowered to personally protect it and to back it up as I see fit.)

On my iPhone, I chose an exceedingly difficult passphrase after reading about how relatively easy it is for hackers to brute-force the code in hardware when they possess the device. I also chose a very short, 1 minute lockout period, and opted to let it wipe my data clean after 10 failures. These steps minimize the chances that a thief will be able to access my data. But this is a royal pain in the ass in practice, as I’m constantly required to fumble with my phone, keying in this monstrous phrase.

Apple, and other companies who hold the “keys to the castles,” can help by developing technologies that empower us to apply increasingly strong protections while at also minimizing the day-to-day hassles of a complicated passphrase. For example, I would be happy to use a simple 4-digit passcode that unlocked my phone, if a longer passphrase was demanded after an hour of inactivity. This would allow me to use my phone in confidence that it would be fairly hard to unlock quickly without the passcode, and that a thief would only have an hour to make that happen before the phone entered “strong lockdown” mode.

Apple seems interested in evolving their authentication strategies: they recently acquired AuthenTec, a fingerprint-sensor manufacturer. Will future iPhones allow us to unlock our phones with a simple finger-touch? It would be a nice step forward in usability, but I’m not familiar enough with the technology to know if it’s a step forward in security. Other companies are looking forward, as well. Tim Bray at Google recently announced he’d be pouring his energies into identity technologies. A commonly cited approach is two-factor authentication, which is perhaps a way Apple could apply the fingerprinting technology, combining it with a relatively simple-to-type pin code.

Culturally and technologically, we have certainly come a long way from plain-text passphrases stored in a file, but it’s clear there is a lot more to be done. In the mean time, I’ll just be here fumbling with my phone every other minute, cursing Apple as I bask in a moderate sense of security for having jumped through all these hoops.