Hacker News new | comments | show | ask | jobs | submit login

Our goal is that all your data will be encrypted and completely secure from the point that they leave your camera until you view them in the app/website/etc. The images would only be your to decrypt and we would have no access to your key, only you will be able to view your images, unless you share them ofc.

Our biggest concerns at the moment is partly how we can implement effective encryption/decryption that won't drain the battery life of your phone or decrease the user experience. Another concern is what will happen if the user loses their password? If we have no possibility to access a users encrypted data then their data would be lost in this case. We would also need to decrypt and reencrypt all data if the user changes password, something that would be very time/battery consuming if done on the device, instead of our servers.

These concerns are something that we are evaluating solutions to as we speak, our goal is to make it impossible for anyone but you to access your private, aka. not shared, data. If you have any suggestions we are of course happy to hear them.

/Dan Berglund, Software Developer @ Memoto

The most important thing you need to do is to make your implementation completely transparent and publicly available. Data doesn't get more personal and private than the data you will be storing.

Simply saying that you encrypt data is not enough. People need to know who has the keys and who is able to get access to the keys if they need to.

Also, if the images can be viewed in a webpage, then they're not encrypted as far as I'm concerned. Even if you use client side javascript to handle the decryption, you can be compelled to modify that javascript for a particular user to obtain their key/password next time they log in.

"We would also need to decrypt and reencrypt all data if the user changes password"

This depends if you are using a key derived from the password. Or if you are using a randomly generated key that is encrypted using a key derived from the password. With the latter, you would only need to re-encrypt the randomly generated key. Not the entire data set.

I understand that usability is important for your business case. Just don't forget how sensitive the data is that you will be collecting and how ripe for abuse it is if you don't secure it fully.

I also think that you should open source your client software. If not, I'd be concerned that at some point you'll be forced to put back doors in it to get at peoples keys.

You can do what apple does for disk encryption:

* Encrypt the data with a key (let the user print it out if you like)

* Encrypt the key with the password of the user (or multiple users!)

* Store the encrypted-encrypted-key on your server.

If a user wants to change their password, their old password decrypts the key, and the new password re-encrypts the key.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact