social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Social-discuss] A question of bandwidth in terms of privacy


From: Andrew Gray
Subject: [Social-discuss] A question of bandwidth in terms of privacy
Date: Wed, 24 Mar 2010 03:51:47 -0700

Hackers,

I'm no expert in these matters, but I've been pondering over a few
things concerning prospective GNU Social implementations. As I've seen
elsewhere on this list, feel free to sort the nonsense from the
legitimate concerns.

I'm very much interested in how GNU Social is effectively redefining the
ideas behind how we communicate over the Internet (using essentially
existing methods), and one of my biggest concerns is about
centralization/distribution of the protocol.

XMPP, as others have stated, a very promising way to establish presence
over such a social network, and something else established on this list
is the concern over domains one does *not* control (i.e. facebook.com)
having a monopoly on the connectivity. Here were my thoughts on that
(and please hang in there):

1. Facebook has at least one thing right: the amount of bandwidth you
have to expend in order to establish sure lines of communication with
your friends (though at the cost of privacy) is relatively low. Would it
seem outrageous to, at first, use a single XMPP server (daisycha.in?) to
establish the concept of presence for the purpose of data transfer? 

2. Once the protocol and system is established, just about anybody could
run their own XMPP server for presence establishment, making groups of
geographically near friends' connectivity much faster, while providing a
means to connect to those on separate (address@hidden)
XMPP/GNUsocial servers.

3. An idea I rather like for security is modeled here, using GPG
extensively for security, at the cost of a SHARP increase in bandwidth
for **everyone**. (Think Freenet, only worse). I'm using this as a
concrete example, something to look at; whether this is the final method
(I hope not) is not my point.

/******************************************/
/******************************************/

  A. Alice, Bob, Carol, and David are all users of GNU Social, and are
all mutual friends of each other, though on separate XMPP/presence
servers. Each has a private GPG key, and each has each other's public
GPG key. For the purposes of this model, they are all mutual friends on
the network, but have no other mutual friends.

  B. Alice is the only one of these friends online. She requests David's
profile. This request (request.Alice.profile.David+MessageID) is queued
for delivery.

  C. Carol gets online, and through XMPP's presence system, Alice
becomes aware of her on the other network. Alice's queued profile
request is sent to Carol (since they are both friends of David). Alice
goes offline.

  D. Bob comes online. Carol sends request.Alice.profile.David+MID to
Bob.

  E. David comes online, with his freshly updated profile. Bob and Carol
both submit request.Alice.profile.David+MID to David. David's client
safely ignores the duplicate request, thanks to the MID.

  F. David encrypts his profile using D's private GPG and A's public
GPG. Initiate send.Alice.profile.David+MID to Bob and Carol.

  G. Bob and Carol exchange a check.Alice.profile.David+MID, and
establish that they both have send.Alice.profile.David+MID, so
re-sending the data is not necessary; they both have it.

  H. David goes offline. Carol goes offline. Bob is still online when
Alice finishes class and checks her GNU Social. Bob's client initiates a
check.Alice.profile.David+MID, and verifies that Alice does not have
David's profile.

  I. Bob (who could not read David's encrypted profile transmission)
sends it on to Alice, who easily decrypts the data and enjoys reading
about David's new favorite movies. MISSION ACCOMPLISHED.

  J. Carol and David come back online, and exchange a MID check with
Alice, who affirms that she did indeed receive the encrypted profile
data, and there's no need to send it again.

/******************************************/
/******************************************/

4. PROS/CONS

Benefits: Profile data can have different levels of privacy for each
friend, for example if David would rather Alice not be able to read
about his exploits with Ellen the night before, David need not send it
to Alice. Also, thanks to GPG, nobody along the "daisy"-chain is able to
read the message before it arrives at its final location. Security++.
The data is never sent to the servers, only between friends.

Drawbacks: Too many to count. This adds extensively to the already quite
extensive XMPP overhead. I was reading that some 60-70% of all XMPP
traffic is overhead for presence establishment, and since XMPP data
transmission without Jingle must convert binary streams to and from a
base64 translation to allow it to coexist within the XML standard of
XMPP. That's (excuse me) a shitload of bandwidth, once aggregated with
all other traffic.

Something to consider, though, is that if all of this data *is*
encrypted with GPG keys, there's no reason NOT to send it to the servers
(though that does increase the server load and storage dramatically).
Nobody could read it there anyway (except the intended recipient).



Just something that's been bugging me. I had a dream about this system,
woke up, and decided to type it out. Hope I was coherent.

--Andrew Gray (Sweetandy)
address@hidden
Happy hacking!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]