[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Creating distributed social networks with WebId behind Tor



On 15 May 2012, at 21:25, miniBill wrote:

> Quick feedback:
> 1) nice idea

thanks.

> 2) tor hidden services already have transport level encryption

Yes, this is a point worth exploring. The advantage of https for
WebId is that the TLS protocol comes with the tools for the server
to ask for a client certificate, and that this is built into all 
browsers (desktop ones at least). It is also very useful for robots
since they can then do work on behalf of the user, and authenticate
as themselves or as the user they are working for, without one 
needing to develop a login protocol.

Does Tor have its own method for the server to request the client
certificate too? Then one could apply the webid principles to that
protocol too.

If the issue is minimising the number of encryption layers needed then
servers behind TOR could negotiate the null encryption layer. Clearly
that would have its own issues. There may be other ways to do this...

> 3) there are plenty of https hosts providers, but no .onion ones

I am working with the initial assumption that we would have our own
freedom boxes. Would that address this point, or have I misunderstood it?

> 4) this requires every user to have an always on machine

Yes, that would be possible with a freedom box. I am assuming that in this
set up as it simplifies the architecture at this point. 


> Il giorno 15/mag/2012 11:55, "Henry Story" <henry.story@xxxxxxxxxxx> ha
> scritto:
> 
>> Hi,
>> 
>>  Recently in Berlin I was lucky to met Jacob Applebaum at the CCCB as he
>> arrived to talk at the re:publica conference. I had been wondering for some
>> time if it would be possible to use WebID for distributed social networks
>> using linked data behind Tor, but I had not yet had time to make it a
>> priority . From the discussion with Jacob, it seems like this should be
>> feasible, and indeed relatively easy, but of course only real
>> implementations can tell.
>> 
>>  Here of course a bit of background on WebId is needed (
>> http://webid.info/spec/ ). There are a number of ways of thinking of
>> WebID. At one level it is an application of mathematical logic and web
>> architecture to the  problem of identity. At another it is a philosophical
>> hack of TLS, whose effect is to shift the Trust in TLS from a hierarchical
>> system into a web of trust.
>> 
>>  To understand its power one has to understand LinkedData and RESTful web
>> services. But those are in fact exceedingly easy: REST is easy and well
>> known, and LinkedData is just the idea that one applies the concept of
>> hypertext to data - indeed some have called it hyperdata. Hyperdata allows
>> one to create distributed social networks, the same way we have created the
>> world wide web - allowing each individual person or organisation to control
>> access to their data (web site). Place the web site behind Tor, use .onion
>> URLs and you now have a web site - as I understand it - that can't be
>> located by IP address. Place your (linked-)data behind tor, use .onion URLs
>> and you should be able to publish data without anyone knowing where the
>> server is. This of course creates issues of trust, and this is where
>> distributed Social Networks can help.
>> 
>> In order to understand distributed social networks built using LinkedData
>> it helps not to start with TOR. Indeed
>> it helps to start without TLS, and just use plain HTTP. This way we have
>> been able to create distributed social networks
>> with millions of users using the foaf (friend of a friend) ontology. ( I
>> go into how that works in detail in a presentation
>> "Philosophy of the Social Web" http://bblfish.net/tmp/2010/10/26/ ). But
>> of course that does not address the serious issues of privacy. So this lead
>> me to add a layer around http with TLS and use client side certificates to
>> identify people in a distributed social web that can use access control to
>> limit who can see what. ( the http://webid.info/spec/ has a diagram that
>> makes that clear ). But TLS with WebID still reveals the users IP address.
>> So this is where we should be able add another layer to our onion: Tor.
>> 
>> All we need are Tor onion URIs. Place an onion URI for your profile in
>> your X509 certificate and you should now be able to authenticate to any web
>> site without the server you are authenticating to knowing where your
>> identity Profile is located. If that server wishes to know more about you
>> than your public key, your server can let it know as much or as little as
>> you wish it to know by requiring it to authenticate with WebID and then
>> calculating its position in your web of trust. (WebID is a recursive
>> protocol). In such a social web you can allow your friends to post to your
>> wall, and you can interact happily as if you were on Facebook, but with no
>> big brother in the loop. Anyone else will just see your onion URL and a
>> public key.
>> 
>> There is a short screen cast showing how this works with current browsers
>> at http://webid.info/ .
>> 
>> So how does one proceed to test this out? I think there are a 3 stages,
>> of increasing complexity
>> 
>> 1. build a foaf social web behind Tor
>> 
>>  Instead of links such as the following ( which you can find in my
>> foaf-profile at http://bblfish.net/people/henry/card )
>> 
>>  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>> 
>>  <http://bblfish.net/people/henry/card#me> a foaf:Person;
>>               foaf:knows  <http://www.w3.org/People/Berners-Lee/card#i> .
>> 
>>  you need to write the above using .onion URIs and make those publicly
>> available on the tor network. It should be possible to follow the links
>> from one profile to another, deference the second url and get more
>> information... using well known LinkedData principles. It is best if those
>> files are on different machines to make it real.
>> 
>> 2. if the above works then you can add your X509 public key to your
>> profile as explained in the http://webid.info/spec/
>> 
>> <http://a2342sdsf.onion/profile#me> cert:key [ cert:modulus
>> "...."^^xsd:hexBinary; cert:exponent 65537 ] .
>> 
>> 2.1 then create a service behind tor that authenticates users with X509
>> WebId certificates with .onion urls and see if you can log in there.
>> 
>> If the above can be done, then adding access control is just one more
>> step that is relatively easy.
>> I am currently building a server in Scala that can do this type of work
>> very efficiently, but there are others who
>> have done it already in php/python and C# .
>> 
>> Currently I am focusing on building the server with access control using
>> plain https without Tor. If I am right in believing the above to be
>> workable, then it should be quite easy to add Tor to such a server. Jacob
>> suggested I look at JTor, as I am working in the Java ecosystem
>> https://github.com/brl/jtor . But perhaps others will want to explore
>> some of this before I get around to doing it, or indeed perhaps there are
>> some Scala/Java people who are interested in working with me on this a bit
>> more closely (so we can move faster).
>> 
>> I hope that helps and would be interested in your feedback,
>> 
>>       Henry
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> _______________________________________________
>> tor-talk mailing list
>> tor-talk@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>> 
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Social Web Architect
http://bblfish.net/

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk