Skype, Kludge, Wasabi, Matrix

• At least one manufacturer is honest about their software: "The Android version is unreliable and frustrating to use." - Lol, how about fixing it?
• I think I'll get extra feather on my hat, for doing ultimate kludge solutions. From architecture point of view, these are absolutely nightmarish technical debt. But at least I'll try to write the code as robust as possible, so no manual intervention and fixing would be required. But if anyone ever reviews the architecture and design, it's totally horrible. Anyway, this solution will still save 95% of the work required compared to doing it "properly", so I guess it's worth of it. Yet it will make all kind of support and problem resolution much more complex later in the project. That's why it's kludge an technical debt. It's not the way it should be done, if doing things properly.
• Tested Wasabi eu-central-1 cloud object storage (Amazon S3 compatible buckets) and really liked it. Only thing that really sucks, is the access rights management. It's almost the worst access management system I've seen so far. Extremely messy, really hard to configure right and still fails. Maybe the reason so many cloud services got incorrectly configured rights, is that the right management is so poorly made? - I even did go through the documentation and sure, it's extremely bad and messy. It's probably possible to get it configured correctly, but I'm sure 99% of users won't bother, because it's so bad. Wasted another hour on the second attempt. And from those 99% only 10% would get it done, even if they would really want to. - It's about as bad as command-line PGP or GnuPG, which aren't that bad after all. - From user friendliness point, this is just pure trolling. Making rights management bad, can also give bad media visibility, of course it's not their fault if critical information isn't properly protected, but if they've made it too hard to properly protect it, what would you expect to happen? - This leads to situation where all systems (and users) are configured to use the sa account on SQL server, and or guest access is globally allowed, because if you'll do anything else, it just won't work. So that's the way to go.
• Matrix uses Curve25519 and Ed25519 for basically all ECC ecryption operations. Hmm... Also Megolm left some questions like who does - the encryption key rotation for a group chat - https://matrix.org/docs/guides/e2e_implementation.html#rotating-megolm-sessions -. The client, they say? Which client(?). When room got dozens of users. The client whom created the room, any admin, any member user? What if the creator isn't present for extended periods and so on. I've seen so many projects where there are synchronization and race conditions with data. Having timer set in ms resolution, without randomization to generate new keys for possibly large group of members with potentially high lag, sounds like a traditional problem case. - After digging bit deeper, it founds out that every client, which sends data to the shared encrypted channel uses their own keys. This means that there's no "channel key" at all. But every recipient must have the senders (current and past) encryption keys to decrypt the messages. Which allows choosing per device key distribution. When someone posts to a channel, it's possible that users A, B and C are able to decrypt the messages, but D and E aren't. This is possible due to device blacklisting or situation where they missed the encryption key delivery. But the team is working on improving key deliver as well as "trust" between devices and peers, which would allow the keys to be retrieved from other device(s). Currently this is possible, with the devices which share same user account. Not, all of the clients must remain online all the time. Off-line clients will miss the key rotations and then it's time for 'utd errors', which you can't recover from anymore.
• Joining Skype for Business meeting won't work, hangs for ever, no error messages. Thank you Microsoft for creating quality software. Yes, it's sarcasm.
• Skype for Business, still broken after several days. Great work, Microsoft. meet.lync.com is still unavailable over IPv6. Maybe this would be a good time for some aggressive hate speech? I just can't stop deeply hating this kind of software, policy and administration. Yep, it's clear. Microsoft noobs do not support IPv6 yet. That's the reason, and the shitty client fails to fallback to IPv4. That's is just freaking awesome work guys! That's actually just so meh fail. Because site is reachable over IPv4 and IPv6 using HTTP, but HTTPS works only over IPv4. So they've misconfigured the server probably, or are for some other reason blocking traffic over IPv6. Maybe they're just blocking HE.NET 6to4 bridges or something, but why. Why no clear error messages, where to report the issue. Hail, Microsoft! Confirmed meet.lync.com IPv4 HTTP = Ok, IPv6 HTTP = Ok, IPv4 HTTPS = Ok, IPv6 HTTPS = Fail. Thank you for that. Why is the traffic being blocked and why is the client is so badly implemented, why? Sure I confirmed IPv6 HTTPS cloudflare.com, ipv6.google.com all work without any issues. Sounds just like the configuration stupidities they have with Outlook and mail servers. Incompetently and badly managed systems.

2020-05-03