Many src-dst connections but as a single logical connection. There's no way any middlebox could easy capture full data even metadata.
http2/QUIC can do something similar with frames (and hopefully multipath)
Don't place your whole stream inside a single src-dst IP connection. Demux them into many paths over the Internet. We need more variety of "traffic shapes" to combat Internet surveillance.
I'd argue it's even more effective than encryption. Split your activity and mix them, monitor traffic over a single transport is useless.
est · · focus · HN ↗
Many src-dst connections but as a single logical connection. There's no way any middlebox could easy capture full data even metadata.
http2/QUIC can do something similar with frames (and hopefully multipath)
Don't place your whole stream inside a single src-dst IP connection. Demux them into many paths over the Internet. We need more variety of "traffic shapes" to combat Internet surveillance.
I'd argue it's even more effective than encryption. Split your activity and mix them, monitor traffic over a single transport is useless.
dongcarl · · focus · HN ↗
Yeah it'd be a cool addition to combat internet surveillance but in practicality it may have a lot of problems:
1. Deteriorated performance if it's across unequal links (3G vs. Fibre WiFi)
2. Many countries have single exits to the global internet so they'd be able to assemble everything there
3. The most important plaintext data is probably in the TLS SNI which usually sits in a single packet for TLS in HTTP/3
est · · focus · HN ↗
Hmm, maybe consider MPTCP-like design? It tackles exactly the problem you descrbed.
> Many countries have single exits to the global internet
Well it's f'ed anyway. But multipath makes content restoring much, much more complicated.