Aaron Swartz

I woke to the sad news that Aaron Swartz has died by suicide.

I have been inspired by Aaron’s work and philosophy since 2004, when I started reading his thought-provoking blog. I checked in with him after a few of his more down-spirited posts, and this led to a very loose, occasional friendship by email. Our paths nearly crossed in the Boston area a few times but owing separately to his or my own social anxieties, we never met in person.

Like many successful people, Aaron never seemed to appreciate his own achievements the way others did. After Reddit was acquired by Wired, presumably making him rich, he wrote about his inability to celebrate like his co-founders did, and all but wished it undone.

A piece that will probably get a lot of attention in the wake of his death is his own dramatic post about suicide from 2007, which was originally written auto-biographically. The post elicited responses from many people, including me. I wrote to reassure him, lightly, that many folks would miss him if he left us. He thanked me, and said he was “just having a really bad week.”

Given the combination of challenges Aaron faced, from the inner voices that talked down his successes or criticized his appearance, to the fear of imprisonment for trumped up charges of wire fraud, these “really bad weeks” may have been frequent.

It’s hard to find an appropriate perspective for commemorating somebody who has died so suddenly and so tragically. When suicide is involved, our society tends to look for someone or something to blame, often the victim himself. After witnessing a small extent of the struggles Aaron fought, I choose to commemorate him with gratitude for the many bad weeks when he resisted drastic action, and gave us all more time to appreciate and share his contributions.

Screenshot Lightning

Apple recently changed their policy regarding screenshots for iOS applications in the App Store: you must supply any changes to your screenshots by the time of approval, or the existing screenshots will be locked down until the next time you submit and are approved.

Long story short: you better have those screenshots ready at submission time or very shortly after. And the screenshots had better be something you are willing to live with for a good long while.

This is a dramatic change from the old policy, under which developers could update screenshots at their leisure. This afforded a workflow where a developer might put all of their effort into the actual development of the app, submit it, and then get to work fine-tuning their screenshots for the marketing aspect of selling in the App Store.

One reason for putting off the job of creating screenshots is that creating them is time-consuming and tedious, even with a relatively simple app. For a more complex app, or one that is localized into many languages, the challenge is that much greater.

Last night, at our local Boston CocoaHeads meeting, I learned about a well-timed solution for this problem. Kent Sutherland, the programmer for Flexibits, showed off how he uses an automated screenshot-capture procedure to tame the task of generating Fantastical’s many screenshots, in many languages.

His approach uses a novel technique in which the target app itself is built with customized screen-capturing code compiled right in. Then the app can be driven through the iOS Simulator with WaxSim, a command-line tool for launching the simulator with various options. He was kind enough to share a sample project in which he applies the same technique to Apple’s UICatalog sample app:

Click to download Kent’s UICatalog sample.

After downloading the sample, navigate to the “Screenshots” folder to find the real goodies. The Readme.txt in that folder has simple instructions for kicking off the process. In a nutshell: just open the Screenshots folder in the Terminal, and type “python make_screenshots.py output”. Then watch as the iOS simulator cranks through the process of generating 12 screenshots for UICatalog before you’ve had a chance to wipe that tear of joy from the corner of your eye.

I plan to build more iOS software in the future, and something like this will undoubtedly be a lifesaver when I have significant screenshots to generate. My only existing iOS app, Shush, only has 4 screenshots in one language, and I still found it tedious enough to re-generate screenshots that I hesitated to improve the UI because of the work of another round of, ahem, bitsplitting.

The same approach is also applicable to Mac apps. Currently I go through a similarly tedious procedure of manually navigating and cajoling the app into a specific state before taking a screenshot by hand. This could all be driven by automated capture code built into a custom version of the app, where I could also imagine other niceness such as adding annotations to illustrative screenshots, being added to the process.

If you’re selling apps on the iOS App Store, Apple’s policy change makes it imperative that you come up with a workflow for effortlessly and quickly generating screenshots. Thanks to Kent’s generous sharing of his approach, your work is mostly done for you.

Shame Projection

Marco Arment addresses the common defense among media pirates that lack of a legal alternative has “forced” them into pirating it:

Admit it: you’re ripping it off, it’s morally questionable at best (and illegal), but you don’t care.

