[Freedombox-discuss] CCC Meeting Notes

Tue Aug 16 12:24:37 UTC 2011

On 15 Aug 2011, at 15:40, Isaac Wilder wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello All,
> 
> This is Isaac Wilder, from the Free Network Foundation. I convened a
> meeting at Chaos Communication Camp a couple of days ago, in order to
> talk about FreedomBox, FreedomNode, and Free Network Architectures. I
> told those in attendance that I would type up my notes from the
> meeting, and send them to the list.

Thanks for organising the meeting Isaac.
Below are a few extra pointers.
> 
> 
> To start, I presented what I saw as a workable architecture: several
> protocol daemons connected by a 'graph' or 'identity' manager that
> handles access control. We came up with the following list of
> essential daemons, in approximate order of priority:
> 1)HTTP
> 2)XMPP
> 3)SIP
> 4)IMAP
> 5)TOR
> 6)NMTP
> 
> As far as daemon selection goes, there was (general) agreement that we
> should use Apache for HTTP (despite its weight), Prosody for XMPP, and
> Yate for SIP.
> 
> We also discussed UI, stressing its paramount importance to the
> success or failure of the endeavor. The idea of having the user
> configure and interface with the box via chatt (XMPP chat) was
> suggested. There's also always the fallback position of a web GUI.
> Still, many felt that the chat idea has great potential.
> 
> Then, we chose to approach the discussion from the angle of open
> problems, both short and long term:
> 1) The ability to generate good random numbers
> 
>    a) We could foster the development of a free/open entropy key.
>    Problem with this solution is cost.
>    b) We could fetch randoms from a trusted upstream source. Problem
>    here is with the first Diffee-Hellman exchange.
>    c) We could feed a noise-generating circuit into the audio
>    interface. This seems like a viable solution on the DreamPlug, but
>    is not an option on some hardware.

Is there a social way to get some verification that the numbers generated
are random, so that one can spot bugs in whatever mechanism is chosen?

> 
> 2) How to build robust, no-hassle mesh networks.
> 
>    a) B.A.T.M.A.N. protocol is good, but people have been having a
>    lot of success with the new OLSRd. FunkFeuer has had great results.
>    b) The problem is with the radios. A single, embedded 2.4Ghz radio
>    will not lead to good QoS, plus it should probably be reserved for
>    communicating with client devices inside the home/business.
>    c) The Free Network Foundation is designing FreedomNode, which is
>    essentially the same as FreedomBox but with the addition of two
>    5GHz radios, allowing for multiple full-duplex mesh links.
> 
> 3) Free Drivers (wifi and bluetooth drivers are closed)
> 
>    a)Argue with Marvell
>    b)Reverse Engineer
> 
> 4) Persistent Names (which don't rely on existing DNS)
> 
>    a)Name resolution based on a DHT. Problem with table poisoning
>    could be approached by authorizing and authenticating those that
>    participate in the resolution table. This would still introduce a
>    degree of hierarchy, but it would be far more distributed than
>    what we have now.

I came up with a sketch of an httpk scheme on the freedom box list some time ago.

  http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html

I am interested in developing such a protocol. It could be done using just simple
HTML forms to get going. 

John Gilmore was the one who pointed out the problem of hash poisoning to me, btw.

>    b)Use TOR hidden services. This solution is good for those that
>    are running tor, but otherwise require use of tor-to-web. Also,
>    the .onion names are not human-readable, so would require further
>    resolution via the mechanism above, or existing DNS. This was a
>    topic of much controversy. Many feel that it is unnecessary to
>    route all FBX traffic through TOR.

Is there a good link to .onion urls ? Wikipedia does not mention those. I am wondering if .onion urls can be resolved using DNS or if they require a special protocol. If they require a special protocol, then one can't simply write 

http://1231231231.onion/ because the http URL spec requires DNS resolution there. One would need to a number
of onion schemes otherwise.

> 
> 5) Grid Dependence (electrical)
> 
>    a)Add PV cells to rig. (Again, $$$)
> 
> 6) Store and Forward Messagaing (The ability to store messages until
> they become deliverable)
> 
>    a)Utilize Shamir's Secret Sharing Scheme (SSSS), gather physically
>    and exchange via radio.
> 
> 7) Archiving Proxy that maintains privacy and security
> 
> 8) Distributed Backup
> 
>    a)Tahoe LAFS
>    b)Pagekite
> 
> 9) Bitbank
> 
> 10) One Time Passwords

yep always useful. 

Perhaps also crypto keys. The second video here http://bblfish.net/blog/2011/05/25/
shows where the technology is now. (The cryptostick people say they should have a 
few improvements soon)

> 
> 11) Distributed Search
> 
>    a)YaCy
>    b)Seeks

