[liberationtech] a privacy preserving and resilient social network
Yosem Companys
companys at stanford.edu
Fri Jun 28 12:20:05 PDT 2013
I want to commend Alirezza.
It's very important for us to welcome all those who design and conduct
research on liberation technologies, I commend him for trying to
build something of importance to all of us and dealing with the
inevitable issues that result from doing so.
One of the great things of this list is that others with
liberationtech experience are kind enough to give feedback to folks
like Alirezza.
As always, however, let's try to keep the discussion constructive.
Rather than simply point out why certain things may not work, outline
your ideas about how these limitations could be overcome. Everything
has a solution, if only we brainstorm the problem long enough.
It's one of the best ways we can all learn from one another and
continue to make progress in the field.
Best,
Yosem, one of the list moderators
On Fri, Jun 28, 2013 at 12:01 PM, Alireza Mahdian
<alireza.mahdian at gmail.com> wrote:
> To answer your concerns Eleanor: If you are talking about content
> unlinkability as implemented in Darknet I don't want that in a social
> network that works like Facebook. I want to be able to trust the contents
> that are published on it based on their linkability to their publishers.
> Think of Facebook with no content linkability, it is not even meaningful
> anymore. what does it mean to have a wall if no one knows who the wall
> belongs to. it is a completely different experience and I did not want that
> in MyZone. I was more aiming at a distributed Facebook where user contents
> are stored on their own devices and mirrored on trusted devices.
>
> Now if you are talking about the linkability of users within the social
> graph I would also recommend you to take a look at my thesis where I have
> introduced the concept of social hosting. an advantage of this is that let's
> say user A and B are friends also B and C are friends but not A and C. if B
> chooses A as a mirror then C would at some point connect to A to receive B's
> updates or interact with B's profile while it is offline (writing something
> on B's wall for example) at this point the entity that monitors all the
> links (let's say the government) would wrongly assume that A and C are
> friends (linkability) while it is not true. now the users can use this to
> their advantage and when prosecuted they can deny the linkability by just
> giving the counter example of this i.e. if A and C are really friends and A
> happens to be a person of interest C can always claim that A was not his
> friend and he only connected to A because it was hosting B which is a non
> threatening user. I have introduced the concept of deniability while
> providing authentication in the system. the authenticity is valid within the
> social network (if A publishes something it is traced back to A by all of
> A's friends) while the deniability is valid outside the social network (as I
> made the example). As john mentioned the user experience is very important
> if at some point this system is going to compete with something like
> Facebook therefore implementing this on top of an overlay network would not
> be a good design choice. As for any system I am not claiming that this
> system does not suffer from any drawbacks but at least it's a fully
> functioning system that provides a pretty good user experience while
> preserving their privacy. also at its full implementation it is resilient
> towards large scale DDoS attacks and black outs which is what I mean by
> resiliency.
>
> To answer John: As I mentioned in an earlier post I have done this protect
> myself from any liability if someone modifies the code rendering it a
> malware. I may publish the service layer code independently under a
> different license where anyone can modify it as they want to. However I do
> understand your point.
>
> On Jun 28, 2013, at 11:14 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>
> From: Eleanor Saitta <ella at dymaxion.org>
> To: liberationtech <liberationtech at mailman.stanford.edu>
> Sent: Friday, June 28, 2013 12:24 PM
> Subject: Re: [liberationtech] a privacy preserving and resilient social
> network
>
> [...]
>
>>Congratulations! Your job is now to figure out how to make it faster
> while keeping the same privacy guarantees. You don't get to opt out,
> because you can't do any meaningful work until you've done this.
> Actually it looks like there might be meaningful work here on the mirroring
> front. Mirroring content on trusted friends' machines is something the
> Freedombox folks mused about, and the video demos what looks like
> a user-friendly implementation of the same idea.
>
> Just curious, Eleanor-- once you implement your "bullet-proof" privacy-
> preserving network, how do you plan to make the user experience at all
> tolerable without automated mirroring like what this developer has written
> and tested?
>
> Of course this is all moot while the license of "it's free and open, as long
> as you ask me first and I agree" is in effect. I can't imagine anyone
> taking
> a serious look at the code with that.
>
> -Jonathan
>
> -Jonathan
>
> E.
>
> - --
> Ideas are my favorite toys.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iF4EAREIAAYFAlHNuKUACgkQQwkE2RkM0wr0/wD+IVTnHPuZzNSs6hqEIP0gyaiQ
> 8J351/zcc6UWICx6suEBAIVLljasG1kp4vOMjwCclkxYdOFcsfQBJSAp2zjvWX7D
> =cHDZ
> -----END PGP SIGNATURE-----
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Alireza Mahdian
> Department of Computer Science
> University of Colorado at Boulder
> Email: alireza.mahdian at gmail.com
>
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
More information about the liberationtech
mailing list