A few years ago my wife opened my eyes to the phenomenon of shame projection. In short: assigning blame for your own shortcomings to external circumstances. Now it’s like that thing where you learn a new word and suddenly start noticing it everywhere: our society is swimming in shame projection.

I am no psychologist, nor have I ever taken a psychology class, nor have I even finished the “Psychological Projection” Wikipedia article cited above. So I’m probably completely misguided and wrong about this, but an example that springs to mind is when a motorist almost runs me down, and then screams at me for being in the way.

What happened in the blink of an eye is:

  1. Motorist is cruising along, distracted, late for work, whatever.
  2. I step into the crosswalk, over-confident of my right of way.
  3. Motorist proceeds to within inches of striking me before braking abruptly.
  4. Motorist feels terrified, ashamed, regretful, and then grateful I’m not hurt.
  5. I, nearly killed, glare my visceral outrage at motorist.
  6. Motorist feels offended by my lack of graciousness upon not being killed.
  7. Motorist’s brain seeks unconsciously for directions to project blame.
  8. Upon not finding any reasonable outlet, brain settles on me. Watch where you’re going, you idiot!
  9. Motorist carries on, content that he or she was the victim, not me.

Most folks who pirate media are feeling some of those same terrified, ashamed, regretful, and grateful feelings that the motorist felt upon almost killing me. In the case Marco cites, the projection outlet is on the companies for not making the media available.

This kind of projection seems to have a delightful efficiency. When the media companies do make the media available, the blame will be on their pricing it too high. When the price is right, it’s the media format that’s wrong. If the media format is right, then the DRM is too odious. If DRM is absent, then the authors are making too much money, anyway. If the authors aren’t making much, you’re only pirating to try it out. Once you’ve tried it and like it, you’ll pay for it when you get your next paycheck. You wouldn’t have to pirate at all if your boss wasn’t such a cheapskate and paid you better…

Hacking My AOL Account

When I read Mat Honan’s article today about the relative uselessness of passwords in protecting the security of our various online accounts, I was attracted by his assertion that it’s particularly easy to hack into an AOL account:

Let’s say you’re on AOL. All I need to do is go to the website and supply your name plus maybe the city you were born in, info that’s easy to find in the age of Google. With that, AOL gives me a password reset, and I can log in as you.

Although I have never been an avid AOL user, I do have an AOL Instant Messenger (AIM) account. I figured, and was correct, that for the purposes of this assertion, the accounts are one and the same. I quickly set about hacking my own account, just to see if it was as easy as Honan had described.

After navigating to AOL, I clicked the Login link and then clicked the “Forgot password” link to get to a very friendly, step-by-step process for resetting the password on an account. As Honan predicted, it offered to let me reset my password if I could supply my home town and another piece of personal information such as my birthday. But try as I might, I couldn’t get the right answers, and therefore I couldn’t break into my own account.

You see, I have had a habit for a long time of supplying bogus information when prompted for personal information. Obviously I break this habit when dealing with an institution that legitimately requires it, but I guessed that when I signed up for AIM, I had supplied false information. The nice side-effect of this appeared to be that my account was now less hackable than a typical account.

Of course Honan has had a little more practice than me with this, and when he saw my tweet he was inspired to ask if he could give it a shot. He and I are friends, and I trusted him to do nothing more than test the security of my account, so I agreed. He said it might take a day or two. A few hours later he sent me a screenshot of the AOL page where it was helpfully offering to let him enter a new password for my account.

I simply hadn’t tried diligently enough to get through the ridiculous “security” wizard. In the end it was as simple as knowing that I grew up in Santa Cruz (a value that I had evidently chosen to enter accurately), and that my email address was my last name at “red-sweater.com.” Totally, outstandingly, ridiculously poor security.

I made a video of myself “hacking” my own account, to show just how awful it is. The worst part is AOL will offer a laughably guessable hint about the alternate email address (j****t@red-sweater.com) down one security path, which can then be used to satisfy the secret question answer down another path.

As I said in the video, my best advice for anybody who has an AOL/AIM account is to change every personal detail on the account to something bogus, and to write those values down in an encrypted note somewhere for future reference if it’s needed. An idea I had is to choose as the email address something like “jalkut+fdj29f292935″@red-sweater.com. This way the confirmation email will still get to you if it’s ever needed, but the address will be much harder to guess.

