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

[Blaine Cook]

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, Blaine Cook wrote:
>
> An editing note - you use the phrase "reader" in section 3, but it seems
> like after that, you use "user" where you want to say "reader".

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 request reveals the social graph to both the client and
> the publishing server. I'm not quite sure if there's a way to avoid this
> while still doing authentication of the type you propose; in Social-P2P
> we avoid this by simply giving encrypted data to anyone who asks
> (Diaspora, I hear, will do the same thing). It seems to me that the only
> way to protect the social graph in this case is to use public-key
> cryptography; if the user and publisher can have an exchange that's
> encrypted end-to-end, then they can utilize crypto at key points to
> ensure that the client and content server don't know who's talking to
> whom. This also allows you to forgo the question of whether the user has
> delegated to that client, since the client is no longer trusted with
> either the data being requested or the social graph.

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 reading this sort of draft, but it seems like the
> content server MUST know the originating user, and since they have to
> know who the publisher is, it seems like the social graph is irrevocably
> compromised.

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