[Top][All Lists]

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

Re: [Social-discuss] Control own privacy, posted by _others_

From: elijah
Subject: Re: [Social-discuss] Control own privacy, posted by _others_
Date: Sat, 10 Apr 2010 12:57:41 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100217 Shredder/3.0.3pre

On 04/10/2010 09:36 AM, Rob Myers wrote:
> On 10/04/10 16:47, Hellekin O. Wolf wrote:
>> When designing social software, and thinking about these issues, one
>> has to be careful with terms and concepts.
> Do you have a good example of a positive conceptual framework for
> thinking about social software?

I have been quiet on this list for a while. Despite the distraction of
debates over language and platform, my hope is that some useful and
agnostic protocol will shake out of this process.

If a protocol with sufficient utility and privacy is worked out, I will
be happy to write a ruby implementation for rails.

Personally, however, I have a few requirements for any protocol that I
would consider worth while. It must pose a serious challenge to the
current model of social networking as currently practiced... where the
service is paid for by targeted advertising and surveillance is the
business model.

For me, the requirements for a privacy enhancing protocol would look
like this:

(1) Social Graph: You must be able to indicate to your friends whom they
may share information about you with. Obviously, they don't have to
follow your desires, but if you trust them enough to be their friend,
then you should trust them enough to respect your privacy. The options
might be to share the existence of a friendship: (a) to no one, (b) to
mutual friends, (c) to friends, (d) to everyone. Everything else can
happen at the application level, I think.

(2) Recall: By some push or pull means, you have let people know about a
new photo of yourself passed out with demeaning messages written over
body. Hilarious. When the fog lifts, you should be able to recall those
announcements. Yes, the application level is responsible for actually
changing access to the image, and yes, maybe some people have already
seen it and archived it locally. However, you should still have the
ability, as a courtesy to the UI, to notify other social networking
services that the image is no longer available to particular users
(either because it was destroyed or they don't have access anymore).

(3) User tagging: as mentioned previously on this list, the protocol
should support some way of being notified when someone associates your
identity with some content and also a way for you to remove this. Again,
irresponsible social network software does not have to follow this, but
responsible social network software needs a protocol level method of
making this easy to do.

(4) Routing privacy: There is a big problem with PGP in that the headers
for routing do not have any privacy protection whatsoever. The whole
point of social networking software is that the social graph is
amazingly powerful. We live in odd times: your membership in
organizations is constitutionally protected in the US, but current
jurisprudence says your social graph is not private data. What exactly,
is the difference? I think current research clearly shows that the
social graph is more sensitive. For example, the research done to
identify someone's sexual orientation simply by their social network.
So, for me, routing privacy is an absolute must for any useful protocol.
There are many options for routing privacy, but I think a workable
solution might look like this: allow that each person will have a
routing gateway, and that this gateway will know the real identity of
its users. Users can run their own gateway, or use a cloud service. The
gateway receives routing addresses in one of two ways: (1) the actual
recipient routing information has been encrypted with the gateway's
public key (by the client of the sender) or (2) the recipient
information is anonymized on a per-subscription basis and the mapping is
resolved by the user's gateway (ie address@hidden gets
delivered to address@hidden). The goal is to make it so that only my
gateway, and the sender's client, are aware of the actual route (and not
any of the servers in-between or MitM). This principle holds true for
either push or pull communication.

I agree that most control is best pushed to the application level.
However, there are some privacy aware things which must be built into
the social protocol in order for privacy respecting services to be able
to work well together. I think it would be a great tragedy if something
came out under the auspices of the free software foundation that was
unable to take these vital privacy concerns into account.



reply via email to

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