Hasura, Miradore, Cash, MulteFire, JSON, FIDO2, Email, debugfs

  1. Took care of the authentication requirements using Hasura with AWS Cognto.

  2. Used Miradore to automatically deploy system images on network. Really nice if you've got such environment where you can utilize approach like this.

  3. Built automated cash handling integration for one large international company. Cash is going out, but it seems that in some cases, there' still so much cash to be handled, that it needs to be automated. Technically that's marvellous, but it's also really expensive technology.

  4. Studied - MulteFire - https://www.multefire.org/ - @ Official site and - MulteFire - https://en.wikipedia.org/wiki/Multefire - @ Wikipedia technology. Interesting technology, using LTE in unlicensed and shared spectrum. I'm just wondering if this is a good idea, I thought that LTE licenses are quite expensive per device and there might be cheaper options, so why LTE instead of something else? Or maybe this is only supported by devices, which already got LTE licensing deal with, so it won't add significat extra cost to devices.

  5. XML / JSON fun. Got a complaint that value isn't 0. I'm pretty sure it's zero. But it seems that one intermediate processing step omits all 0 values, and therefore recipient didn't see value as zero. Oh joy, this is fun. The amount of mess such a small thing can cause.

  6. FIDO2 passwordless logins are working again with Microsoft Office, Azure and generally with Microsoft accounts. Finally, it took months for them to fix it. But now it's working. - Thinking hard if I could say good job... Hmm, no, I can't. Because it really shouldn't have been broken in the very first place.

  7. Corona virus (2019-nCoV) is forcing people to remote work. I think that's kind of great. Many companies are finally taking steps to ensure that everyone is able to remote work reliably and securely. And all of the physical tasks requiring presence are minimized. Also including silly procedures including printed papers and stuff like that. Oh, it's 2020, you wouldn't believe that there's still paper work, but yes, there is. But when people get used to remote work, and things just work. Then it's less and less necessary to get to the office and even less likely to travel for meetings.

  8. Email security best practice? I just received email from bank. Recipient is only "Investors" and sender is investors @ example.com as well as is recipient. There's a link in the email which says: "You've received a confidential message which requires action. Click here to read". Sounds bad, right? I checked headers. No DKIM no SPF. Great. Then I examined the email source in detail, the URL to be clicked and so on. After analyzing the link domain and structure and references, I concluded that the link is correct and points to the authentic bank servers. After clicking the link they ask for all authentication information, and after that they ask for all the standard stuff. How much money you've got, where it's coming from, what you're using it for, and to verify all your contact and identity information, what kind of relations you have etc.- Well, that's as scammy as it can be. But I made sure, it's all good. But after people learn that this is totally normal flow and legit way of doing things, how would you expect them to ever spot scams?

  9. Played with debugfs, seems to be pretty awesome tool to modify many things. Really nice tool, allows you to easily find and read as well as manipulate data. Except of course manipulating file system data can, ahem, is extremely dangerous even if you would know what you're doing. Also found dump_unused to be really interesting. You can easily check if trim / discard has done it's job, or if there's data in the unused parts of the file system on the disk. I wonder if here's some kind of pattern. On multiple ocmputers it seems that there's syslog and directory data on the disk after trimming in unused blocks. I guess that all "free block" cases do not actually call discard / trim? Also drives showed huge speed differences when reading the "empty" areas alone. There was also third kind of data type which was very common in the empty blocks, but I don't know what it is. I'm pretty sure someone would recognize this right away. But it seems to contain consistent record sizes and is binary data. Some kind of data map structure. I do recognize exFAT and FAT32 data structures, but this left over from ext4 wasn't familiar. The records size seems to be 24 bytes and usually only around 7-10 bytes from the record are occupied. After the first byte it seems to be little endian data and there's often clear binary numbering when ranges happen to hit visible ASCII ranges with one byte prefix. Many records seem to show s:s or ++ starting from 6th byte (0 based index) now I'm sure someone immediately knows what the data is. Yet huge majority of blocks return zero, so discard is mostly working.

2021-01-24