4 ms·
That's still vulnerable to coldboot style attacks. If the data is never unencrypted unless you're readining it that's technically safer. But yes you are right t
by gravypod 10y ago
That's still vulnerable to coldboot style attacks. If the data is never unencrypted unless you're readining it that's technically safer. But yes you are right that would work as well.
- Tepix 10y agoHawkpost (the project introduced here) is also vulnerable to a coldboot attack - if the server that sends the page with the javascript is compromised, all bets are off.
- jsingleton 10y agoYou need to trust the server at some point. Assuming you do then it doesn't matter if the at-rest encryption is done in the browser or on the server. I'd be happy with HTTPS upload and PGP encryption before writing to disk or forwarding. I think the biggest risk of a secure upload server is a vulnerability exposing a disk full of secure content in the future.
- EGreg 10y agoYour don't need to trust the server. You can implement subresource integrity checks!
- nsgi 10y agoSubresource integrity still requires you to trust the server sending the hashes.
- EGreg 10y agoOk so publish the hashes on a blockchain and have the client verify them there
- rudolf0 10y agoNot a bad idea, but this isn't a thing browsers currently do, and the average person can't do that with ease. Especially considering this web app is aimed at non-tech savvy individuals.
- roblabla 10y agoMake the whole page hosted on IPFS, and make your DNS point to it. Then you just need to trust the DNS. So use namecoin.