[Freedombox-discuss] Store-and-forward is a necessity

Michiel de Jong michiel at unhosted.org
Tue Mar 1 10:02:01 UTC 2011


I didn't read your entire email, sorry. but i absolutely agree
store-and-forward is very important and interesting thing to investigate in
the context of internet freedom. we could do an interesting experiment to
set up a revival of usenet over either WoT or wifi mesh. if we could make
the experiment work that would be a really cool result. putting usenet into
the freedombox would probably be easy, and definitely noone could say we're
reinventing the wheel (although, maybe rediscovering a forgotten wheel)

On Tue, Mar 1, 2011 at 1:02 AM, Tracy Reed <treed at ultraviolet.org> wrote:

> Hello all,
>
> So far it appears that everyone is focused on TCP oriented connection
> protocols which require the freedom box to have a live Internet
> connection, perhaps via mesh. That would seem to me to be missing what I
> see as the whole point of Freedombox entirely.
>
> I, too, have been thinking people need some small and inexpensive device
> which people can use to communicate and get freedom.  I was happy to
> hear of the foundation of this project.
>
> The first thing evil regimes always seem to do is to turn off the
> Internet access and censor communications in general. I keep asking
> myself, "How did people communicate electronically before broadband
> Internet or even PPP dial-up enabled the always-on connections which
> allowed the web to grow?" The answer is store and forward message
> passing systems: UUCP in the case of pre-Internet communications.
>
> More than anything people need a way to ship around messages such as
> tweets, emails, IMs, and smallish files. They need to be able to send
> around simple news and activity coordination items. They don't need
> flash and ajax and graphic heavy webpages. That is for marketing, not
> freedom-giving information exchange.
>
> Wild stream of consciousness brainstorming follows:
>
> Goals:
>
> * Allowing transmission of messages world-wide in the face of active
>  oppression
>
> * Not requiring a dedicated Internet connection
>
> * Encrypted
>
> * Hard to detect
>
> * Location-aware (for routing purposes)
>
> * Provide very basic communications abilities. This is an improvement
>  when people have no ability to communicate at all.
>
> Hardware:
>
> Dedicated freedombox devices
>
> Mobile phones/apps
>
> Communications:
>
> Primarily wifi with wired and 3G Internet gateways as short-cuts via
> systems that support it.
>
> How it works:
>
> There would be a standard messaging protocol similar to UUCP or AMQP or
> SMTP or something (whatever best fits whatever the ultimate system is to
> be). Messages (be they files, SMS, email, whatever) would be fit into
> this protocol.
>
> The whole idea is to get a message from a place that doesn't have an
> Internet connection (presumably because an evil regime has destroyed the
> economy so there is no infrastructure or is actively prohibiting net
> connections) to a place where there is one so that the message can be
> delivered and vice versa.
>
> It would implement a protocol...call it (for lack of anything better)
> Freedom Protocol (FP).
>
> It would have a GPS or be able to be fed its lat/long by a passing GPS
> enabled device communicating to it via wi-fi (such as a mobile phone
> since many of them have GPS and wi-fi in them now). Accuracy isn't
> important. We just want to know what general part of the world we are
> in. Accurate to within 10km would probably even be good enough.
>
> Let's say that I am a revolutionary who wants to send out a message to
> another local revolutionary. I can encrypt a message to his key or send
> in the clear if I don't have it or am not capable. I have a mobile phone
> with wifi and GPS.
>
> Like all FP capable devices, it knows:
>
> * Where we are likely located (via onboard GPS or because someone told
>  it where we were when it last communicated with a GPS enabled FP
>  speaking device)
>
> * Where I generally travel (doesn't keep specifics on lat/long, just a
>  probability distribution because I don't want my phone to tattle on my
>  exact movements, especially if it is captured).
>
> * What the probability of my coming into contact with a wired uplink is
>  (think of this like NTP: call it stratum 1 probability)
>
> * What the probability of my coming into contact with another FP device
>  and its probability of coming into contact with a wired link (stratum
>  2 probability etc)
>
> * It also keeps track of the probability of communicating to a
>  particular part of the world of each of the other FP speaking devices
>  it talks to. This is for routing messages back to the non-connected
>  device.
>
> Assumptions:
>
> * Wifi bandwidth is plentiful but not unlimited while we have it but
>  connections are somewhat rare.
>
> * Connections to the wired Internet from which everything can be reached
>  are rarer.
>
> * Opportunities to transmit/pass along may be limited, especially at
>  first
>
> * Message space is limited
>
> My device wants to hand off this message as soon as possible. They find
> each other via wifi broadcasts. Maybe the above probability info is what
> we broadcast if we can fit it all in a packet.
>
> We want to find other devices and offload our message(s) quickly. We can
> keep a history of what location and stratum probability distributions we
> typically see. From this we can decide how desperate we are to offload a
> message and to whom. We should probably hand off the message to the very
> first device we see just to get it out there, then perhaps more
> judiciously later for either a fixed amount of time (TTL?) or until we
> get a reply.
>
> We come into contact with another device implementing FP protocol. It
> could be mobile (an app running on a GPS/wifi enabled mobile phone), it
> could be fixed (a wall wart discretely hidden away somewhere). We send
> it our message. It weighs the likelyhood that it will be able to deliver
> the message vs available storage capacity. It may drop an old message, a
> message which has already been passed along a number of times or reached
> its (potentially long) TTL, or whatever message it calculates it is
> least likely to be able to deliver (which might even be ours).
>
> You can transmit an awful lot of SMS style text messages quickly via
> wifi. We want to be able to get this done in mere seconds in case we are
> passing by quickly such as in a car.
>
> Our message gets passed along in this way hopefully always getting
> closer to its recipient whose location we specified in general and
> perhaps specifically by encrypting to his private key.
>
> Or perhaps we want to send a message to the free Internet-enabled world.
> We cruise around and it gets sent to a fixed location device nearby a
> busy street. Every hour or two a mobile phone passes by on its way to
> the airport. That mobile phone is going to get on a plane and go
> somewhere in the world.  We know this because of the location
> probability distribution. We know that device within hours is very
> likely to be in contact with a dedicated wired Internet connection. We
> dump every message we possibly can on him, starting with the messages it
> is mostly likely to be able to deliver followed by less likely messages
> because our connection is just temporary and will get dropped as we move
> out of range, possibly while we are still transmitting.
>
> That device lands at the airport in Europe somewhere where it disburses
> its messages to other mobile FP speaking devices. In fact, it probably
> already did so on the plane before everyone turned their phones off or
> even in the departure area while everyone was waiting to board. But it
> might also do so in the arrivals hall although it may not because it is
> satisfied that it has already delivered to enough other devices with a
> high probability of being in contact with a wired connection soon.
>
> In a nearby concesssion along the terminal on the way to the baggage
> carousel someone has discretely stashed a fixed FP speaking device. It
> spends all day receiving and transmitting messages to different parts of
> the world as the FP speaking mobile phones walk by on the way to their
> international flights. Via the probability broadcasts it knows who is
> likely returning to China, to Pakistan, to Venezuela, etc. although it
> only knows these places at lats/longs. There is also a similar box in a
> neighborhood on the main thoroughfare passing almost as many messages
> from the taxis and buses as they go by. Not to mention all of the FP
> speaking devices being carried by passengers furiously exchanging
> messages as they move throughout the airport.
>
> Our message eventually hits one of these devices with a wired or
> otherwise unmetered Internet connection where it hits a gateway which
> converts the message to a tweet, an email, a facebook entry, whatever.
>
> So how do we get return messages or even ACK packets (receipt
> verifications) back? Are ACKs even necessary? Probably not. Certainly
> not at the low level. Let the receiver reply to the message in their
> higher level protocol if they want to ACK it. This is like UDP.
>
> Say our contact (be it a person, a website, a twitter account, whatever)
> in the Free World receives our message, does whatever needs to be done
> with it, and wants to send us a message such as "The Good Guys are
> sending in the cavalry on Monday, sit tight." Or someone could
> theoretically subscribe to a twitter feed via a gateway and have all
> tweets with a certain hash tag packaged up and sent to them.
>
> Their return address would have to be an approximate lat/long where they
> expect to be able to pick up the message. They may even choose a very
> specific lat/long which is nearby where they expect to be able to pick
> up the message but of course never their exact location, just something
> to report as their exact location when picking up messages to ensure the
> message ends up on a nearby FP speaking device and is directly routed to
> them first when they pass by to ensure they get their message.
>
> The message would be routed in the direction of their return address
> wherever possible. The message will either have some sort of To: address
> in the application layer (like email) or it will be encrypted
> specifically to them if they care about privacy. The receiving device
> would receive all of the messages the sender thinks it should have and
> then pick through them for specific messages addressed to them either by
> name or lat/long or whatever.
>
> Would the message from the Free World with Internet access ever arrive?
> Getting to a place with a wired net connection is a lot easier than
> getting from such a place to a specific area or town such that one might
> have a chance to pick up the message. What is the range of the typical
> wifi? Indoors or with various sorts of obstructions let's say 35m. A
> typical freeway has a lane width of 4m. So anyone within 8 traffic lanes
> (a whole freeway width, in the US) is within range. That actually
> creates a LOT of opportunities for message passing.  What are the
> chances that a device will pass another FP capable device on the
> freeway, find each other, and exchange messages? My wifi enabled mobile
> phone sees many wifi access points as I go down the road. How many
> people do you come within 35m of throughout the typical day? I bet it is
> a lot. Especially if you live in a densely populated area or travel on a
> freeway. The chances of coming into contact with another FP enabled
> device depends on how many you can get out there into the world but I
> don't think you would need nearly as many as there are mobile phones out
> there to do some real good.
>
> If a device has 4G of flash available and we set the average message
> size even at 10k we can store a LOT of messages. Do the math. We could
> store messages for such a long time that their chances of being
> delivered eventually actually get pretty high. The speed of delivery
> then becomes a function of how many FP enabled devices are out there.
>
> Why would anyone who isn't a revolutionary run this on their phone or in
> a fixed place device?
>
> You need a killer app to get everyone using it. That would also serve to
> obscure any dangerous revolutionary traffic. You need some chaff to hide
> in.
>
> Something like this could replace SMS messaging. Especially in a
> confined area such as a school, an office, or a small town or congested
> city area where the messages would potentially travel very quickly.
> Teenagers love this sort of thing.  Create an app to run on their smart
> phone. Sell very cheaply FP enabled SMS only devices. Let them spread
> all over the world.  Each device generates its own key, devices can be
> paired like bluetooth so you know who is who and won't suffer man in the
> middle attacks where the devices transparently encrypt the messages to
> each other's keys. Call it "friending". Hide all the complicated fancy
> crypto stuff which would just scare people off, just claim the
> communications to be "secure". Definitely avoid any certificate
> authority type nonsense. Use the ssh trust model. Anyone really betting
> their life on it would be obliged to understand the technology a little
> better.
>
> So it looks like software and mobile phone apps are the best way to go
> here. You could build a physical device and call it a freedom box if you
> really wanted but I would create it with the intention of it being used
> by kids as secure adult-proof communications devices for spreading
> high school gossip. Not a boring wall-wart which nobody will buy
> ensuring per unit costs remain high. But do make it small and with
> ability to connect to an AC power supply so it could function like a
> wall wart and possibly external antenna and be hidden somewhere. It
> wouldn't even need a graphical screen necessarily. Text only LCD
> displays very inexpensive compared to the fancy high rez touch sensitive
> smartphone displays currently shipping. Would kids go for pure text
> messaging ability and no voice, digital camera, web etc?  Who knows. But
> SMS sure is popular, especially in third world countries where this is
> likely to be needed. Most of SMS is just black and white text.
>
> Most of the world can't afford a fancy phone with voice anyway.
>
> Things to consider:
>
> Could a bad guy build a device or abuse the protocol to suck up all of
> our messages becoming a black hole preventing message delivery?
>
> How can we make such broadcasts inconspicuous yet recognizeable? How
> often should they announce so as to conserve power? Maybe only announce
> while moving. Perhaps as detected by accelerometer if we aren't fancy
> enough to have a GPS. Maybe announce whenever we passively listen and
> hear another device. If he just came into range he was moving so he was
> announcing. Some such discovery protocol needs to be worked out.
>
> It would be nice if we could somehow track replies vs who we sent the
> original message through. That way we could calculate the probability
> that any one particular node consistently fails to deliver. On the other
> hand, you can't have negative reputation on the Internet. You can just
> fake up a new identity. Perhaps even completely unnecessary if we can
> run into enough honest devices to get the message through. Maybe it
> would be better to track who likely got us a reply faster. That is a
> form of positive reputation which is more doable.
>
> Just my 2 cents. :)
>
> --
> Tracy Reed
> http://tracyreed.org
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110301/5e6d3690/attachment-0001.htm>


More information about the Freedombox-discuss mailing list