Search Mailing List Archives
[liberationtech] How to make the Internet secure
gmkarl at gmail.com
Fri Feb 3 13:23:12 PST 2017
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.
Sent from my iPhone
> On Feb 3, 2017, at 9:04 AM, Rich Kulawiec <rsk at 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.
> 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 companys at stanford.edu.
More information about the liberationtech