I decided on Google Sites, which I knew and liked from its days as JotSpot, a hosted wiki with some powerful features. It ended up not being the right place for me, for a couple of reasons:

• Currently, Sites’ priorities are in website publishing, as a replacement for Google Page Creator (which is being phased out soon.) It’s quite good at it, but I’m less interested in that than in collaboration features.
• Google’s server-side infrastructure is really, really, really huge and complex. There is an endless landscape of internal technologies and tools—the few that have been described in public (MapReduce, BigTable, Chubby, etc.) are just the tip of the iceberg. I have discovered that I am not very interested in this kind of stuff, and I quickly became frustrated by the deluge of technologies I needed to learn to get things done.
• Running a large web service is like running a nuclear power plant or an electric power grid. It requires 24/7/365 monitoring, and at that scale, anything that can go wrong will go wrong, and frequently does. I do not have the right temperament for working with this, especially not when it comes to taking turns carrying a pager that wakes me up at 4AM because some service’s latency has gone above 300ms.
• I’ve been vocal about my frustration with centralized systems; Google’s websites are kind of the ultimate in that (even though, ironically, they’re implemented as P2P-like networks internally, as I believe all large web operations are today.)

The good news is that Google encourages transfers between teams, and makes it easy to do so. The near-total transparancy inside the company makes it easy to find out everything that’s going on, and there’s a well-designed website for engineering transfers that helps you find teams that need people. I even went to an internal job fair.

I’ve now ended up working on Chrome, Google’s web browser. The team I’m on is responsible for implementing HTML 5 features, as well as designing and implementing other new features (for standardization) that will help web apps become as powerful as native apps. Much of what we do will go into the WebKit source tree, where it will also directly benefit Safari, Android, the Palm Pre, and other WebKit-based browsers.

In fact, everything I work on (more or less) is going to be open source. Both the WebKit and Chromium source trees are public. You can view, if you care to, the one patch I’ve contributed so far and the one that’s currently out for review. That’s kind of mind-blowing, in a good way, to me, steeped as I am in the secrecy of Apple.

I’m pretty excited by this. There are quite a lot of things I’m interested in working on—client-side storage, local apps, drag-and-drop, better font support, menus, even far-out stuff like peer-to-peer networking. Forward in all directions!

1. Secure, encrypted storage for all passwords and keys.
2. Items can be shared between applications—so in principle you don’t have to enter a given password more than once, since other apps will find the existing item in the keychain.
3. Items have access control lists, so they can be restricted to certain apps.
4. The user can “lock” the keychain, requiring a passphrase to be entered before there’s any further access to it. This happens by default when the system goes to sleep, which is a good security feature especially for laptops.
5. If an app’s code changes, it has to ask permission to use the keychain again (protects against malicious code patches)

For the past few weeks’ worth of Copious Spare Time, I’ve been trying to get my MYCrypto framework, which is in part a friendly API to the Keychain, to run on iPhone. The iPhone has a Keychain API, but it’s a different API than the Mac OS one. At first glance it looks simpler and easier to use, and maybe it would be if it were properly documented, but in practice the item-storage part of it (the SecItem* functions) is incredibly frustrating because the documentation is both incomplete and just plain wrong.

Currently I’ve gotten a lot of it working, but I’m stuck on some issues that seem like either major Keychain bugs or philosophical differences (parts of the API don’t seem to work at all with items that exist in memory but haven’t been persistently added to the Keychain store.) I’ve filed at least six bug reports to Apple in the last week, including the kind of basic unit tets that I would have hoped Apple QA engineers would have written before iPhone 2.0 ever went to developers. I’m very frustrated.

All this for what?

After finishing the bug reports, I had the crazy idea: why should I be using the Keychain store at all on iPhone? Going through my above list of benefits, I realized that hardly any of them apply:

1. The iPhone security model relies on app sandboxing to protect data. Even malicious app code can’t reach the keychain file because it’s outside the app sandbox. (I have some data that implies that the file is in fact just a plaintext SQLite database, not the fancy encrypted store it is on OS X.) [ Update: I now have confirmation that the Keychain file is encrypted on the device and in backups, making it secure against most attacks.]
2. iPhone apps can’t share keychain items. Every app effectively has its own sandboxed keychain. So there’s no usability benefit of putting passwords in it.
3. No sharing means no point in access control lists, of course.
4. There’s no keychain passphrase or lock/unlock behavior on iPhone. Once you unlock the iPhone itself, all apps can access their keychains freely.
5. Since all apps are signed, there’s no question of malicious patches.

