Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] a privacy preserving and resilient social network

Eleanor Saitta ella at
Fri Jun 28 21:58:40 PDT 2013

Hash: SHA256

[apologies for top-posting]

There are different kinds of linkability that matter.  Linkability
from an external adversary and my ability to identify myself to a
friend are unrelated.  If we posit a Facebook where I only connect via
Tor, only post encrypted content, and also post chaff content so the
service can't tell what content is even real, the other people who I
a) tell the username to, and b) give the encryption key to can still
use the network just fine -- from their perspective, it's the same
experience.  The difference is that from an outsider's perspective,
it's noise -- they can't tell who's connecting to the service, how
much traffic they're sending, what it is, or who's reading it.

Location privacy is a critical part of unlinkability.  If I can tell
where people are located in the physical world, I can use that to
reverse engineer an otherwise pseudonymous social graph and
disambiguate social graph chaff, as is provided with your mirroring.
Likewise, message transit times when all connections are observable
will serve to distinguish between initial post propagation and mirroring.

Services that attempt to provide deniability have an interesting
problem to deal with.  Deniability is poorly defined (c.f. the
difference between hidden volume deniability in TrueCrypt and the
deniability property in OTR).  In each case, they're trying to use
technical properties of a system to enable a user to perform a certain
kind of real-world falsehood.  Enabling your users to lie has (at
least) two failure modes: the first is that the lie isn't complete
(for Truecrypt, maintaining hidden volume confidentiality is
sufficiently difficult that I'd call it field-impossible for most
moderately technical users faced with a competent forensics
technician), which means that you may be encouraging them to take
risks that will get them caught and in more trouble than otherwise,
while not giving them the degree of security they expected.  The
second is that the lie isn't plausible -- in theory, after keys have
been published at session end, another user could fake an OTR message
as having been part of that session.  However, given a wiretap taken
to even the most minimal level of forensic standards, no judge will
ever find this plausible when presented as evidence that a separately
captured transcript might have been forged.  Again, the feature is
non-functional in the real world.

Services that claim to provide a form of deniability have an
exceptionally high bar to reach to prove any degree of field utility.
 Deniability features often make protocols much more complicated (see
mpOTR) for no real gain.  Thus, I would claim that barring further
research (both field and protocol), it should be avoided as a protocol

I am a very strong believer in distributed systems.  They are key to
any freedom we may regain online.  I also see very clearly that the
set of privacy properties that we believed were necessary are
different than we previously understood, and that we need to change
the systems we research immediately in reaction to this.

Yes, Tor is slow.  This doesn't mean it's ok to say that "well, I care
about user experience, therefor we have to give up on network
unlinkability".  You'd never dream of saying that about
authentication, right?  Well, now you've got another thing you have no
choice but to deal with.


On 2013.06.28 15.01, Alireza Mahdian 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.

- -- 
Ideas are my favorite toys.
Version: GnuPG v2.0.17 (MingW32)


More information about the liberationtech mailing list