3 ms·

> we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it. This doesn't solve the problem you're respond

by graue 14y ago

> we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it. This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo. In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does.

gizmo686 14y ago
> In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does. Actually, facebook does, and that information is (potentially) available to third parties. The intent of my system is that in order for information to leek, you would need to have one of your trusted recipients be compromised.
- graue 14y ago
  If you're thinking in terms of Facebook showing deleted updates to law enforcement to track down activists — or some rogue employee at Facebook HQ taking a peek — then we're talking about totally different levels of paranoia. Sure, that is a legitimate concern for the relative few who have something to fear from powerful governments. For the rest of us, though, someone we unfriend (an ex-partner, for example) being able to archive and still access all of our old photos/updates is a much bigger concern. I argue that distributed social software should follow Facebook's lead and offer a sane default of not having such an archiving feature, and not going out of its way to make it particularly easy to add one, either. Otherwise the "creepy" aspect of not being able to rescind access to your photos/updates is going to be a serious downside to this new network, and could keep people from using it. Edited to add: Also, what's more secure in theory isn't always more secure in practice. Moxie Marlinspike observed that the original version of Cryptocat (which did end-to-end encryption in JS) was potentially less safe than Gchat. Why? Because if you compromised Cryptocat's server, you could make it serve JS with a hidden backdoor. And Cryptocat, being a one-man shop, would likely be a softer target than a company like Google, which has had plenty of time and expertise hardening their systems. How much do you trust the guy behind Cryptocat, versus Google with their reputation to protect? Along the same lines, imagine you use a hosted Tent server for social networking — you don't have time to bother running your own server, but you've heard Tent keeps your data safe from Facebook, so it'll protect your privacy better, right? But then the random guy hosting your Tent account turns around and leaks your info. Or he's running old software with a vulnerability in it, and gets pwned. Suddenly hackers have all your data. Would that have happened on Facebook? When I was curious about signing up with Diaspora, one of the open community pods had a cheeky note from the server admin saying basically that he would peek in and read your stuff if he felt like it. So this is not entirely hypothetical. I'm a huge fan of efforts like Tent, but let's not forget there are upsides to Facebook and Google's stewardship, and an alternative system can easily have as many privacy/security cons as it does pros. Tread carefully.
tripzilch 14y ago
> "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo. That particular photo, yes. But Bob could also have saved that photo as soon as he saw it or maybe he's got eidetic memory, so crypto can't help with that anymore. However, any new photos shared through the same channel can't be seen by Bob anymore because I assume the key changes as the members of the access group change. Still, while you can't solve the original problem (Bob can leak everything), you can still do slightly better than that by properly implementing Off-The-Record messaging[1]. This adds perfect forward secrecy, as well as deniability: The latter is very interesting because in OTR it means that both parties can authenticate received messages to be certain of the sender's identity, but they can also FORGE any message to look like it's been signed by the other. This means that even if Bob decides to publish your private messages to him, he can never prove you were the one that wrote and signed them, because he could have forged them himself. Two problems with that: I'm not sure how the OTR protocol extends to multiple recipients (but I bet there's some research on it), and while this "deniability" might be enough for private (text) messages, it's not much use for photographs in many cases: If Bob decides to publish an embarassing photo of you that he had once access to, it's not going to be much use that you can argue "ha, but you can't prove I sent you that photo!". Still, for textual communication, it adds a (thin) layer of extra security even though you can never beat Eidetic Bob. [1] http://www.cypherpunks.ca/otr/index.php#docs http://www.cypherpunks.ca/otr/index.php#docs and in particular http://www.cypherpunks.ca/otr/otr-codecon.pdf http://www.cypherpunks.ca/otr/otr-codecon.pdf
- graue 14y ago
  I addressed the "Bob could have saved that photo" point: "although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does." Facebook has a sane default of not saving everything that you view on your computer. Yes, maybe someone saved one or two photos, but they probably don't have them all. OTR is pointless for a medium that's mostly about photo sharing. For the Facebook use case, what's far more important than crypto is the set of social norms the site establishes via what's easy to do (share) and what's hard, e.g., archiving everything your friends share as it comes in. Not only would that be tricky to do without getting detected as a bot, but 99.9% of users would never think to try it. This problem is inherently more tractable with a distributed system, and that could be bad.

by graue 14y ago

gizmo686 14y ago

> In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does. Actually, facebook does, and that information is (potentially) available to third parties. The intent of my system is that in order for information to leek, you would need to have one of your trusted recipients be compromised.

graue 14y ago
If you're thinking in terms of Facebook showing deleted updates to law enforcement to track down activists — or some rogue employee at Facebook HQ taking a peek — then we're talking about totally different levels of paranoia. Sure, that is a legitimate concern for the relative few who have something to fear from powerful governments. For the rest of us, though, someone we unfriend (an ex-partner, for example) being able to archive and still access all of our old photos/updates is a much bigger concern. I argue that distributed social software should follow Facebook's lead and offer a sane default of not having such an archiving feature, and not going out of its way to make it particularly easy to add one, either. Otherwise the "creepy" aspect of not being able to rescind access to your photos/updates is going to be a serious downside to this new network, and could keep people from using it. Edited to add: Also, what's more secure in theory isn't always more secure in practice. Moxie Marlinspike observed that the original version of Cryptocat (which did end-to-end encryption in JS) was potentially less safe than Gchat. Why? Because if you compromised Cryptocat's server, you could make it serve JS with a hidden backdoor. And Cryptocat, being a one-man shop, would likely be a softer target than a company like Google, which has had plenty of time and expertise hardening their systems. How much do you trust the guy behind Cryptocat, versus Google with their reputation to protect? Along the same lines, imagine you use a hosted Tent server for social networking — you don't have time to bother running your own server, but you've heard Tent keeps your data safe from Facebook, so it'll protect your privacy better, right? But then the random guy hosting your Tent account turns around and leaks your info. Or he's running old software with a vulnerability in it, and gets pwned. Suddenly hackers have all your data. Would that have happened on Facebook? When I was curious about signing up with Diaspora, one of the open community pods had a cheeky note from the server admin saying basically that he would peek in and read your stuff if he felt like it. So this is not entirely hypothetical. I'm a huge fan of efforts like Tent, but let's not forget there are upsides to Facebook and Google's stewardship, and an alternative system can easily have as many privacy/security cons as it does pros. Tread carefully.

tripzilch 14y ago

> "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo. That particular photo, yes. But Bob could also have saved that photo as soon as he saw it or maybe he's got eidetic memory, so crypto can't help with that anymore. However, any new photos shared through the same channel can't be seen by Bob anymore because I assume the key changes as the members of the access group change. Still, while you can't solve the original problem (Bob can leak everything), you can still do slightly better than that by properly implementing Off-The-Record messaging[1]. This adds perfect forward secrecy, as well as deniability: The latter is very interesting because in OTR it means that both parties can authenticate received messages to be certain of the sender's identity, but they can also FORGE any message to look like it's been signed by the other. This means that even if Bob decides to publish your private messages to him, he can never prove you were the one that wrote and signed them, because he could have forged them himself. Two problems with that: I'm not sure how the OTR protocol extends to multiple recipients (but I bet there's some research on it), and while this "deniability" might be enough for private (text) messages, it's not much use for photographs in many cases: If Bob decides to publish an embarassing photo of you that he had once access to, it's not going to be much use that you can argue "ha, but you can't prove I sent you that photo!". Still, for textual communication, it adds a (thin) layer of extra security even though you can never beat Eidetic Bob. [1] http://www.cypherpunks.ca/otr/index.php#docs http://www.cypherpunks.ca/otr/index.php#docs and in particular http://www.cypherpunks.ca/otr/otr-codecon.pdf http://www.cypherpunks.ca/otr/otr-codecon.pdf

graue 14y ago
I addressed the "Bob could have saved that photo" point: "although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does." Facebook has a sane default of not saving everything that you view on your computer. Yes, maybe someone saved one or two photos, but they probably don't have them all. OTR is pointless for a medium that's mostly about photo sharing. For the Facebook use case, what's far more important than crypto is the set of social norms the site establishes via what's easy to do (share) and what's hard, e.g., archiving everything your friends share as it comes in. Not only would that be tricky to do without getting detected as a bot, but 99.9% of users would never think to try it. This problem is inherently more tractable with a distributed system, and that could be bad.