So much for that. What you’re left with is a rudimentary flat-file database, specialized for just a few data types, with a really clunky and badly documented API. Other than the fact that it happens to already exist, there’s nothing about it that’s as good as something you could write in a few hours using CoreData, or your favorite high-level SQLite API like FMDB or QuickLite. Heck, for simple needs you could just use a property list, for example an NSDictionary mapping URLs to [username, password] pairs. It ought to be just as secure, because the sandbox prevents any other apps from being able to access the file.

Updated: What you’re left with is an encrypted flat-file database, specialized for just a few data types, with a really clunky and badly documented API. As I wrote above, its functionality could be duplicated, with a better API, without much effort. The encryption part is significant, though, since its primary purpose is to keep keys and passwords safe. A DIY key database could be protected by encrypting it with a symmetric key, and then putting that key in the Keychain.

I’m not sure where that leaves MYCrypto. I’m not sure I’m motivated to write a general-purpose version of this data store myself. If I can get some good answers and workaround to my Keychain API bug reports, I may just continue to tough it out.

Leaving aside the issue of whether Apple has any business deciding what constitutes obscenity (a task that’s driven grown Supreme Court justices to drink)—
And leaving aside also the fact that Apple’s censors have three times now been too dim to comprehend that the application does not contain any books, obscene or otherwise, but downloads them from the Internet much like Safari—
No, the really outrageous issue is that the supposed obscenity here consists of a text-only English translation of the Kama Sutra. Apple specifically called out some pages of steamy advice for “when a man wishes to enlarge his lingam“. (No, really.) [1]

Now, Richard Burton had to get his 1883 translation of this ancient text printed privately when no publishers would accept it, but that was in the Victorian era. The current authoritative translation is nowadays published by that infamous smut peddler, Oxford University Press. Much harder-core fare like Ulysses and Lady Chatterley’s Lover—books which go so far as to use recognizable English names of the naughty bits—were judged after some controversy to be free of obscenity in the 1930s. By 1970 the obscenity statutes had been lifted from nearly all printed material, and nowadays anything goes—take a look at some of the e-books available for sale on the iTunes store.

Montgomerie has now, humiliatingly, been driven to self-censorship: his latest message to Apple states “I have now submitted a new version that specifically blocks access to the Kama Sutra book you identified. Is this what you mean?”

[Update, May 24: Mongomerie reports that on the 23rd he “received a phone call from an Apple representative. He was very complimentary about Eucalyptus.” The whole matter was, of course, resolved, and Eucalyptus is now available for purchase. A happy ending, certainly, and congratulations on the release! …But I don’t believe it invalidates my argument below. After all, this isn’t the first time an outrageous rejection has been reversed after mass humiliation of Apple. It’s the overall default policies and behaviors, and their chilling effects, that I’m complaining about, and there’s still no sign of those changing.]

The “E” word.

I don’t think anyone but a card-carrying member of the Christian Coalition or Taliban would disagree that this was a stupid decision on Apple’s part. (And it was a considered decision, not a ‘glitch in the approval process’, given that Apple repeated it twice.)

I feel the need to step up to a stronger word. How does evil sound?

Hear me out. I’m not talking “evil” as in killing babies or nuclear blackmail, rather in the sense it’s meant in Google’s corny motto “Don’t Be Evil”, or alluded to in the older proverb “With great power comes great responsibility”. But yes, I do mean “evil” as malign, the opposite of good, etc. etc.

Last year Apple put itself into an ethically very delicate situation with the App Store, by creating a market in which it has the sole power to make 3rd party software available (or to take it away). As has been amply discussed before, iPhone developers have no choice (if they want to be iPhone developers) but to put tremendous effort into developing the product, only finding out at the very end whether or not Apple will let it be sold.[2]

There are definitely some good reasons for such a model, primarily that it helps keep the platform secure from malware, and that by preventing piracy it allows developers to collect a lot more revenues per user, allowing them to set prices far lower than those in other software markets.

But in return Apple had the obligation to be very, very careful to be ethical, upright and transparent in its dealings with developers and the public, to minimize the dangers (of censorship, of conflicts of interest, of stifling innovation) inherent in its position.

And being Apple, it completely and utterly fucked it up. Because it’s in Apple’s genetic code to be about as transparent as a lead brick. This has always annoyed the press, and it has frequently enraged developers, who suffer from the consequences of blank silence from Apple in between carefully-scripted WWDC keynotes and PR-scrubbed announcements. But in the context of the App Store, Apple’s inscrutability and arbitrariness has become actively malign.

Evil is as evil does.

I’m not saying that Apple is evil; it isn’t run by bluestockings or monopolists or cackling supervillains. But evil is a result of what you do [3], and actions are not excused by good intentions; in the real world those who do evil (excepting psychopaths) uniformly believe they’re working for the good.

Apple’s App Store approval process has, over the past year, shown that the company is:

