OnionShare, MultiCloud, VPN, Signal, SQL, Privacy, OVH
How to chat anonymously in secure end-to-end (E2EE) encrypted way using Tor and OnionShare Chat
Attended some multicloud training, how to connect using: AWS: Direct Connect, VPC, TGW, VGW, DGW and Azure: ExressRoute, VNet, VNet Gateway, Virtual Networks with Encryption aka Virtual Private Networks (VPN). - Currently I don't have any use for such solutions, but it's good to know about these options if and when required.
VPN FUD is strong - Instead of using your local (EVIL!!!) telco, which follows laws, rules and regulation very strictly... You should use some random Antiguan (or so) VPN provider company, which nobody knows anything about. No known employees, no management, no it-infrastructure, no owners, no share holders, no CTO, no CISO. - But that sounds much more reliable and trust worthy company than your local big telco? Right?
Signal adding MobileCoin? (@ schneier.com ) - What, that was strange twist. I completely agree with Bruce Schneier about this. And it was my first thought even before I read any other comments / blog posts about it. Oh, why?
Really liked this article: Best practices for writing SQL queries (@ metabase.com ). I can agree with everything in the article, yet it didn't contain anything new. It's a good basic guide. But I really loved when they mentioned that know your data, yep. It's just like know your tools. When someone suggests new approach to something, it's not usually easy. Not knowing the data is very often a major problem, when no proper data / description is available.
A Privacy Network - A correctly designed and implemented privacy network, hides everything, except the fact that you're using the network. They don't know when and whom you're communicating with or when, nor when you're receiving or sending messages. Many people seem to forget these facts when they secure communication. Most of "secure networks" people are talking about leak metadata and traffic pattern information. I'm often annoyed by networks which think user should have a single identity. That's major design flaw. The network should allow anyone to have unlimited amount of ephemeral identities which can be created and destroyed at will. Nor anyone should know what other contacts someone got. Even if I'm with someone in three different rooms, there should be no way for them to tell that, if it's me or not, unless I tell it my-self. If they can detect that in any other way, the platform is technically flawed. Signal is way way far from secure network.
I can't believe it. Banking app without transaction identifiers. Transaction committed twice. I've got no words for it. So classic, there's some error in communication, client doesn't know if the server executed or didn't execute the transaction and retries. Well, now we've got the transaction executed twice. Sigh, this is legendary and obviously total fail. One friend said that the banking app cloud give error. Well, that's even worse. Depending on the client side, it can lead to head of blocking the queue. Retry, fail, retry, fail. Because the transaction has been already processed, but the client just doesn't know it. And if the error message is just shown to the user, then the user might actually create a new transaction, thinking that the previous transaction failed. - I've seen this stuff way too many times, in all of it's more or less annoying forms, requiring manual investigation and fixing. - Yet one thing has been improved a lot, it used to be a common issue with web shopping, that things were invoiced several times, but lately I've had many payments issues online, but I don't think I've been charged several times in a quite a good while. So some progress have been made in general.
Nice problems caused by OVH. Now some of the SBG2 destroyed servers, popped suddenly online without a prior warning. Some of those were restored from backups (to new server on another service provider) and now suddenly we got two servers with same identity and credentials running, another just with really old data sets. Oh joy, what a nice mess. Well, luckily it didn't cause any major problems, but in theory it could have been really bad thing to happen.
2022-07-17