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 <[email protected]> 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 > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss > >
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