• acting like a Victorian-era book censor;
• quashing competition by blocking apps that improve on Apple’s products;
• blocking innovation by denying 3rd party apps access to the user’s legally-owned data (such as MP3s);
• attempting to deny end-users the freedom to do what they want with the hardware they bought and paid for (viz. its current efforts to have jailbreaking declared illegal);
• and causing undue hardship to small developers by arbitrarily withholding their ability to sell the apps they’ve developed.

Nor has Apple engaged in the slightest bit of dialog with its developers and users to work through any of these issues. The best that’s happened is that, after much public ridicule, Apple has without comment released some apps that it had previously blocked.

Maybe you think “evil” is too strong or melodramatic or exaggerated a word for this. Then feel free to substitute something that has fewer loaded connotations to you—“unethical” or “anticompetitive” or whatever. But if you’re one of those who, like me, has applied the “e” word to the past actions of Microsoft, or to groups that try to ban books from libraries, then I think there’s really no option but to use the same blunt language here and now.

[3] This semantic distinction is one I’m not sure Google gets either. “Don’t Do Evil” would have been a better motto. But in its defense, Google does in practice seem to understand its responsibilities and is admirably open about its actions.

“In this tutorial, we are going to explore a simple chat application for the iPhone. It allows you to host your own chat room and advertise it on your local Wi-Fi network (in which case your app acts as a chat “server”) or find and join chat rooms hosted by other people on your network (acting as a chat “client”). Both announcement and discovery of chat rooms are implemented using Apple’s Bonjour protocol. The goal of this app is to show you how to use various networking-related frameworks available in the iPhone SDK version 2.x. The UI is minimal (consisting of only 3 simple views) – just enough to be able to play with the core functionality of the app without having to deal with complex UIKit code.”

It’s a well-written overview of everything from sockets to runloops to message framing, and it happens to basically describe what my MYNetwork framework does. So an alternate way to read the tutorial is as a description of things you don’t have to worry about if you’re going to use MYNetwork ;-) Because honestly, the stuff he’s describing can be a real mess to deal with, and isn’t that the kind of thing that should be solved once and stuffed into a reusable framework?

Now I am seriously tempted to download the app, replace its networking and messaging code with MYNetwork, and see how small it comes out. If I do, I’ll be sure to post the results here.

[ Update: I actually did it. Here’s my forked Chatty.]

Speaking of “developers”, I’ve been really pleased with the reaction to my initial source-dump to Bitbucket! So far, in nine days:

• 79 people have subscribed to change notifications;
• 10 people have forked the repository so they can modify the code;
• 8 people have contributed to the code, fixing bugs and adding some new features;
• 39 changesets have been committed to the repository;
• 29 bug reports and feature suggestions have been filed,
• 12 of which have been fixed.

I’m especially happy about the patches I’ve received; I’ve gotten some in the past, but never this many or so quickly. Part of this is thanks to Bitbucket, which (like its inspiration, Github) makes it so easy to share code and manage contributions. I’ve been getting more contributions to MYNetwork as well, since hosting it there.

My initial motivation was like Tom Sawyer whitewashing the fence—I was hoping someone else would take over the project, since I’d run out of steam and hadn’t done any work on it in a while. But what happened instead is that the attention got me enthused to work on it again, so I’ve made a lot of progress on it this past week. That’s a good thing!, just not what I expected.

Now I think it’s about time to put out an actual easy-to-download binary release of Murky, as some of the main bugs have been squashed and I have more confidence that it works for other people besides me. I’ll probably do that this weekend, and mention it here as well as on the new mailing list (don’t forget to subscribe.)

Now, Chrome is open source. (Technically the open source project is a separate thing called “Chromium”, but that’s mostly an organizational detail; the code is the same.) So when I compared this controversy to the rather different attitude of the many programmers who’ve gladly contributed to Chrome and WebKit (and thus also Safari) without pay … I went “hmm”.

There’s a long comment thread about this on the LiveJournal of the talented cartoonist Rebecca Clements. The craziest comment I saw was by one “Anonymous”:

“Good will never paid a bill or put shoes on my child. I admit there should be some caring people in the world. But Google being kind …so we all should be kind like them and give our work away? Come on give me a break. Someone in their executive chain of management has thought this through enough to realize it as a Public Relations “cool” thing to do to get more attention and drive people to Google as a source. It wasn’t because they feel like being kind and giving something away.” *

Maybe I’m especially pissed off at this attitude because I just spent most of my weekend being kind and giving my work away (as well as the work of several others). And I’m sure much of the software these complaining artists use was created for free by open-source programmers. Do they draw with The Gimp or Inkscape? Use Firefox or Chrome or Safari? Run Linux or BSD? Host their blogs with WordPress or LiveJournal? (Let’s just hope they’re not using pirated copies of Photoshop or CorelDraw…)

So is there a double standard here, or am I missing something?

I’m happy to say that Murky is finally blinking in the light of day, with its own Mercurial [natch] repository on Bitbucket.

Setting Expectations

Murky isn’t “done”, and this isn’t a 1.0, or even a beta, release. I’m not even providing a compiled app to download, just the source repository. No one but me has ever tested it. About nine months ago Murky became “good enough” for what I usually do, and I’m a happy customer, but I’ve lost the impetus to keep adding things to it. I hope some other people will grab the baton and improve it further. Then we can throw a party for a real 1.0 release, with several names on the About box.

Obligatory Screenshot

Features

Here’s what it can do so far:

• Create a new repository from an existing folder
• Clone a remote (or local) repository
• View the revision history (log) of a repo as a table view, complete with * a visual graph showing the inheritance of revisions
• View the source tree, and the contents of files, from any past revision
• See which files were changed, added or removed in any revision
• Compare revisions of files, either visually with FileMerge, or as straight ‘diff’ output
• Add or remove files from the local working tree
• Commit (or revert) changed files
• Update to a specific revision (past or present)
• Push to or pull from remote repositories
• Automatically detects filesystem changes made by other apps (or by the ‘hg’ tool) and updates the display immediately

In addition to Mercurial repository hosting, each project gets a nice source browser, a wiki, and a bug-tracker.

To kick things off, I’ve put up a new release of MYNetwork. It doesn’t change the core functionality much, but it adds

• A new PortMapper class that lets you open up your TCPListener to receive connections from outside your local network, when behind a NAT;
• Bonjour classes for browsing for network services.

I’ve also restored the BLIP protocol documentation that went AWOL when my own local project server died last year.

Abstract.

Numerous studies have been conducted upon patients in terminal paresis (GPI), placing the author J.G. Ballard in a series of simulated auto crashes, e.g. multiple pileups, head-on collisions, motorcade attacks (fantasies of Presidential assassinations remained a continuing preoccupation, subjects showing a marked polymorphic fixation on windshields and rear trunk assemblies). Powerful erotic fantasies of an anal-sadistic nature surrounded the image of the award-winning novelist.

J.G. Ballard And The Conceptual Auto-Disaster.

J.G. Ballard died yesterday in his last car-crash. During his life he had rehearsed his death in many crashes, but this was his only true accident. Driven on a collision course towards the royal limousine, his car jumped the rails of the London Airport flyover and plunged through the roof of a bus filled with airline passengers. The crushed bodies of package tourists, like a hæmorrhage of the sun, still lay across the vinyl seats an hour later. Holding the arm of her chauffeur, the Princess Diana, with whom Ballard had dreamed of dying for so many months, stood alone under the revolving ambulance lights, a gloved hand to her throat.

Could she see, in Ballard’s posture, the formula of the death he had devised for her? During the last weeks of his life Ballard had thought of nothing else but her death, a coronation of wounds he had staged with the devotion of an Earl Marshal. The walls of his apartment near the film studios at Shepperton were covered with the photographs he had taken with his zoom lens each morning as she left her hotel in London, from the pedestrian bridges above the westbound motorways, and from the roof of the multi-storey car-park at the studios. The magnified details of her knees and hands, of the inner surface of her thighs and the left apex of her mouth, he matched at his apartment with the photographs of grotesque wounds in a textbook of plastic surgery.

Yesterday his body lay under the police arc-lights at the foot of the flyover, veiled by a delicate lacework of blood. The broken postures of his legs and arms, the bloody geometry of his face, seemed to parody the photographs of crash injuries that covered the walls of his apartment. Twenty yards away, illuminated by the revolving lamps, the princess hovered on the arm of her chauffeur. Ballard had dreamed of dying at the moment of her orgasm.

Before his death Ballard had taken part in many crashes. As I think of Ballard I see him in the stolen cars he drove and damaged, the surfaces of deformed metal and plastic that for ever embraced him.

The Voices Of Time.

You’re not alone, Ballard, don’t think you are. These are the voices of time, and they’re all saying goodbye to you.
Every particle in your body, every grain of sand, every galaxy carries the same signature.
You know what the time is now,
so what does the rest matter?

References.

• Ballard, J.G. “The Voices Of Time” [1962]
• Ballard, J.G. “Why I Want To Fuck Ronald Reagan” [1967]
• Ballard, J.J. The Atrocity Exhibition [1969]
• Ballard, J.G. Crash [1973]

[For the perplexed or appalled: This is a pastiche assembled out of bits of Ballard’s best-known works, with the names changed around. I claim no ownership of these words nor personal identification with their opinions.]