It’s been two months since Tumblr surprised me by suddenly dropping support for MarsEdit and countless other clients that connect to their service using a previously approved technique with their 1.0 API. This reduced MarsEdit’s functionality to posting only, eliminating the ability to download and edit existing posts. Two weeks ago, they finished the job, by dropping support completely for the 1.0 API. MarsEdit ceased functioning with Tumblr completely.

I’ve been spending a good portion of the past two months reorganizing MarsEdit so that it can accommodate all the new requirements of Tumblr’s API changes. It’s not all “wasted on Tumblr,” so to speak. I’ll gain benefits from having robust OAuth authentication support, for example. In fact, I’m already reusing that support for Flickr’s new preference to authenticate with OAuth. But it’s been an unwanted, unexpected shift of my priorities, and I’ll be glad when it’s over.

It’s almost over.

I’ll be honest: there were times along this latest sprint to support Tumblr when I thought of throwing in the towel. Why should I continue to shed proverbial sweat and tears for a service that has shown little concern for me? I’m not doing it for Tumblr, I’m doing it for my users. I sold MarsEdit to many, many people who rely upon it to connect to and edit their Tumblr blogs. It’s within my power to restore that functionality, so that is what I feel compelled to do.

On a side note: although Tumblr as a company has shown disdain for its API clients, I have recently received great support from one of their employees, John Bunting, who responds fairly diligently to developers on the Tumblr API Google group. He doesn’t always have great news to share, but he often does what he can to help.

I’m finishing up MarsEdit 3.5.6, which will restore support for Tumblr. While I was in there I was able to shore up a couple other long-standing shortcomings with MarsEdit’s Tumblr support: you can now edit completely private blogs and private posts, and MarsEdit now works around a Tumblr API behavior where editing a post would always change the publish date to now.

If you are interested in trying out the latest changes before 3.5.6 officially ships, I would be pleased to have some sanity checks on the fixes that are in place. Some folks have already been testing a previous beta release, but this one should be even more solid and full of goodness.

Click to Download MarsEdit 3.5.6b3

Let me know how it goes, and thanks for your patience while I worked out the various issues that were preventing me from adopting Tumblr’s latest API.
 

Gus Mueller of Flying Meat is a good friend who, for a short time, even worked on MarsEdit. Much to my chagrin, Gus doesn’t actually use MarsEdit for editing his own blogs. When I’ve asked him why, he explains that he’s too tied to a particular setup involving VoodooPad, his desktop wiki app.

To make things worse, he’s finally made his blogging solution public! You can read all about static publishing with VoodooPad on the Flying Meat site. There goes the neighborhood.

Although MarsEdit supports static publishing, I have to confess it’s pretty minimal compared to the support for hosted blog services such as WordPress and Blogger. MarsEdit support is all built around the old “Blosxom” publishing convention. If you’re interested, Dan Weeks has a good write-up about how he used this support to connect MarsEdit with Octopress.

Although static publishing isn’t a top priority for MarsEdit today, I’ll be considering enhancements that would give more flexibility and power to these setups. In the mean time if MarsEdit doesn’t fit your needs, I strongly encourage you to check out Gus’s new stuff in VoodooPad!

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.