[liberationtech] How to make the Internet secure

[Karl Semich]

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 <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.
> 
> ---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 companys at stanford.edu.