reincarnate0x14

JFC, that twink thing is freaking me out. My ex, objectively hot and already too thin due to a gallbladder problem, kept bugging me to get her various GLP-1 drugs and we had screaming arguments about how her drug abuse was going to kill her (recreational ketamine, GHB, cocaine, marijuana, whatever peptide stupidity her friends just read about, probably a few I'm forgetting). Fast forward and she's not my problem anymore. I have no idea what's she's on now, but I fully expect to get a call about her having ODed.

Comically IPv6 now has almost all the neat stuff IPX did. There probably is an argument for more datagram centric networking these days as the underlying services are generally much faster and more reliable and there is so much more session tracking going on at higher application layers anyway.

Signal, which shares its name with the propaganda publication of the Third Reich ...

Microsoft hasn't managed to burn down entire towns (But Copilot is probably working on it), so I suppose we do have at least some kind of gauge of callousness to work off of thanks to PG&E. Which was also the company behind that whole slightly famous Erin Brockovich thing, amongst so very many others.

Sometimes, it's both incompetence AND malice.

I had something similar with a 6-letter apple account that has never been compromised but I guess got put on some kind of list, because I had to go through account recovery almost every time I logged in, which wasn't a big deal until I got an iphone. Apple support was completely useless. Random old buried forum post in a stall marked "beware the leopard" mentioned the behavior and suggested changing the account name.

Nothing in the Apple site or phone stuff would even clue the user in to what was happening, much less how to resolve it.

My "callsign" at work for many, many years was a result of the entire C-suite hearing me laughing about Microsoft Critical Update Notification Tool and sending a manager down to figure what the hell was going on in the test lab.

If you're assigning addresses, you can make the addresses in a ULA as short as you want. You're supposed to use a random 40 bit network id but if you can accept that you may need to renumber at some point there is no reason you can't use fd12:b:a:d::beef or whatever.

It is telling that the answer is never stop.

It's like the sobriquet about the media's death star laser, it kills them too because they're incapable of turning it off.

In the original version, there is minimal physical description of Gollum (it was dark after all) and the ring was simply a magic ring that granted invisibility. Gollum lost it and IIRC he just let Bilbo go. They whole idea of him being some hobbit-like creature corrupted by the One Ring was not present at all. It was one of a series of fairy-tale adventures no more important than the trolls turning to stone. Bilbo needed a way to sneak around Smaug, so he found a magic ring.

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.

If you're debugging your own equipment you should have the certificates or keys to make it work. I'm not saying that's easy in a lot of scenarios, in fact it's frequently tedious as hell. But for example there are debug tools for like DNP3 or RPC over TLS, etc that can watch the whole exchange if provided the keys and parse the SCADA traffic or JSON objects as if it was plaintext.

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 behavior exists to prevent a 3rd party from inferring keystrokes from active terminal sessions, which is surprisingly easy, particularly with knowledge about the user's typing speed, keyboard type, etc. The old CIA TEMPEST stuff used to make good guesses at keystrokes from the timing of AC power circuit draws for typewriters and real terminals. Someone with a laser and a nearby window can measure the vibrations in the glass from the sound of a keyboard. The problem is real and has been an OPSEC sort of consideration for a long time.

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.

I used to share that opinion but after decades in industrial automation I find myself coming down much more on the "yeah, encryption everywhere" because while many vendors do not provide good tools for debugging, that's really the problem, and we've been covering for them by being able to snoop the traffic.

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.

It sort of already is. This behavior is only applied to sessions with a TTY and then the client can disable it, which is a sensible default. This specific use case is tripping it up obviously since the server knows ahead of time that the connection is not important enough to obfuscate and this isn't a typical terminal session, but in almost any other scenario there is no way to make that determination and the client expects its ObscureKeystrokeTiming to be honored.