Cryptocurrency, Isolation, Apps, Matrix

1. "If we remove the timestamp match requirement from the query, then the temporal scope will be boundless." - Sometimes it's irresistible fun to write jargon.

2. Helped a friend with cryptocurrency cryptowallet(s) setup. All the standard stuff: non-custodial, multiple wallets with limited exposure, multi-sig (when possible), hardware isolation, full disk encryption, software isolation in containers using ephemeral environments to prevent attacker persistence, at least double layer 256 bit symmetric crypto using different algorithms and utilizing 256 bit true random keys, secret sharing scheme for recovery in case something bad happens with trusted peers and finally multiple encrypted paper backups with algorithmic error correction for redundancy, in redundant and off-site storage devices are wiped by some unexpected event. Always verifying all software signatures when updating / installing something, and so on. Ok, tinfoil enough? Maybe not, I can still see patterns how I would attack that. But in most of cases, this should be reasonably safe. No, I don't know the private keys, or encryption keys, I just might have one shard of the secret, but I might have lost it already. Am I happy with the setup? Well, mostly, even physical security has been taken care of. But I think that if embassy level focused espionage would be present, it still would fail due to some circumstances not being handled perfectly. Yes, I gave very clear information what I think the easiest attack vectors would be after all this. - But obviously I'm not sharing those. Sorry I can't provide any further information about this. kw: crypto, wallet, setup, security, secure

3. In one place people have asked several times, why do they have stacks of laptops and phones. Well, that's the second layer of isolation, after separating devices into multiple physical locations. Things which aren't supposed to be connectable to each other, shouldn't reside on the same device.

4. Mobile Public Transit Tickets by HSL - Application is pure cr-abs, it crashes repeatedly, then it says login has expired, and says that you should re-login, after a while it works without re-login. So, was the login session expired or not? I'm ashamed who designed this peace of cra-bs and wrote the sh|t code? Bad error messages, bad code, bad design, the ultimate way of sabotaging everything by playing stupid. Or, maybe they're just that stupid, or is it intentional? I don't know. When browsing route maps, it also crashes repeatedly. Good going, great work! Several days serious problems, requires 20 times to restart the application, retry transactions, takes several minutes to get the ticket etc. - This falls in the category I've posted before. It's so f-king cool and great technology, that it doesn't work at all anymore. - How about using traditional guaranteed to work methods?

5. Helped a friend to setup own domain(s), related dedicated servers, services email mx / smtp, dns / glue, domains, dnssec, ssh, web / https, and content, firewalling, etc. Basic stuff.

6. It's always good to check where you're giving your credentials. Google just landed me on fake GitHub, haha. No, I didn't fall for it, but let's login, hmm, something's not right, ahh, this is fake GitHub. (No link on purpose)

7. Matrix having serious issues when using Element client, with multi-device end-to-end encryption (e2ee), keys being correctly updated / shared / trusted. So annoying. It seems some issues like this seem to take a lot of time to get actually fixed.

8. More silly bugs with Element / Matrix. Some pictures aren't visible on Android, even if visible on desktop. The image sharing / media stuff is really broken. As well as is the encryption key sharing.

9. Ability to send self-destructing messages on Matrix / Element is coming MSC2228 (@ GitHub ) / Matrix: Proposal for self-destructing messages(@ GitHub ). (A bit later, still waiting for it!) - They clearly haven't thought about data retention and information life cycle properly in the initial design.

10. When messages / events in Matrix expire, also the clients should remove encryption keys for the messages, just in case to guarantee e2ee privacy later, as example in situation where old server database / logs are restored. If encryption keys are kept, then the messages are still available. If all well behaving clients have gotten rid of the encryption keys, then the messages aren't recoverable anymore, which is the whole point.

2022-11-13