Hi Rich, What you describe here sounds exciting to me. I am very interested in communication solutions that prioritize all of sneakernet, encryption, and conventional use.
I was wondering if you know of any modern sneakernet resources, or up-and-coming systems which support this? Right now I'm basically using git-annex for everything. - Karl Sent from my iPhone > On Feb 3, 2017, at 9:04 AM, Rich Kulawiec <r...@gsp.org> wrote: > > > Many of these kinds of proposals are wonderfully thought out BUT > they presume underlying network infrastructure that (a) exists > (b) has sufficient performance (c) is not heavily censored/blocked > (d) is not heavily monitored/surveilled. > > The problem with that, as everyone here probably knows all too well, > is that those assumptions are often not true. In some places, they're > less and less true by the day. > > So assume a country where connections from/to the outside world are > thoroughly blocked and heavily monitored, and where the ISPs are compelled > by the government to record and store data/metadata about everything > their users do. Assume a country where VPNs and Tor are illegal > and/or are red flags to surveillance agencies. Assume a country which > will shut down its Internet connection and/or its internal ISPs if > it wants to. (These are plausible assumptions to make because in > some cases, they're already true.) > > So even if all connections are encrypted, that won't suffice: the > endpoints won't be able to connect. Even if they can, that won't suffice, > because it'll leave a very suspicious metadata trail. Even if that's > avoidable, the end-to-end performance will be terrible. Even if that's > acceptable, synchronous and direct communications will always be far > more dangerous than asynchronous and indirect communications because > it facilitates traffic analysis. Even if that's acceptable, none of > it will work when the network's unplugged. > > For these kinds of proposals to be viable under adverse circumstances -- > which are the circumstances where they NEED to be viable -- they need to > be able to work over highly intermittent/slow connections (e.g., ad hoc > connections that don't traverse any ISP's broadband infrastructure) > and over sneakernet. > > *Especially* over sneakernet: I think that's an absolute must-have. > > For example: > > 1. Mail queue written onto a USB stick or memory card or similar. > 2. It's smuggled into a location. > 3. It's plugged into a system which delivers the queue locally > and/or via wifi and/or bluetooth. > 4. Same system collects traffic going the other way, then > 2 and 1 are reversed. > > This is a model somewhat like Usenet in the days of UUCP connections > over dialup -- with the wrinkle that we didn't have to commit queues to > 9-track tape and physically transport them very often. But an awful > lot of mail will fit on a 2G memory chip -- and that can be concealed > in almost anything. In slightly less hostile circumstances, a USB stick > or portable drive could hold far more. And just as once upon a time we > were admonished to "never undestimate the bandwidth of a station wagon > full of tapes" we should not underestimate the bandwidth of a backpack > full of drives. Heck, a single one would easily suffice to transport > hundreds of newspapers' worth of news plus photos plus audio plus video > (in) and to transport an equivalent amount of text, audio, video, > photos, etc. (out). > > (As a site note, let me note that there's also good reason to think > about the Usenet flooding model, because it makes traffic analysis > difficult: everything is delivered to everyone. I wrote a proposal > a few years back to leverage Usenet news plus encryption to create a > highly asynchronous, indirect communications method that would suffice > to get email and news in/out of countries with NO external connectivity. > Plus: almost all the software already exists, it's well-understood and > mature, it scales indefinitely, works over intermittent and slow links, > works over sneakernet. Minus: arguably inefficient, somewhat vulnerable > to DoS, requires rethinking duplicate detection problem.) > > If you'd like a contemporary use case for this: Cameroon. > > I am, by the way -- and this is a nod to your preamble about > incrementalists and absolutists -- firmly in the middle. There are a > number of things that we're doing (and have been doing) that we need > to stop doing immediately, and some things we don't do that we need to > start doing yesterday. That's the absolutist part. The incrementalist > part says that we should not be tinkering with machinery that has proven > itself to be very robust in the face of determined attacks *unless* > the replacement parts we have in mind can demonstrate that they'll be > just as resilient. For instance, I'm highly dubious about JSON email, > which I think is far more likely to introduce gratuitous complexity, > creeping featurism, and horrible code bloat -- and thus massive security > and privacy issues -- than anything else. > > ---rsk > -- > Liberationtech is public & archives are searchable on Google. Violations of > list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, > change to digest, or change password by emailing moderator at > compa...@stanford.edu. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
