It's not like preventing root from getting the key is some attribute they omitted by accident or incompetence - it's a significant design change that changes the way the application would work. It seems like everyone criticizing Facebook is angry that they're not compromising their design principals for added security. They have very clear priorities: We are _going_ to benchmark and make sure any code we add does not increase UI latency beyond an unacceptable limit. We are _going_ to cache some large MB of data on the phone, because it makes the app faster. We are _not_ going to take up more space than we need. We are _going_ to support old phones that have an SD Card, and if that's where we cache the data, then so be it. We are _not_ going to require the user to enter a password or PIN on app startup. We are _not_ going to require the phone to be online to used the cached data. With requirements like those, what you get is exactly this library. It adds some small level of security against a very specific attack: data stored on the SD Card and accessible to other programs. (It may even be a way to get the security they need to permit themselves to store cached data on the SD Card, which is a desirable situation because it makes the app faster.) If you relax some of those requirements, you can add security features. Relax the latency or minimal storage requirement and you can create an encrypted container, and hide metadata like filenames, sizes, and times (like IOCipher). Relax the password requirement, and you can have the user enter a password on app startup and prevent root from getting the key unless it's in memory or entered. Relax the latency and offline requirement, and you can have the server send down a key to decrypt the data. Facebook is starting with the User Experience and adding as much security as it allows. -tom