Shame on you, AOL.

The Anti-Apple Market

John Gruber points to Amazon’s willingness to use its valuable home page to antagonize Apple and its fans by deriding the iPad mini in comparison to the Kindle Fire HD:

I’m sure some people will love it; they’re going for the anti-Apple market.

I first learned about Amazon while working at Apple in the mid-1990’s. There was a series of mail-sorting cubby holes in a hall at work, and I remember noticing the Amazon-branded boxes multiply as my colleagues turned on to the dead-simple innovation: a huge selection of books and music delivered to your door for a reasonable price.

Although I was an early, occasional patron of internet commerce, I looked at Amazon with some derision because of a character flaw. For as much as I appreciate and yearn for innovation, I tend to overvalue the status quo. These folks were buying nearly all their books and music online. My internal dialogue judged them as entitled and too lazy to support a local shop. They may well have been, but a few years later, I was shopping at Amazon too.

From the beginning Amazon has shared Apple’s focus on simplification and iterative improvement. Their catalog evolved into the internet’s de facto product review authority. It’s as easy today to buy all your toilet paper from Amazon as it was to buy all your books from them 15 years ago. Amazon CEO Jeff Bezos’s reputation for customer-focused innovation is often compared with Steve Jobs’s mastery of that art.

The company has grown consistently from within but also through judicious acquisition. The companies they buy typically share that quality of providing customers with some product at a level of service that was previously thought infeasible. Zappos sold upscale shoes with an unfathomably generous return policy. The IMDB collected an unprecedented database of information for film buffs. Audible cracked open the market for digital audio books. I made my first CD Now purchase through a terminal connection over telnet! “Amazon companies” are always innovative, and focused primarily on the service of premium customers.

As with Apple, Amazon’s pursuit of premium customers has resulted in a strong appeal to the mass market. I believe that companies like Amazon and Apple have expanded the expectations of the mass market, such that it’s getting easier to market a company based on its unique, premium innovations. The “anti-Apple” market historically pooh-poohs these advantages, reducing the product landscape to a crude, high-level comparison of features and prices. This is what Amazon has done on their home page, comparing the $199 Kindle Fire HD to the $329 iPad mini, while audaciously claiming they offer “Much More for Much Less.”

Since when does Amazon target the anti-Apple market? The companies compete in a growing number of areas including digital music, movies, and eBooks. But Amazon has thrived with this competition largely because it targets the same market that Apple does, while doing some things better than Apple. From the early days when my colleagues were tearing open shipping boxes at Infinite Loop, to the present time when many Mac and iPhone aficionados cling tenaciously to their authentic Amazon Kindles, the pro-Apple market is the pro-Amazon market. Why would a company that has historically aimed so high change its focus to the lower end?

I see this as a rare example of concession on Amazon’s part. Traditionally when the company discovers they are not the best in a market they wish to dominate, they acquire the stunning leader and integrate the advantages. Here they are going up against Apple, which happens to be both the largest company in the world and also the most inimitable hardware designer. Amazon can’t buy it, and Amazon can’t copy it. They must compete on price, and they must confuse on features. They must go anti-Apple, which is a shame for Amazon and a shame for customers, but it’s the only reasonable choice they have.

Fairly Priced

Tapbots released a Mac version of Tweetbot, their popular Twitter client.

I have been beta testing the application for months and have found it to be a suitable replacement for Twitter.app, the once neglected, now abandoned official application.

But folks are talking less about Tweetbot’s features and more about its price: $20. In today’s culture of low-priced apps, anything costing more than a Starbucks latte raises a eyebrows of the suddenly cash-poor masses who shelled out for expensive iPhones and Macs.

A healthy opposition to the price-whiners has risen to the task of preaching the merits of “fairly priced” software: $20 is a relatively small investment for something you use all the time, quality software takes a ton of time and effort, and unless your beloved software can sustain its creators comfortably, you’ll be disappointed when they abandon it or sell it to a multi-national corporation.

I agree with all this “fair pricing” rhetoric, but I can’t help but notice a key point missing within it: Tapbots doesn’t want to charge $20. From their announcement:

