3 ms·
Well, (1) would be pointless: that means you're still decrypting server-side! The way I see it, social networks are mostly just a reworked version of (email +
by yungchin 17y ago
Well, (1) would be pointless: that means you're still decrypting server-side!
The way I see it, social networks are mostly just a reworked version of (email + mailing lists + usenet) in a form that appeals to non-techies. Now, adding encryption requires quite a deep understanding of how the system works in order for it to be useful (eg. how many non-techies would realise that (1) defeats the purpose?), so it's really only for techies. But techies already have GPG-encrypted email...
- lukev 17y agoIt would be pointless from an ultimate trust perspective, yes. But somehow I'd still feel more comfortable with a company that (at least claims) to use my key only to decrypt data immediately before sending it to me, than a company that stores all my data in clear text and mines it and distributes it internally as they see fit.
- yungchin 17y agoI get the feeling, but rationally, that would be equivalent to a company that simply promises (say, in the Terms of Service) not to mess with your data. I may actually trust a company on such promises, but the real risk is in this scenario: the company goes bust and some weirdos seize control of the server. In that situation, it doesn't matter much that the data is encrypted, if the keys are available too.
- lukev 17y agoThis could be alleviated if the server kept the user's key only on a per-session basis and never actually stored it. I'm curious... how would you feel about that? Also, there might be a way to make a server transparent so people are more likely to trust it... open-source the server code, of course, and expose the entire file system as read-only could people could run a checksum on the server executable to verify it's the same one? Of course there'd ultimately be no guarantee that there wasn't networking trickery going on...