BBRv2, USB, Matrix, XMPP/Tor

  1. BBR v2: A Model-based Congestion ControlPerformance Optimizations (@ ietf.org). Congestion Control algorithms keep developing. We've gotten a long way since statically set transmission window, retransmission interval and packet size which were used long long ago. Yes, I remember those times when those values weren't set dynamically, but were fixed. Why? Well, dynamic control of those values creates unnecessary overhead.

  2. List of 29 different types of USB attacks (@ bleepingcomputer.com]. Yes, USB isn't safe, it's system bus. You'll need to know what you're connecting to it. Don't connect untrusted devices.

  3. Matrix.org mega "outage", or more like performance degradation / brownout (slowness, lag, slow, tar pitting) due to spam. It seems that they had major issues due to some DDoS spamming attacks. Message delivery was halted for about 24 hours. This is pure speculation based on my earlier experience with many distributed systems: I guess most of the spam got deleted. But why didn't that help so much, why it actually made the situation even worse? I've seen how the Matrix federation works. When messages are posted, messages are generated and placed in queue. When message is edited or deleted (redacted), another message saying that the previous message should be deleted is sent. If someone sends millions of spam messages, and then those get deleted, now you've just made the problem about twice as bad. I'm pretty sure that the federation protocol doesn't process "in queue" deleted. This is what I'll always check when making system integration my-self. Depending on situation, if I'm sending events out, I'll deleted deleted event's before sending the event and subsequently the delete out. But depending on queue architecture, at times it's impossible to cancel messages which already are in wrong kind of noncancellable queue, and then you'll just have to deal with the flood of deletes later. Which in this case, caused the extreme latency in message delivery. But always, if possible, delete the deleted event, instead of sending delete notification. Yet, in some cases due to integrity requirements, this is not possible. As example for bookkeeping it's not possible. But for most of reporting / analytics, it is. Yet in this case, there probably should be two kinds of deleted, "spam mass deletion" which is allowed do remove the original event from out bound queue and normal deletion, which would just add the delete message to the queue, to be later deleted by the server / client downstream. Of course there are several ways to implement that. Pre-elimination (deleted data is eliminated before processing in inbound queue) / post-elimination (deleted data is eliminated after processing, by removing it from outbound queue), etc. Which ever is best from architectural / performance reasons and meets the requirements. - Updated later, it's nice to see that the problem was exactly what I expected it to be, as well as the solution. Haha. Attack resolution (@ matrix.org).

  4. I wish that Matrix would have "channels" or "distribution groups", like Telegram got. Where you can post stuff to a group of people, without the people seeing which other users are in the group. This can be partially achieved by removing rights to post, but it's still not the same thing due to user information leakage.

  5. In some discussions it became clear, that many people agree about Matrix and it's lack of privacy / security features on many aspects. After long discussion it was found out, that actually none of the current messengers are really good or private & secure. Is there a need for yet another app? Which would start from privacy aspect. Briar is pretty good, but it still lacks two key features, message self-destruction timers (two are required: max retention (burn, self-destruct, whatever) / retention after read). Automatic key rotations, so that keying material is rotated automatically and separately from the messages. The second missing key feature is anonymous introduction feature, which would allow single-sidedly adding untrusted contacts, which can be later marked as trusted (just for user information, no technical meaning), as necessary. This should make the app pretty good, on top of the fact, it's running on Tor network.

  6. Helped a friend to setup XMPP as Tor hidden service and wrote a short instructions how to use it via Tor with OTR. For some interesting reason, it seems that all secure chat apps, either are backdoored or just disappear / get unmaintained pretty quickly. Just wondering if there's some kind of evil invisible background force forcing them to do that with gag-orders. Worst type of chilling effect? ?OTR:base64.