On Saturday 10 May 2008 17:33, Ian Clarke wrote: > > Ian is of the view that this should be a separate application based on similar > > principles to Freenet. I'm not. We agree that there are some significant > > issues to deal with. I am of the view that these networks are mutually > > complementary and therefore should talk to each other > > I think the use-cases are too different for these to be part of the > same application. > > I see a simple scenario where a "sneakernet" would be useful is in a > situation like Burma or Tibet where stuff is happening, possibly a > political crack-down, and the authorities are actively trying to > prevent information from getting out.
You are assuming a short term emergency, right? > > In this case, the role of the sneaker net would be to allow the covert > transmission of information, probably large files like video and > images, out of a hostile area and onto the Internet. The optimal > strategy here is probably a simple one of spreading information as > quickly as possible to as many "sneaker nodes" as possible whenever > they come in contact, to maximize the likelihood that one of those > will be able to connect to the Internet. I don't think this would > require any sophisticated routing, its just a broadcast with an > intelligent replacement strategy for older content (probably LRU). This is what happens now, except that the determination of what is most important is made individually. If there is no filtering, it will of course be flooded with garbage. > > This might be combined with encryption and or steganography to protect > the sneakers should they be inspected. > > The ideal hardware platform for this would be a small device with wifi > and a lot of storage. The obvious example that springs to mind is an > iPhone or iTouch, the iPhone being better as it has a camera, and it > can transmit what it has as soon as it reaches a friendly cell phone > network. > > >From there we could get more ambitious, trying to support > bi-directional communication - but even here I think a key is to > replicate the transmitted content as far as possible, because it > probably won't be easy to predict which sneaker nodes will have > opportunities to communicate with each-other and when. Spreading it > far and wide maximizes the likelihood of successful transmission. It > only starts to make sense to route, ie to limit which nodes will > replicate data, if the size of the network is sufficient that global > replication won't scale. When the data reaches its destination, > another small response message can be sent which indicates receipt and > causes nodes that receive it to delete the original data to make room > for new data. Manual filtering will work better, if stuff is of universal relevance. Any broadcast system will be flooded. > > With all of this, I just don't see why it would be any practical > advantage to bundle this functionality with Freenet: > > 1. The platform for this type of thing is a small mobile device, > getting Freenet to work well on an iPhone would be a world of pain - > and doesn't buy anything for us No, to do that requires a massive amount of short range bandwidth. Phones do not have this. What you want is to swap actual memory sticks, at least until PDAs with UWB (maybe wireless USB) are available. Furthermore, with the currently planned changes IMHO Freenet 0.7.1 will be able to run in a 64MB memory limit. Running it on a low end device is not so far away, and would have some massive advantages (e.g. being able to ship it on one of the fanless boxes they currently ship for overnight bittorrent downloads). > > 2. Most or all Freenet apps assume a few seconds latency on requests > (Frost, Fproxy, etc), yet the latency with the sneakernet would be > measured in days. Freenet's existing apps would be useless here. Not true IMHO. A lot of existing Freenet apps deal with long term requests, which would work very nicely with sneakernet. > > So, tying this to Freenet would be a world of pain, without bringing > additional benefits. I know that some freenetters just love bundling > everything under the sun with Freenet, but in this case it really > doesn't make sense. Sneakernet is a great idea, and we probably have > exactly the expertise needed to build it, but it doesn't follow that > it should be part of the udp-based Freenet. I see it more as a long term, attack resistant, scalable solution for general communication in places where Freenet-over-UDP doesn't work. Either because there's no internet access, or because ISPs have been compelled to deploy network flow analysis, and thereby eliminated Freenet, darknet or not. This is feasible, it's a little expensive, but not so much so that a state like China couldn't afford it. It can exist over the long term, it is flexible enough to deal with bulk data transfers, with passive requests it could efficiently support the sort of broadcast operations you describe above (although we may need some new request types with different security/performance tradeoffs to minimise round trips), it wouldn't be any more vulnerable to flooding than the current Freenet is (which is to say, far less than any broadcast system), and generally would provide privacy similar to the current system. What is wrong with this vision? Technically speaking, this might be best post-0.8, but I do think that there is a certain synergy here. > > Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080512/1281049d/attachment.pgp>
