Passwordless, Jitsi, Jami, SREcon19, CF PM, Dat

1. True Passwordless (@ iadaptive.com ) - Once again closed solution, meh. But to the fact, I don't get what's wrong with the passwords approach. Because with MFA one factor should be something you know. Something which you can replace with duress code if required. If authentication doesn't require "your co-operation" then it's flawed. Of course you can replace passwords with something else, but in technical sense, it's still "a password" just obfuscated to some other input method. And sure, PIN is a password as well, yet usually really really weak one. To be honest, I don't see the problem with passwords nor the benefits of passwordless. Yet I'm probably viewing this from bit different point of view. Of course SSO is great with MFA and in some limited environments ZSO is preferable. Yet there's always the problem of misusing the "unlocked" credentials. Each "secure transaction" should be authenticated separately. That's why I would really love to be able to use FIDO2 in mode where it requires PIN AND BIOMTERIC verification. Because PIN is easy to eavesdrop, and BIOMETRIC authentication doesn't require my co-operation. Sure it's possible to work around that too. But it's still safer than KEY & (PIN or BIOMETRIC) identity. kw: Zero Sign-on (ZSO), Patent, Web Browser, Idaptive

2. Tried finding Jitsi vs Jami article quickly, which would contain technical & user experience comparison and differences, and couldn't find one. Hmm. Maybe if I try both, I could write such. - I tried both, and those are very different and best use cases are also different. Jitsi is great for adhoc (in browser!), Jami works as generic P2P messenger.

3. SREcon19 Americas - What Breaks Our Systems: A Taxonomy of Black Swans (@ YouTube ) - Nice talk! Sure, there are many ways to fail. Yet I think none of the issues they mentioned were in any kind of way new. Business as usual. Many times resources required for proper load testing are so huge, that well, if tests are done, those are naive tests on single subsystems. Testing everything as whole, with higher that production loads with larger data sets etc, probably isn't going to happen. kw: thundering herd, load monitoring, performance planning, etc standard stuff. Complex systems are inherently dangerous, no surprises there. - Have backup processes, procedures and communication methods. Well, that's all obvious.

4. Also read the Cloudflare post-mortem report (@ Cloudflare Blog ). Made me smile. Stuff like overall design , given instructions (process) and the documentation, really made me smile. It's awesome to see how top experts can fail with very basic stuff. - To sum it up, business as usual. Everything is done poorly, bad instructions are given and nobody cares, and finally something fails. After that everyone's wondering how this could have happened. But this is the standard how pretty much every fail usually forms. Worst part of it that usually at least few of the experts knew about the problem very well, but for various reasons no action was ever taken. Probably they even laughed about it during coffee breaks. Wouldn't it be funny if ... Or if I would want to sabotage our own systems / operations, how would I do it. What if someone else does it by accident or purposefully? - If someone thinks this is critics towards Cloudflare, well, this is more critics towards how things are usually done, and it's not IT only. It's universal.- This also applies to many so called surprises, which aren't surprises at all, probably people who's job is to think about such scenarios has thought about it earlier a lot.

5. Checked out Dat Protocol (@ datprotocol.com ). I liked the dat protocol documentation (@ GitHub ), it's very clear and pretty much the standard stuff, I've seen over and over again, with very minor adjustments from earlier similar protocols. Yet the documentation doesn't describe how problems related to P2P networks are mitigated and how distribution of chunks is optimized etc. I liked the have bit field approach, that's also in category of standard approach. But I really loved the visualization in the documentation. It's really good. Not like that academic white papers often are, really hard to interpret. Don't forget to take a look at the upgrades Hyperdrive and Hyperswarm (uses the good old Kademlia DHT) and NOISE protocol (@ NoiseProtocol.org ).

6. Something different? A-235 PLK-19 Nudol anti-satellite weapon (@ Wikipedia ). Plus read about new Iranian long range radars, sorry no link.

7. Google Sites - fresh ad hoc addition - Today Google Sites (@ sites.google.com ) gave me totally new problem. Some of the post content got duplicated, and links were broken in the copy and the copy was in middle of the article. Really really strange. In the duplicate copy links were broken, but those were still underlined. I really don't know how this could happen. Sounds like a big bad bug somewhere handing post rope(?) structure or something like that. Or partial updates with wrong index. But how did the links change to underlining, I really don't know. One thing I know, it wasn't me. - It's always so joyful to find that everyone writes bleeped code. So when I do it my-self, I can just say, it's the global standard. - Not a good excuse? No, I didn't think so either. Finally confirmed, it's Google, the site is super slow and save often fails and so on. Good job guys! - Also this notice gives me confidence ahaha: "Can't save your changes. Please copy your recent edits, then revert your changes." - Yet when I open new tab, copy paste the content from the old tab to the new tab, then everything is ok? - Ok ...

2021-04-25