social-discuss
[Top][All Lists]
Advanced

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

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


From: Story Henry
Subject: Re: [Social-discuss] Control own privacy, posted by _others_
Date: Sun, 11 Apr 2010 00:02:55 +0100


On 10 Apr 2010, at 20:57, elijah wrote:

> 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.

great!

By the way we have a list of ruby libs that could be used for inititial 
foaf+ssl implementations

   http://markmail.org/thread/4lyisousqz3waath



> 
> 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.

  That should be easy to add. We just need an ontology that says something like
what creative commons says, such as

  <> data:licence <shareNoInfo>. 

where we could decide what types of licences there are.

In my opinion this is not really as interesting as one may think initially, 
because if I publish in my foaf file

:bblfish foaf:knows jack .

And if you publish in your profile

:bblfish foaf:knows jack .

Those are different statements. In one case I am making the statement, in the
other you are. The meaning of each statement is the same of course (ie the 
set of possible worlds that are made true by the relation), but it is a 
different act. When I say who I know, it should be obvious that I know that. 
There are certain types of mistakes I cannot make when I make a claim to 
foaf:know
someone: at the very least it is clear that I know their name, and that I am 
making
the statement. This is not dissimilar to someone who would say "My hand is 
hurting".
They cannot fail to refer to themselves, and they should be directly aware if 
their
arm is hurting.

Now because it is so easy to link to someone else, and because keeping 
information
about other people up to date is so much work, it is clearly a lot easier for 
you
to say

:elija foaf:knows <http://bblfish.net/#hjs> .

And to let me say who I know .

In any case, if we find that people start publishing info about other people all
over the place - which I doubt will happen at first - because people will
be so taken by publsihing info about themselves, and their relations to others
we could add some kind of statement such as  

  <> data:licence <shareInfoButCheckWithMeRegulary>.

Whose meaning could be something like: you can share but if ever I don't want 
you
to share anymore you have to agree, or I can cut you off my list of friends


> 
> (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).

Ok, so you could just restrict access to that photo, located on your server.
Should be easy to do. We could also have a relation such as

<> retractionEndPoint </delete> .

Which people could publish on their server.  Where people can send retraction 
requests by  POST ing some info at /delete . Mind you, I think any attempt 
to do that is more likely to get people's attention than anything else.

> 
> (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.


Very clearly it should be easy to add a pinging mechanism for a number
of different reasons.

<> talksAboutMe </ref> .

A service could just post a URL to /ref and your server could go check what it 
found
there. More complex versions could send a description of what type of reference
was at the location.

The server could then let the user know what people were saying about you.

I think we really need that, if only just to have a simple way to 
let people know you have added them to your friend list. I would be willing to
work on writing this one up immediately, as I think it is absolutely obviously
needed :-)

> 
> (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.

Ok, would foaf+ssl help? You only show info to people who have identified
themselves?

By the way I have just updated the FAQ
   http://esw.w3.org/Foaf%2Bssl/FAQ

and it goes into some detail on the difference with PGP.

> 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.

What if the communication is pure p2p. If you want info on my server you just
connect directly with https. No intermediary is needed.

> 
> 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.

The above are sketches of solutions. Do you see a conceptual 
problem with those sketches? Because if not then we perhaps don't need to 
implement all the solution right now, but can do that in a months time or so, 
when we have some more basic pieces set up, and more people have the skills to
participate in a more detailed discussion.

(( that is partly why I think we should not bother with the legal copying issues
because international legal reasoning and work is very complicated. It took 
Lessig
a few years to get the simple CC licence right)

        Henry

> 
> -elijah
> 
> --
> http://riseup.net/collective
> http://crabgrass.riseup.net
> http://sociology.ucsc.edu
> 
> 





reply via email to

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