Communication, Admins, Monitroing, SW Dev, Engineering, IPv10, GCIC

• Checked if a group of friends would like to use goTenna Mesh networking which work well as encrypted off grid / Internet communications channel. - Results: REDACTED. There are cheaper alternatives, but those aren't generally so secure. In that sense goTenna is very useful for many kinds of operations. Leaving no phone / Internet records to be tracked.
• Reminded a few friends, that System Administrators are prime targets when attacking or doing covert surveillance / intelligence work. Because after their credentials and network access is compromised, pretty much everything else is compromised too.
• About the Internet monitoring and surveillance law. I don't think it's going to be very efficient. Because if there's something which requires absolute secrecy. It's highly unlikely that it'll be passed over Internet connection anyway. Even more ridiculous would be using Email, Facebook or WhatsApp for something like that. WiFi dead drops work pretty well, especially when used with end device which hasn't been ever used for any other purpose. Using normal Internet connected smartphone with those would be just plain stupid again. It's very important to keep that kind of information totally off Internet. Was it encrypted or not. Because the network analysis alone is just devastating give off for anyone monitoring. It's even best not to share ever contact information like that, because someone might use it, if available. It's secure alternative communication method, or nothing. The backup method can be even more cumbersome. But it shouldn't be so that if the primary method fails, then you'll fallback to totally insecure and trackable communication which might run everything in that instant.
• In many development projects it's really frustrating that the project gets changed all the time. That's also one of the reasons why often it's better to write ad hoc than proper code. Because you'll never know if that code will be scrapped tomorrow. If you spent lot of time writing perfect code, it was all time wasted.
• Sometimes constant flood of change requests make it quite hard to create any kind of sane code. Because if you try to simplify, generalize and write clean code, after a while there will be changes which will break all that again. And major refactoring is required to make stuff somewhat sane again. But who want's to pay for that? Yet it seems, it's very common.
• Crappy engineering and design. No it's not limited to software. My coffee maker Philips HD8847/01 is prefect example. The water container handle is absolutely crappy. It's so thin that on normal use it flexes considerably. As we all know, plastic parts which flex but aren't designed to be flexible, get broken in no time. That shouldn't be any kind of surprise to anyone. Except maybe to the engineers who designed the device (?). In random use it probably lasts just bit more than the warranty period. In bit heavier use, it doesn't even last the warranty period before it naturally breaks off. - Thank you for that engineering again. A) Was this done on purpose? B) Were they just so stupid that they didn't realize how bad it is. C) They knew it's crappy and didn't give a bleep. (If you're stupid enough to buy this, then this is what you deserve attitude. What did you really expect?) - Which one is the right answer? Or maybe the truth is just combination of all options? - Our solution is not to use the handle at all, we always fill it in place, yet it makes washing hard.
• Is IPv10 really necessary? Sounds like more horror to me. This also implements tons of new security nightmares. Because the IPv4 address in the example is already private IP, I would prefer using proxy to allow the traffic. This is what I've been planning to do with the few legacy horror devices, which are IPv4 only in the case it's required. This IPv10 is real security nightmare. So what if last resort communication isn't optimal. It's only temporary solution. Just as using NAT is horrible gunk, but still most of people seem to love it. So this solution improves efficiency on marginal issue and adds absolutely horrible mess for all devices. Also deployed easily ... Hmm, using this already requires migration anyway, on network level. Even if the end devices can operate using IPv4 and then DNS is involved and. Omg. But thoughts like that are nice play, what it would actually require etc. It's still much better than not thinking at all.
• Studied Google Cloud Interconnect. Wondering if Helsinki will be option, or if they route everything via Stockholm when Finland Cloud becomes publicly available. - Update just before pubglishing (this text is from backlog.,) No, having data center in Finland, didn't change a thing. All traffic is still being routed via Stockholm, even with expensive interconnect deals.

2018-12-30