You got some sources or did you just make that up?
Because to hell with UX when it comes to security. Knowing the exact length of a password absolutely makes it significantly less secure, and knowing the timing of the keystrokes doubly so.
Yet somehow, none of the other high security tools I have ever interacted with seem to do this for some reason. No auditor flags it. No security standard recommends hiding it.
But SUDO is the one bastion where it is absolutely essential to not offer hiding keystrokes as an obscure config option, but enable for everyone and their mother?
This is security theater. Masking sudo input does nothing against keyloggers, shoulder-surfing, or anyone reading your terminal, and pretending password length is the deciding leak ignores the much larger attack surface around a compromised box. If password length is where your threat model gets scary you've already lost.
I still have my node address memorized. The very late 1980s and mid 90s were the very best era for the vibe of hobbyist computing. Amazing ANSI art and text driven menus still fill my heart with joy.
I still think that some of those systems are easier to use than what we have now.
I miss the quality of EchoMail conversations with friends around the world. I even ended up moderating a few echoes myself after mods had moved on.
I am not a mathematician; I barely knew who Cantor was and had never heard of Dedekind. I would have likely not read the article without the title being so sensational. Your assumption sits upon the tip of your nose.
Their replies are only obtuse because you fail to see that you’re being made fun of for having such a ridiculous pedantic position about this. “Terminal” does not mean shell when you read the Telnet RFC. It means TTY. A human to machine interface. MUDs implement the Telnet protocol and provide a remote TTY. What’s running on the terminal is absolutely irrelevant.
Can you show the exact line in the RFC or IANA port reservations that says it has to implement a shell login interface with the Telnet protocol if it’s on port 23? Because I can’t find it. Nothing says that anywhere.
I literally already did. And it is not merely the RFC which specifies it. The RFC defines the protocol and really leaves it open-ended for any sort of implementation.
What defines port 23/tcp is the longstanding usage and the original understanding of a "remote terminal" or NVT. In 1983 when the IETF described the NVT, it was simply understood that a terminal, or "canonical console", was a method to access a timesharing system and log in as a user. If you went to a "terminal lab" or you sat down at a desk with a "terminal" or "teletype" or any of its predecessors, you were preparing to log in and do some programming or data processing.
There were literally no terminal labs where you would sit down and begin playing Centipede, Asteroids, or PONG. Those were completely different concepts of "consoles" and "cabinets" and the IETF did not stutter when they defined an NVT.
Every Unix implementation, every router and network device, practically anything with an Internet connection implemented a "shell" login on port 23 or it did not. There were plenty of systems with /usr/games and a plethora of leisure-time activities, but surprisingly they did not default to using port 23/tcp. It has been long-standing tradition, and convention, that the TELNETD service operating on 23/tcp is what a user expects to find when they connect.
MUD admins and wizards who put their servers on 23/tcp necessarily needed another way to log in and manage their server. I am surprised that they were so easily able to usurp telnetd if this was the status quo. Was sshd already established for them or something? Did they just resort to rlogin instead? I'm genuinely clueless and curious how it was so easy to usurp 23/tcp and use it for MUDs.
Because my community often ran them clandestinely, and we always ran them unprivileged, so there would literally be no way for the server to start on port <1024 -- it never ever had root access! If your MUD ran on port 23, that's dangerous because at some point, somewhere, some time, it enjoyed root access, and hopefully dropped that UID 0 immediately after the bind()!
This is not ok I totally agree with you, but still, I would rather just block the ads, and not buy their products or support them.
There is a side-effect in terms of privacy: you send a fake click request every single time, you also actually disclose to adnetworks which page you are visiting and incidentally your whole browsing history (not through referrers, but because click URLs have a unique click IDs to match).
Somebody deeply hurt this person and their anti-women stance is so bitterly apparent in their writing that they felt the need to write something not worth reading.
Because to hell with UX when it comes to security. Knowing the exact length of a password absolutely makes it significantly less secure, and knowing the timing of the keystrokes doubly so.
reply