I guess I should explain a bit more about the SharedObject thing.
As awalton correctly points out, we don't actually have very much available storage to put data from SharedObject. And this being NAND, there *are* limitations on how many times you can practically write to it, but that's not a material concern in this day and age.
Even if SharedObject *did* function, Flash does not allow the developer to designate *where* to store the data, so the fact that you may have extra storage on the USB port is immaterial - there's no way to tell it to save it there as opposed to where it would normally save it.
But let's say we exposed an API to let widget developers store arbitrary data on USB devices. What's to stop some malicious developer from making a widget that wipes out data there? What happens when a customer plugs in their iPod and loses everything due to some freakazoid that thinks it's funny?
We're making this system open enough that you can destroy *your* chumby. We're *not* going to set up a system with such poor security as to allow you the ability to destroy *other* people's chumbys. Allow free read/write access to the device's storage media most definitely fits that category.
These are well-trod paths in the security domain - people had the same complaints about the quite rational and necessary security restrictions of Java in the the browser as limitations on "choice". It's a Basic Rule - Thou Shalt Not Let Something That Came From The Network Have Read/Write Access. A huge percentage of the security issues with Microsoft Windows stem from them ignoring this basic rule.
You're welcome to make a convincing argument otherwise. We're listening.