At this year’s Macworld conference, the guys at Rogue Amoeba decided to do what many trade show exhibitors do: give away a free demo CD to interested attendees. But recognizing the conventional drawback of these demos, that they are obsolete from almost the minute the disc is burned, they invested in developing a clever application that runs from the disc, and conveniently presents the latest copies of all of their software to the user. If what’s on the disc is still fresh, the user runs it. Otherwise, the latest version is downloaded from the web and that’s what the user sees instead.

I spoke to them about their solution at the time, and was impressed by it. It certainly seemed like a good way to avoid turning those thousands of plastic discs into guaranteed landfill fodder. But what’s even cooler is that they’ve now decided to share the technology so that other companies who are interested can pull of the same feat with a minimum of work:

Announcing LiveDiscKit

It’s also worth reading to near the end of the article, where they confess that even with the clever technology in place, the discs did not turn out to be all that effective as marketing tools:

Of the 5,000 discs we gave out, 5.8% were ever used. That may seem a bit low, but it gets quite depressing when converted to an absolute count: 288. Out of 5000 CDs given out, no more than 300 were used – perhaps giving away CDs isn’t the best idea after all

Well, you can’t win them all! On the bright side, I don’t think they would have been able to gather this information without putting in the effort to make the discs smart enough to “check for updates.” It was a valiant effort, and a very cool idea that other companies might still find useful.

The WordPress developers have decided that, starting with WordPress 2.6, access to the XMLRPC and AtomPub-based remote publishing interfaces will be disabled by default. Users who wish to use a remote client such as MarsEdit will have to go out of their way to enable the required functionality in their blog’s settings.

There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.

But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.

First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.

Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.

WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

A Real Solution

If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.

In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.

If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.

Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.

If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.

If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.

I’ve just updated my Black Ink crossword solving app to version 1.1, bringing a dramatically improved printout quality, and a host of other small improvements:

Black Ink 1.1

• Dramatically improved puzzle printing quality
• Improved highlighting of active clue in clue list
• Fix for crashing scenario when migrating preferences to a new Mac
• Improved reliability of puzzle downloads
• Fix some bugs with timer restarting after pausing
• Updated default puzzle sources
  • New: Boston Globe Sunday
  • New: Little Rock Daily Record
  • Removed: Washington Post Sunday

It turns out printing is one of those features you can really start to obsess on. I am very happy with the improvements that have been made for 1.1, but just getting under the hood and having my hands dirty has taught me so much about how it can be improved even more.

Exactly what has gotten better with printing? For starters, the application does a better job of remembering your printing options (selectable from the Page Setup dialog). But the real joy is in the improved quality of the paper (or PDF) printouts you generate. The output is now much sharper and closer to “typesetting quality.” Finally, the layout of the clues list has been revised to offer more readable, flowing text that fills the width of the page more naturally.

For future updates, I’m looking forward to offering further refinements. At the top of my list is a preference for “handedness,” so you can print the puzzle grid at the appropriate side of the clues for your preferred solving hand. I also hope to increase the flexibility of clue and grid sizing, so that users with better or worse vision can get the most out of the printout feature.

Enjoy, and please let me know what you think!

Update: Round version numbers are boring, right? If you already downloaded 1.1 be sure to grab the 1.1.1 update which fixes a really annoying issue with the very printing improvements I’ve highlighted here. In the hubbub of getting these new features in, I neglected to notice that for users who haven’t been incrementally using my private beta builds, the printing options would have been set to unfortunate default settings, which caused a nearly blank printout page :)

Many thanks to David Brown for spotting this and letting me know in the comments below.

Manton and I are still at it. We’ve heard the feedback, some of it lukewarm, some of it intentionally discouraging, but most of it extremely enthusiastic.

We’re proud to announce the immediate availability of episode 3, where we talk about WWDC, MobileMe, iPhone 3G, and a bunch of relatively unrelated stuff.

Check us out!