Re: [GNUnet-developers] Re: [Freedombox-discuss] The message from Tahrir Square

[Toni Ruottu]

You could prioritize content based on a previously formed web of
trust. Governments sending high priority reports do not matter, if I
only forward your traffic and never theirs. That said, maybe there are
ways to measure geographical connectivity and provide best service to
nodes providing us with the best geographical connectivity.

On Sun, Feb 20, 2011 at 10:17 AM, Christian Grothoff
<address@hidden> wrote:
> Hi!
>
> Mike Johnson's general premise, dynamic mesh routing via multiple physical
> access methods, is something GNUnet will be able to do.  We are working on ad-
> hoc wireless communication and have recently had some initial discussions
> about satellite communiction as well. Our general design would certainly allow
> any of these forms of point-to-point communication, but doing them well may of
> course require additional work.
>
> The content prioritization mentioned by Mike Johnson also does not seem to be
> possible -- what if the adversary simply participated in the network and
> published "high priority" reports?  GNUnet currently tries to balance this by
> giving higher priority to those providing more resources, but that may not
> always match the desired priorities of some user groups.  So solving this in
> the manner you seem to envision seems to be somewhere between self-
> contradictory and technically impossible to me.
>
> At least for GNUnet, I also consider providing "the Internet" to be a
> suboptimal part of the solution --- ideally, the system should provide
> decentralized implementations for common services found on the Internet.  That
> is not to say that being able to exit to the Internet should not be done, but
> especially given that access to long-distance services is more easily
> disrupted, integrating them in a distributed manner also has advantages with
> respect to censorship-resistance (in addition to privacy protections).
>
> Now, not having "any" exploits or bugs that could be exploited in the entire
> system (including OS), that I cannot promise ;-).
>
> Finally, I do think that the success of any solution will ultimately require
> ease of use.  Once we have the low-level technical details right, I believe
> this will be the final big challenge, possibly just as big as the technical
> challenges before.
>
> Happy hacking,
>
> Christian
>
> On Sunday, February 20, 2011 08:15:23 am Michael Blizek wrote:
>> Hi!
>>
>> I have found this email on the freedombox mailing list and guessed that you
>> might be interested. Do you think GNUnet can be "bent" to do something like
>> this?
>>
>>       -Michi
>>
>> P.S.: Everybody, please use group reply for this thread
>>
>> On 19:16 Sat 19 Feb     , Mike Johnson wrote:
>> > Hello All,
>> >
>> > I am a college student with limited background in any open source or
>> > professional projects.  I have mostly just tinkered with programs on my
>> > laptop in my free time while in school.
>> >
>> > I wanted to take a moment to throw my two cents because I think this
>> > idea above all others should be the core focus of this project.
>> > Primarily protecting the free flow of information between the
>> > FreedomBoxes, and secondary protecting its flow from a low bandwidth
>> > area to a high one.
>> >
>> > If the network is in a state like Egypt's was, or like Lybia's is today
>> > the FreedomBox network can have no single exploitable weakness or
>> > dependency.  As the designers of this network we must assume that if a
>> > flaw exists it will be exploited.  I think that this is a far more
>> > ambitious design challenge than some may realize.
>> >
>> > Even with a wireless mesh network, we can't assume that it will be
>> > structured ideally.  If one area of the network connects to another in
>> > too few nodes all that's required to cut off access to an area is that
>> > they start jamming the Wifi in that one spot.  What if that one spot
>> > cuts off an entire city?  Worse, we cannot assume that a state such as
>> > this has not been watching the network for months to see who has
>> > FreedomBoxes and has been locating weaknesses and choke points in
>> > advance so that when the time comes to throw the kill switch it is done
>> > quickly and effectively.  If we fail at this design challenge the end
>> > user will not know if there is anything they can do to fix it.  They
>> > will not know that the only thing they may need to do to restore access
>> > is move one person's Box 50m to the left so it won't be jammed.  All
>> > that they will know is that we promised them internet access when when
>> > the going got tough and that they don't have it.
>> >
>> > We also have to assume that this oppressive state has read all of our
>> > code any knows about any bugs if there are any, knows about any exploits
>> > in the OS, has read all of our documentation, has read all of these
>> > emails, has mapped the network on any and all physical layers the box
>> > may operate, and that they posses the money, influence, or manpower to
>> > execute an attack on our network.  The success or failure of this
>> > project will not be judged on how good the UI looks or how well his Box
>> > runs one piece of software over another, it will be judged by its
>> > ability to provide bandwidth when the most oppressive state imaginable
>> > is executing a coordinated attack on the network.  The FreedomBox must
>> > be secure as well as dynamic.
>> >
>> > In my opinion the box needs to be a chimera of network interfaces,
>> > having software to operate over as many physical media as possible, be
>> > it Wifi, Ethernet, HAM radio, Satellite,  Dial up, whatever is possible.
>> >
>> >  It also needs to handle nodes being physically attacked or virtually
>> >
>> > attacked.  It will probably also need to prioritize content because
>> > Citizen A might be trying to send a warning Tweet to his friends about
>> > how the oppressive state has begun massacring people while Citizen B
>> > might be trying to watch a video of a cat on youTube and the only link
>> > between Citizen A and Twitter is a single Wireless b card on a laptop on
>> > the other side of the city that is a decade old.
>> >
>> > One might argue that he should have sent the message on whatever
>> > FreedomBox messaging system that would have allowed his friends to get
>> > the message, but we can't assume that Citizen A can differentiate
>> > between "The Internet" that gives him Twitter and "The Internet" that is
>> > our FreedomBox network.
>> >
>> > Now, I'm not trying to be negative.  I think that we can build this and
>> > I am very willing to devote time and effort with the little experience I
>> > have to such a project.  I just wanted everyone to step back a moment
>> > and think about the scale of protecting the free flow of information.
>> > We must always have this oppressive state in mind as we design these
>> > Boxes and what it is that we are promising to the people as developers.
>> >
>> >  Not to be grim, but it could be a matter of life and death for hundreds
>> >
>> > of people if Citizen A's warning never makes it.
>> >
>> > I know C and Java (probably not applicable on such small hardware) and
>> > will work on whatever is needed.  But I will be balancing work and
>> > school at the same time.
>> >
>> > Best Regards to All,
>> > Mike Johnson
>> >
>> > On 02/19/2011 03:51 PM, address@hidden wrote:
>> > > I think those of us old enough to remember UUCP will be aware of the
>> > > merits of store-and-forward protocols. Obviously, if you have a
>> > > reliable live Internet link you'll use that, but as we've seen in
>> > > places like Bahrain and Libya this week, or Egypt last, continuous,
>> > > reliable live Internet links are not things that people whose freedom
>> > > is under threat can rely on. So a system of opportunistic
>> > > store-and-forward proxies which allow a node to get a message to a
>> > > node just a little bit closer to the Internet, which can get
>> > > information out even when links are partial, patchy and discontinuous,
>> > > should I think be part of the FreedomBox concept.
>> > >
>> > > UUCP itself exists as a package in Debian stable. It can run over TCP
>> > > with SSL, but does not need to. However, UUCP addressing depends on a
>> > > known path from node to node. But in situations where Internet
>> > > communication has been cut by an oppressive state, known paths to the
>> > > public Internet will not be available; a message must necessarily be
>> > > broadcast opportunistically to any node which may subsequently get a
>> > > better connection. I don't know of any existing stable package which
>> > > will do this, although Freenet developers have certainly discussed the
>> > > problem.
>> > >
>> > > But if FreedomBox is to be anything more than a toy for geeks in safe
>> > > and stable Western democracies, this is a problem we need to address.
>> >
>> > _______________________________________________
>> > Freedombox-discuss mailing list
>> > address@hidden
>> > http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnunet-developers
>