On Tue, Oct 22, 2019 at 11:03:59AM +1100, Zenaan Harkness wrote:
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet, but one of the stream covfefe will "recommend as a default for all users" is a really low bandwidth ("bw") and high latency, permanent connection.
1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain.
But let's consider just 512 bytes every 10 minutes (a single small UDP packet):
1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month
each message send can contain up to 512 / 128 = 4 "std tweets" therefore 17,280 "std tweets" at 10 minute latency
at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month
NOW we're talking some serious chaff for high value random tweets at any time, with a maximum latency of 10 minutes, for only 2.1MiB of bandwidth per month!
No doubt some folks can imagine some nice applications for this "recommended baseload" stream :)
Now, if your mixing, then those 17,280 tweets need to be divided by the "mixing hop count" to work out actual payload, so let's say your actual tweets go through 10 hops, we have (up to) 1,728 high value tweets per node, per month, with possibly up to 10*10=100 minutes maximum latency (although I'm confident we can eliminate most of that with nodes cascading off one another in waves, so that maximum latency should be at most say 30 time units.
If we need lower latency, say 1 minute, we're still only talking 21MiB bandwidth per month - and as a bonus we have 10 fold message capacity, for 1/10th the latency, a win win (except on the bw front of course).
To repeat a key point from a previous email: by treating different types of streams for their own nature, we can not only reason about network impact and various performance metrics, but we can ensure that any design caters to include that type of stream.
A high value but rare text message, still has at least one recipient. An adversary will seek to discover "who are the end parties sending messages to one another". Besides cracking end user computers, one can imagine GPA stalker nodes introducing say latency jitter at one point in the net, and detecting that jitter at another point in the net. Such attacks are why the only sane entry to IQNets is via at least one 'trusted' friend. To increase stalker difficulty, we can imagine: - sending encrypted message to multiple friends - either in a star/ multi cast model - or in a token ring/ each always sends to next hop model - my first hop could just be a standard route ABC, where B is a 'trusted' net entry friend providing me his node as a hop which I may use to enter the network - then, my next hop to C could be to another friend/ 'trusted' node which runs a low-vol high-value text message "repeater" to everyone in my little circle, and possibly the odd random target (by sending a chaff fill packet); this is the star topo - alternatively in the token ring topo (topology), the 1st recipient sends the message to the 2nd, who on sends in to the 3rd etc, and the last in the ring finally sends it back to me (they don't necessarily know or realise that I originated this particular message) - once I receive my own message back, I know everyone in the ring has at least received it - this has the effect of total propagation duration (the total time for everyone to receive the message) scaling (increasing) according to the number of recipients/participants in the ring - to receive confirmation when using the star (as opposed to ring) topo, I receive an ack from each recipient; - this scales the number of ACKs according to the number of recipients - so different models have different properties - the low volume, potentially high value, relatively high latency text message stream, if it involves an ACK, can be considered a form of ping - a group of texting friends in a ring has the problem that if one recipient drops out, the next recipient may lose a message, and therefore needs to know about the prior hop in the ring (the node before the friend who dropped out) to ask for any messages or pings that have been dropped/missed, and similarly, the node before that if both nodes drop out, etc - star topo is how the typical internet "chat room" works