3 ms·

In such a decentralized (pushes of feed updates, for example) architecture, how do you revoke a given permission? The data is no longer yours once you pushed it

by gokhan 16y ago

In such a decentralized (pushes of feed updates, for example) architecture, how do you revoke a given permission? The data is no longer yours once you pushed it to some other dude's server. DRMing little chunks of data would also be expensive and time consuming if you check every feed item you can see all the time from publisher's servers. Facebook, also, is not just profiles and the feed. How about events, in a decentralized way, for example? Will a single accept will be amplified to the rest of 500 people invited? For the profile part, my basic identity is my email address. Implement something on the mail server that I can manage and let that be my profile. Emailing a specific command to gokhan@example.com results my profile as the attachment, for example.

pyre 16y ago
So it would just not come with a delete function. Once you've given someone a piece of information, it's hard to revoke it anyway. If you published a phone number to a bunch of friends that you didn't want to have the number, the protocol could allow your client to contact theirs, and ask to delete that information if it exists. Sure their client could refuse to abide by that request, but it's equally likely that they could have exported that phone number info Outlook/AddressBook or written it down on a piece of paper. How do you revoke it then? As to blog/microblog posts, the same thing applies. The communication protocol between clients could specific a mechanism to request a deletion, but there's no guarantee that their client would obey. But there's also no guarantee that the other person hasn't already read your post. Once you send information out into the world, it's very hard to pull it back in. Even on Facebook, if you broadcast information to people, there's no guarantee that they haven't written it down, exported it, screenshotted it before you deleted it or revoked privilege to it.
- mseebach 16y ago
  If we have to assume no privacy around the data on the site, it's much, much easier to just export that assumption to Facebook and keep using that since it has the benefit of existing. The social-service your friends are using will have the same access to the data your friend has access to, and if compromised, you are also compromised. So now you have to trust the integrity of potentially hundreds (actually infinite, since the ability for your friends to carry your authentication for them to access you to a new service would be central) of services - which you can't/don't - and then it's easier to just not trust Facebook.
  - pyre 16y ago
    > If we have to assume no privacy around the data on the site Where did you draw that conclusion? If you accidentally send the wrong data to the wrong person you've violated your own privacy due to your own mistake. That's a lot different than you specifying that someone shouldn't get a certain piece of information, but that person gets it anyway because the software erroneously allows them to see it. It's also a lot different than allowing third parties access to your private data.
anonjon 16y ago
You store all of your stuff on your server. Friending someone gives them permission to pull from your most recent feed. I suppose that if you really wanted privacy, you could give everyone a public key, and then only syndicate your information encrypted with the keys of people who you have friended. Then I guess you would use a desktop client or something to read feeds... allowing them to be unencrypted someone else's server would kind of defeat the purpose. Of course, the real problem with privacy on Facebook is that you can't really have it. When you have 100+ facebook friends, there is a massive attack surface for your information to be leaked. (In our example, get their key stolen, or simply decrypt and repost to a different server). It is almost a ridiculous request...

by gokhan 16y ago

pyre 16y ago

So it would just not come with a delete function. Once you've given someone a piece of information, it's hard to revoke it anyway. If you published a phone number to a bunch of friends that you didn't want to have the number, the protocol could allow your client to contact theirs, and ask to delete that information if it exists. Sure their client could refuse to abide by that request, but it's equally likely that they could have exported that phone number info Outlook/AddressBook or written it down on a piece of paper. How do you revoke it then? As to blog/microblog posts, the same thing applies. The communication protocol between clients could specific a mechanism to request a deletion, but there's no guarantee that their client would obey. But there's also no guarantee that the other person hasn't already read your post. Once you send information out into the world, it's very hard to pull it back in. Even on Facebook, if you broadcast information to people, there's no guarantee that they haven't written it down, exported it, screenshotted it before you deleted it or revoked privilege to it.

mseebach 16y ago
If we have to assume no privacy around the data on the site, it's much, much easier to just export that assumption to Facebook and keep using that since it has the benefit of existing. The social-service your friends are using will have the same access to the data your friend has access to, and if compromised, you are also compromised. So now you have to trust the integrity of potentially hundreds (actually infinite, since the ability for your friends to carry your authentication for them to access you to a new service would be central) of services - which you can't/don't - and then it's easier to just not trust Facebook.
- pyre 16y ago
  > If we have to assume no privacy around the data on the site Where did you draw that conclusion? If you accidentally send the wrong data to the wrong person you've violated your own privacy due to your own mistake. That's a lot different than you specifying that someone shouldn't get a certain piece of information, but that person gets it anyway because the software erroneously allows them to see it. It's also a lot different than allowing third parties access to your private data.

anonjon 16y ago

You store all of your stuff on your server. Friending someone gives them permission to pull from your most recent feed. I suppose that if you really wanted privacy, you could give everyone a public key, and then only syndicate your information encrypted with the keys of people who you have friended. Then I guess you would use a desktop client or something to read feeds... allowing them to be unencrypted someone else's server would kind of defeat the purpose. Of course, the real problem with privacy on Facebook is that you can't really have it. When you have 100+ facebook friends, there is a massive attack surface for your information to be leaked. (In our example, get their key stolen, or simply decrypt and repost to a different server). It is almost a ridiculous request...