Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

There is not a single network protocol in existence that allows a signal (any data under control of the sender) that can't be used to run VPN over.

DNS. "Yes, I do lots of lookups for [long hex string].some.com", and my preferred DNS server is "[vpn provider in country which won't cooperate].com", what of it?

SMTP. IMAP. HTTP.

Pretty much any protocol allows realtime transmission of large chunks of encoded data sufficient to pass IP datagrams back and forth without much difficulty (by controlling both endpoints, so the servers might be "fake" servers - e.g. an smtp server that doesn't send messages, but accepts messages and returns overly verbose errors, or a DNS server where you constantly does "queries" that embed packets, and get responses that contains inbound packets whenever there are any.

If they were to go one further and require all traffic to pass through government proxy servers (including forcing us to knowingly accept them MITM'ing our SSL connections), then it'd be a bit more difficult, but not much: The IP datagrams would just need to be hidden in somewhat plausible looking requests and responses.

It might be slow, but it's impossible to stop because all we need is a way to pass data that they don't know to look for or can't stop. Ever read the April 1st RFC on "IP over Avian Carriers"? It's been "implemented": Print out packets as hex, strap it to a pigeon, have someone on the receiving end type in the hex digits. Obviously that is impractical, but it serves as a good reminder of just how hard it is to stop communication.

Before the internet, pirates exchanged pirated software by mailing floppies or tapes (and not just proper backup tapes - old audio tapes for home computer tape decks). That's how I got my first pirated software, 30 years ago. It got efficient enough that even before BBS's were common, pirated software could make it to pretty much every corner of the developed world in a couple of days, often beating the distributors of the real releases.

It'd also cause a surge in darknets. They keep getting surges in interests after each new attempt at restricting our freedom, and then it dies back but each time the base level of activity is a bit higher than last time.

Here's a network topology map of Hyperboria, an experimental "darknet" that exists as an encrypted network of tunnels over the existing internet, but using a new routing daemon that does encryption by default: http://norlin.ru/st/map.png - it's of course miniscule, but it's also grown from nothing to that size is a fraction of the time it took the ARPAnet.

For my part, I'm seriously contemplating experimenting with "dropping" solar cell powered wifi repeaters at a couple of spots along my commute to my local train station. I don't even have any nefarious purposes with it, nor any secrets I'm concerned about. I'd like to try it just because I'm annoyed with the quality of my mobile cell data connection, and because it'd be fun to see how long they survived, and tiny little suitable access points are getting so cheap that it's becoming viable to do just for the fun of it.

The only things stopping me are time, effort of finding suitable hardware, and that it'd need some work to be inconspicuous enough to not get some scared neighbour call out the bomb squad or something.

But we're on the verge of a situation where people can get a few grand together and get devices enough to cover a small town that are small enough and self contained enough to be "dumped" all over the place with the expectation that a high percentage of them will die or get removed every year.

The combination of more and more restrictions, and lower and lower costs brings us closer and closer to a situation where it becomes attractive and possible for small groups of people to simply start deploying their own darknets coupled with whatever tunnelling mechanisms are needed at the edges to get data to suitable exit points.



Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: