4 ms·
So encrypt client-side?
by j_s 11y ago
So encrypt client-side?
- chbrown 11y agoOkay, but then the receiver has to know how to decrypt. Kind of narrows down who I can realistically send files to.
- res0nat0r 11y agoIf 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.
- cead_ite 11y agohttps://img.bi/ https://img.bi/
- STRML 11y agoI 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 https://securesha.re
- tattler 11y agoThis 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.
- STRML 11y agoThat 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/jquery-spaghetti 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.