Embedded Files
Refreshed memory about Logical Volume Manager (LVM) @ Wikipedia. I usually don't like using it on small systems, but if something like preferred or spanning volume is required, well, of course then it's awesome. It also provides snapshot features, which in some use cases are really important. Configured it in virtual test environment to slightly play with the features before destroying the vm and related file-system(s).
SSH authentication options, using FIDO2 key with SSH (@ stavros.io) and using OpenPGP keys with SSH (@ stosb.com)
Tested ZeroSSL (@ zerossl.com) as alternative to LetsEncrypt (@ letsencrypt.org). It's good to have several options to choose from. Always. Just in case. I personally prefer that there should be at least completely "independent" tech stacks where to choose from. In case one fails, the another still keeps working, if required. No at least single vendor or software "lock-in".
Studied TAISTO20 security incident management training event documentation and material.
Played with Tmux (@ Wikipedia). Yep, I'm old school guy, I often use screen, if required. Screen is basically the same, but without the windowing features, which are usually provided by the GUI where the terminal sessions are created.
Found that one restaurant had made upgrades to their customer service process. It was in a way really handy, you could easily on any web page order anything to the tables of the restaurant. Just select what you want to order and to what table, and pay later. Well, in theory that sounds good. But it's also a great way of trolling. Especially when the order interface is globally open and none whatsoever authentication is required. Also the database APIs were open, so you could simply script massive orders. Yet that of course would be obvious. I might add an feature where there is at least some basic authentication (not referring to the HTTP basic auth). But something which would require you to be present in the restaurant to make the orders at least. Like per table daily password or QRcode. Of course you could make more high tech implementation with Bluetooth Low-Energy (BLE) beacons, WiFi names, or whatever. But just to limit the global abuse potential to requiring at least local presence. Or maybe just even weekly password on the wall. Even that would prevent the worst of abuse. Of course assuming that the password validation isn't made in the application JavaScript which is of course visible to everyone. So the validation needs to be on the server-side. Trivial to implement, but completely lacking it, isn't great approach. Now it was just like, select items from restaurant menu, enter table number and order. -> Boom. - Yet I've seen so many systems which are broken by design, because there's "blind trust" to the data being provided without any (yes, absolutely none) authentication or validation.
Watched several FOSDEM 2020 videos, including Matrix E2E encryption (@ YouTube). Decentralized global real-time end-to-end encrypted communication platform. Really nice talk, I loved the speed and slides, lot of stuff. Had to pause the talk several times to go through the slides in detail. Not a "single topic book" which is a full book of stuff which could have been written in two pages. - I'm just wondering what's the performance of running crypt on PDP-11, Osborne 2 and VAX. Haha, good joke guys! Verification requests in DM and not random popups. That's wonderful, because the blocking popups were absolutely terrible, especially when combined with lagging federation. And finally the E2EE threat model. I still wish that Matrix would provide message / encryption key history management features. kw: SSSS (MSC1946), Messaging Layer Security (MLS) Protocol (@ IETF.org) - Yet, this I have to read later. - Thank you, great talk. Sure, it's hard to get all this right. At least it was clearly mentioned that metadata isn't being protected, that's something what many have been (of course) saying about Matrix in general.
2022-01-30
Google Sites
Report abuse