Because of Twitter’s recent enforcement of token limits, we only have a limited number of tokens available for Tweetbot for Mac … This limit and our desire to continue to support the app once we sell out is why we’ve priced Tweetbot for Mac a little higher than we’d like.

The culture of low-priced software is artificially pulling the prices of many apps downward, while in this case Twitter, with its API token-limitation policy, is artificially pulling the price upward.

Is $20 a reasonable amount to pay for Tweetbot? I think so. But if Tapbots would have preferred to charge even less, has it been fairly priced? Many folks are seizing on the coincidence of Tapbots needing to charge more as an opportunity to exalt “fair pricing,” when this was a result of coercion in two directions.

With price pulled downward by the expectation of free or ultra-cheap software, and upward by Twitter’s inconsiderate API policies, Tapbots have settled on a stasis point. It’s not as low as they wish it could be, and at the same time not as high as it’s “worth.” If Twitter’s API policies were not a factor, then staking out a bold $20 price would merit applause. But as the developers have settled on the price grudgingly, this is no victory for fair pricing. It’s an opportunity to acknowledge the discomfort of being pulled in two directions and to congratulate Tapbots on making a pragmatic choice. Well done.

Color Inside The Lines

Twitter is buzzing with rumors that Apple is on the verge of acquiring Color Labs, the company that famously raised $40 Million in venture capital before failing to produce anything that resonated with a large number of customers.

The article on The Next Web alludes to the possibility of there being some patent value in Color’s holdings. Interestingly enough, Color has apparently only recently published several patent applications related to sharing of information among “device groups.” The applications listed are all published within the past month and a half, and all feature iPhone-like art in the supporting illustrations.

I haven’t taken the time to dig through the content of these patent filings but the the fact that they are based specifically in sharing of content among iPhone-like devices, and that they were filed within the past few weeks, lends credibility to the separate speculation by The Next Web that Color’s founder Bill Nguyen has been specifically angling for an acquisition by Apple. “See these pretty iPhone patents? They could be yours!”

OpenSSL On Mac OS X

Wolf Rentzsch learned about the various gotchas of linking directly with Mac OS X’s OpenSSL security libraries, and shared his wisdom in a cheeky Apple-style technote format:

Long story short: we screwed up when we included OpenSSL (libcrypto) in OS X in the first place.

(We learned our lesson and didn’t repeat the mistake with iOS.)

Now there’s some transitionin’ to do.

Linking directly to OpenSSL on Mac OS X is a time bomb. This is probably a more pervasive bug than it would otherwise be, since Apple prescribed using OpenSSL in their Mac App Store documentation demonstrating how to analyze Mac App Store receipts. The vast majority of developers probably followed Apple’s example, and are thus using OpenSSL and linking directly to libcrypto.

Twitter’s Token Rush

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 your 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.

Cachet

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.

Target The Forward Fringe

Marco Arment quipped on Twitter that web designers need to take HiDPI displays seriously, and adapt their designs to look great on them.

The short-sighted reactions he received revolve mostly around simple mathematical analysis: because HiDPI displays represent a relatively tiny percentage of all users, it is not worth a designer’s time to cater to that niche group.

I confess that after the iPad 3 was released, I paid little attention to adapting my site to support HiDPI. But when Apple announced the Retina MacBook Pro at WWDC, revamping all of my apps and my web site jumped to the top of my list of priorities. My apps are shaping up nicely. My site? Let’s just say it’s still on the top of my list.

Why? Because HiDPI customers may be a fringe group, but they are a forward-facing fringe. They represent the users of the future, and the more we cater to them now, the more deeply embedded our products and designs will be in their culture. The future culture. The same arguments apply to aggressively embracing newer web browsers standards, and the latest technologies in platform operating systems such as iOS and Mac OS X.

It doesn’t hurt that the forward fringe tends to be rich and influential, compared to other niche audiences. When some backward-compatibility quack notices that your site renders poorly on IE5, they may scream it from the rooftops, but it won’t make a serious dent in your sales or reputation.

In contrast, when a Retina early-adopter discovers how beautiful your site and software look on their fancy computer, they’ll be that much more likely to open their wallet again. When John Gruber or Jason Kottke happens upon your beautifully designed, HiDPI site, he’ll be that much more likely to spread the news about your forward-thinking design to their friends and readers.

Target the forward fringe.