yep. Also one may want to look at work in the semantic web for this using SPARQL. 

> 
> 12) Stealth Hardware
> 
>    a)Sell a version wrapped in some other shell
> 
> 13) Access control
> 
>    a)Friend of a Friend
>    b)Case by case + key rating system

http://webid.info/ has a short video showing how foaf can be useful here. Btw. on the WebID list we had a presentation of some work for the NSTIC, National Strategy for Trusted Identities by Francisco Corella. This led me to develop a little how one could use WebID to make CAs themselves work in a web of trust way

http://lists.w3.org/Archives/Public/public-xg-webid/2011Aug/0017.html

> 
> We also talked about the incentives for building such a device:
> 1) Help fight central central control
> 2) Enable communications that are materially peer-to-peer
> 3) Enable local verticals
> 
>    a)Filesharing
>    b)Local information sytems
> 
> 
> 4) Co-ownership of the PHY layer
> 5) Save money by building access cooperatives
> 6) Become our own ISPs
> 

In a very interesting conversation with some folks from la Quadrature du Net at cccamp one of their members (not sure who now) pointed out that you could get allies in the following domain: 

 - housing
 - medical
 - food
 - electronic devices
 - security 

As houses become more an more intelligent, with fridges able to keep track of the food available, and able to order food, with houses being able to control lighting, heat, and cooling, movement of people in the house (did an elderly person fall down the stairs? ), access control to the house (friends can come while one is on holidays), there will be a need for a house control computer to keep track of all of this in a privacy protective way. Because there will be so many different players, it will only work if everything is standards based.

> 
> In addition, there were some trains of discussion that do not fit
> neatly into any of the categories above. We talked about the
> importance of thinking about how technology is actually adopted in the
> real world. It is picked up first by power users, and then friends and
> family take their tech cues from those their trust and respect, or
> from their local technology shop. What incentives do the technically
> inclined have to recommend this solution to their friends? What about
> the people running a small computer store or internet cafe?

We need to use the network effect of social networks. In my philosophy of the Social Web talk http://bblfish.net/tmp/2010/10/26/ I go into this in great detail. Social networks and data networks have network effects that are exponential and much greater than Metcalf's law.

> 
> Finally, I talked a little bit about why the FNF is involved in FBX
> development, and what we'd like to build using the box as a platform.
> I'll summarize it quickly, here, but there's more at www.thefnf.org,
> if you're interested.
> 
> We'd like to add two 5Ghz radios to the rig, enabling it to establish
> high-throughput links to other boxes in the neighborhood. We call this
> FreedomBox + radios rig a 'FreedomNode.' We're also working on what
> we've been calling the 'FreedomTower.' This is a piece of
> infrastructure that would have 5GHz radios and sit inside a mesh of
> two to three thousand boxes. It would also have 3650MHz for long-range
> links to other towers, thus forming a regional mesh network. Finally,
> inside the regional mesh there would be a single 'FreedomLink,' - a
> multi-homed, fiber-connected host, sitting in the 3650MHz regional
> mesh, and speaking BGP to the global internet. This is a practicable
> way to build Autonomous Systems that are owned and operated
> collectively. Of course, outside lines could also be connected at any
> level of the hierarchy (box, tower, link), and shared among the
> community.  The vision is large in scope, but the first step is
> definitely to bootstrap the FreedomBox.
> 
> Anyways, I hope that this all will jump-start some discussion.

Great. If that layer can be built in a nicely layered way, it should not have any impact on the application layer above. If it does it is important to work out what that may be. 

Great camp,

	 All the best,

		Henry Story

PS. I am still in Berlin until the end of the week

> 
> 
> 
> take care,
> Isaac Wilder
> Directer, The Free Network Foundation
> www.thefnf.org
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJOSSHNAAoJEA8fUKCD77NLF9wIAJPSz05hlhwWGAyzSrK/9WPU
> WL07RQ9WDu9aP9IoDs2GYIc7VmM3ChAWirtvHoutFjq1QWUtO7yu7OvJ/Gt8154/
> wlqX2dIB/vNqIFmDHDFxfGu4QJJuS6KMaAT1cau1LOo3fwkXY7t+YQi2o82uUBjn
> 7iRO+w8qTQGmNNofG63M8Bvuq+XMAnO0ztH16/8Kkv45iOOylFkeeW1Q7aEiw+m2
> lWMJ18DEvX9skjSh/0TibuvzZ+W/6TKw/td3DntzSreIDfALgJ80Tdfzfy0eLOAW
> gxWnND/FgrU0Rh5w6gn7VeWWh9oOLKggUrgeewAM+9JhnrBN/Z0U6E3ZcegbmwE=
> =rpT5
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss

Social Web Architect
http://bblfish.net/