1,419 karma · joined August 8, 2020
On one hand this is normal in education and pedagogy to have the student or apprentice put the boring pieces together to find the wonder of the puzzle itself, but on the other this is how we end up with https://xkcd.com/927/
Sometimes, it's both incompetence AND malice.
Nothing in the Apple site or phone stuff would even clue the user in to what was happening, much less how to resolve it.
It's like the sobriquet about the media's death star laser, it kills them too because they're incapable of turning it off.
It's doubtless still possible to find that version, I read it in an old country library that had it on the shelf since the 1950s.
But this goes back to the vendors not providing better tools in the first place. We shouldn't NEED to be picking apart packet streams to prove to some jackass tech support ticket that their code is FUBAR. They're basically outsourcing support to their customer or userbase and we tolerated it because it was more expedient.
The client and server themselves obviously know the contents of the communications anyway, but the client option (and default behavior) expects this protection against someone that can capture network traffic in between. If there was some server side option they'd probably also want to include some sort of warning message that the option was requested but not honored, etc.
Having to MITM a connection to snoop it is annoying, but the alternative appears to be still using unencrypted protocols from the 1970s within the limitations of a 6502 to operate life-safety equipment.
Most casual users have lived with NAT so long they assume its limitations are natural. But they are not. You can achieve the same result with a firewall or ACLs or whatever on ipv6, but that's a choice and not a limitation.
FWIW the broad IPv6 network-prefix NAT behavior ALSO EXISTS in IPv4, it's just less applicable.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
If you're using it on something that doesn't matter, then it also doesn't matter that rainbow tables any attacker could have already had for a decade are slightly more available.
At some point the line must be drawn.
It would completely not surprise me if there are automagic attacks on net-ntlmv1 at this point against some cloud hosted storage. This has been doable by anyone since like 2016 if you had the space and weren't prevented from using that protocol version.
Even getting people to use certificates on IPSEC tunnels is a pain. Which reminds me, I think the smallest models of either Palo Alto or Checkpoint still have bizarre authentication failures if the certificate chain is too long, which was always weird to me because the control planes had way more memory than necessary for well over a decade.
Having flashbacks to troubleshooting bus termination on DEC equipment.
There is a visceral spiritualism to working with your hands, but if you can achieve that with coding, great! Live a life you would want if money didn't matter.
But this is what the classics of stoicism (in the literal sense of both) have been telling us the whole time. We make our own meaning, and money isn't it. Go and grow things. Raise things. Build things.
Civilization is when men plant trees in whose shade they will never sit.
I love this version and I hope you do too.