Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

tl;dr from the FAQ:

Q: "Why should I trust you?" A: "Because you should! We're good people! Honest!"

I'd love to trust a service like this, but there's no credible effort to actually establish that trust.



Don't trust. Use a client that adds an encryption layer on top of file.io.


Or just encrypt your files.


Now it says

> file.io is a project of humb.ly. It was created simply out of the joy of trying to build cool things on the internet, and we thought it may be useful for others. We take privacy very seriously and do not save any data once it has been deleted.

But going to humb.ly still doesn't really get me to trust you, there's not even any identifying info on that page. Two projects, one discontinued and one -- it seems -- novelty "religion".


It said that before, too — I was paraphrasing. "humb.ly" is a more trustable name than, say, "Megaupload", but they can say whatever they want.

What I want is some assurance like "The EFF has complete read-access to our platform and maintains a continuous independent audit of these services to verify that we comply with our own privacy assurances." The EFF is probably not the organization to do such a thing, but that's kind of what I'm looking for.


Humb.ly also makes park.io where the domain file.io is from.


So encrypt client-side?


I built a service for this a few years back - it encrypts and decrypts on each side, all in JS. It's pretty quick with web workers.

https://securesha.re


This is close to something I keep meaning to make.

It would be awesome if I could download the file without the password to verify that it's stored encrypted though.


That could be faked. The best way to ensure I'm not cheating is to watch the network requests and to look at the code (https://github.com/STRML/securesha.re-client/tree/master/jqu...).

You'll see the POST to the server going up encrypted, and the subsequent GET when you download the file coming down encrypted as a binary XHR.



Okay, but then the receiver has to know how to decrypt. Kind of narrows down who I can realistically send files to.


If you are that concerned about security you should be willing to deal with the effort of encrypting it client side and understanding how to also decrypt on the receiving side.

If paranoia is this high, why would a security policy text on a web page make any difference? They could claim anything they want, but you wouldn't have any idea if any actual encryption was happening, so best to do it yourself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: