Marco.org

I looked at the code for OpenClip, the much-publicized iPhone copy-and-paste API for third-party apps. I was very curious about where exactly they stored the clipboard data, since what they’re claiming really shouldn’t be possible. The Developer FAQ is vague:

OpenClip utilizes a shared space on the iPhone. Applications that use the OpenClip framework can access this common area to write to and read from…

Applications are installed into their own directories named with massive random strings, like this:

/whatever/Applications/474F785BFD/

That app’s document files would be stored here:

/whatever/Applications/474F785BFD/Documents/

As far as I can tell by a quick glance at the source code, this is how it works: OpenClip apps create their own subdirectory called OpenClip if it doesn’t already exist in the Documents folder and save the clipboard data in a file there, e.g.:

/whatever/Applications/474F785BFD/Documents/OpenClip

To paste the copied data, it iterates through every app’s directory, looking for that OpenClip directory, and reading the clipboard data if it finds it.

See the problem yet?

This means that applications can read any data from other applications. This is a very bad thing, a tremendous security hole, and definitely not allowed by the SDK agreement.

The FAQ states:

OpenClip is 100% SDK kosher. Using Zac White’s “open clipboard” technique, copy / paste between applications is now 100% legitimate and 100% possible.

Unless I’m missing something about how this works, or I’m misreading the code, this is almost certainly very prohibited, and likely to be patched (and disabled) by a future iPhone software update.

And if I’m correct, any application that uses OpenClip is likely to be delisted from the App Store. I won’t go anywhere near it.

UPDATE: Daryn clarifies with the relevant part of the SDK agreement:

The SDK Agreement states that an Application may only write data within its designated container; it doesn’t address reading data, so technically, this is not in violation, as each participating app writes within its own space […]

That’s a minor technicality, and I’m sure Apple will gladly update the terms to include prohibitions against reading files in other apps’ data directories.

And it’s still a huge security hole for other applications’ data directories to be readable. Using this, an app can read any saved authentication information in any other apps — for example, an app could steal your Flickr API key from any other apps that you’ve trusted with access to your Flickr account. Or an arbitrary app could read saved passwords from a password-manager app.

You could argue that the apps should be encrypting stored sensitive data, but in practice, I bet this isn’t the case:

• When you submit to the App Store, Apple asks if your app contains encryption. U.S. export laws prohibit distributing encryption code outside of the country, so it’s much easier to get worldwide distribution if you don’t use encryption.
• iPhone apps are so heavily sandboxed that most developers understandably assume that their apps’ data directories are private.

So despite being technically allowed by the SDK, I bet this won’t last long, and I sure as hell won’t risk my app (and presumably my developer membership) on it.