Slashdot Mirror
Huge iPhone Cut-and-Paste Tool Security Flaw
Harry writes "I'm using Pastebud, the new third-party copy-and-paste solution for the iPhone. It's extremely clever, using a Web-based clipboard to get around the fact that Apple doesn't provide one on the phone. Unfortunately, it seems to be giving users access to e-mails that other Pastebud users send to their clipboards. This has happened to me repeatedly and is being reported by other users in Pastebud's Get Satisfaction support forum. Pastebud is operational and still doing this as I write, even though a message at Get Satisfaction says they're working on the problem."
Ya, if I read this correctly, a quick scan of TFA (I know, not supposed to do that here) seems to indicate this is a *Pastebud problem, not an iPhone problem. Of course, if the iPhone does not have cut'n'paste, that's entirely another problem.
When It Counts.
Apps are chrooted into their own directory structure, so they can't share data. But, yeah, this is people surprised to get what they should have expected.
Do you even lift?
These aren't the 'roids you're looking for.
(NOTE: Jed Schmidt of Pastebud fixed the problem I discuss in this post yesterday night after I notified him about it. It affected only users-such as me-who misconfigured the service. Scroll down for details...)
Harry,
I've updated this issue over at Get Satisfaction[1], but let me just summarize what exactly was going wrong: you were inadvertently forwarding your emails not to your secret pastebud address, but to the address set as the from address for these emails, which was noreply@pastebud.com.
This happened to other folks too; instead of sending email to secret-random-string@pastebud.com, they were sending to noreply@pastebud.com. And everyone who was doing this ended up sharing the same clipboard.
Anyway, I just wanted to let you know that we've fixed it, and the changed will be live by the morning. You can find more details about the issue here[1].
Thanks again for bringing this to our attention, and let me know if there's anything else you need clarification on.
Jed Schmidt
Founder, pastebud
Furthermore, why can't it just store your clipboard through local storage? Does it really have to put it up online?
You're looking for OpenClip. It's basically an open spec (well, as open as it can get under Apple's terms) for clipboards on the iPhone, and is supported by several applications. MagicPad is the notepad replacement that is written by the same folks.
Do Apple's apps have no way to store and retrieve local data?
iPhone applications have read-only access to the data of other applications. This prevents the creation of a single app that acts as a clipboard, since you can't (yet) have background apps.
What OpenClip does is specify a standard location in each app for clipboard data. When an app copies, it simply sets this variable to the clipped data. When an app wants to paste, it looks for clipped data in all the installed apps and uses the latest. it wastes a bit of memory if you have copied data from multiple apps, but it's pretty good given the technology. And there's no Internet involved.
According to the OpenClip website, Apple killed it off by tightening up the sandbox so that applications can't read each other's data. This doesn't surprise me.
Yes, on OS X, you would use the NSPasteBoard class to interact with the system-wide clipboard. The only thing stopping Apple from implementing NSPasteBoard in the iPhone SDK appears to be the question of how to implement it best in the UI. The system of NSPasteBoard filters handles all the gritty details of converting data between different formats; a given pasteboard can hold data in a specific format (or even multiple formats at once), and the client can invoke a filter to read the data from the PB using any applicable filters. Honestly, everything is in place API-wise, it seems that Apple simply wants to work out the UI (there is, in fact, more than one way to do it, but it seems they are dragging their heels with this important feature!)
If an app can read other apps' data, that's not much of a 'sandbox' now, is it?