Re: [Social-discuss] Privacy-over-Webfinger Draft

[Natanael]

(Sending again so the list gets it)

Your anonymization suggestion sounds a lot like i2p. Gnu social could likely work over it unmodified.
http://www.i2p2.de/

Den 15 jul 2010 13.47, "Blaine Cook" <address@hidden> skrev:

Thanks [everyone] for the feedback! These are exactly the sorts of
details and trade-offs we need to sort out.

On 15 July 2010 03:58, Ted Smith <address@hidden> wrote:
> On Wed, 2010-07-14 at 02:34 +0100, Bla...

> An editing note - you use the phrase "reader" in section 3, but it seems
> like after that, you us...

Yes - there was a change in terminology, something got mixed up.
Thanks for catching that. :-)

> The sort of thing in Figure 4 unnerves me - that sort of transparency in
> the origin of a reques...

The trade-offs here are not easy. If the data is just up on the
internet, how do you signal to someone that they should fetch it? You
could use Tor and poll your friends for updates, but that means that
your latency will be *extremely* high, and that Tor would become a
massive heat score (i.e., the incentive for attackers to "own"
sufficiently large chunks of the Tor network becomes high enough that
they will, and the privacy that you're trying to precipitate
disappears, without you knowing it).

Keep in mind that in order to discover the social graph (assuming the
use of SSL), an attacker would need to gain control of either the
Client or the Content Server, and then would only be able to determine
links between users on the Client and Content Server. In a P2P
scenario, this could be accomplished by installing malware on the
target user's computer – something that's not at all difficult to do
for the vast majority of cases.

Moreover, it's important to not lose sight of the goal; people will
only use a social network if it's possible to see the relationships
and interconnectedness inherent in the graph. Our real-world social
interactions do not happen in "cones of silence",

A thought experiment (I don't know if this will address your concerns
fully, but it's worth a shot):

Given the scenario where sender identity is to be hidden from
attackers who have access to either the Client or Content Server, what
if we used an HTTPS-based mix network? If we can send messages from
HTTP point A to HTTP point B, then we can essentially construct
Tor-over-HTTP.

This provides both the desired addressability and anonymity
properties, and decomposes into something I can build and experiment
with using little more than netcat and telnet.

> I'm not sure if this is permitted by your specification, however. I'm
> not really good at readin...

To elaborate a bit, yes, as above it is permitted. Really, the only
real constraint (and this is a social constraint that I am trying to
support [not enforce] with technology) is that the *publisher* must
know who the *user* is, so that the publisher can make a decision to
share-or-not-share data with the user based on [[whatever metrics the
publisher cares about]]. Ideally the user would be able to trust that
they were receiving messages from a verifiable source, too.

> Is that included in "Plenty"? :-P

Yes :-D