Comment by tptacek
5 years ago
Finger is a silly protocol. It doesn't exist anymore because it is worse in every possible way than HTTP (or, at least, the tiny subset of compatible HTTP that replaces it).
I remember when I was earlier in my career and more specialized on implementing weirdo protocols hearing that HTTP was going to replace all the existing protocols. I was appalled; it seemed absurd, like suggesting Word .DOC was going to replace all text files.
But for the most part, the people saying that were right, and we are better off for it. The thing about a lot of those purpose-built protocols, even the "important" ones like DNS and most especially infrastructure stuff like SNMP, is that they are pretty dumb, the product of their time and thus, by construction, deprived of several decades of systems learning.
Something interesting about them though is that they were mostly simple, plaintext, protocols and you could learn a lot by popping open a telnet connection and playing around. At least I learned a lot that way when I was a kid. I figured out how to make HTTP GETs, use IRC, etc playing around with telnet.
Counterexamples: DNS and it's silly, idiosyncratic compression; FTP and its absolutely batshit control/data channel connections; the ASN.1/BER nightmare of SNMP. Also consider the "simple, plaintext protocols" that should not have been: the r-utils, for instance, had to be supplanted by encrypted binary protocols; NNTP failed, and ultimately ended up centralizing Internet discussion on sites like this, because it was doggedly optimized for text and inevitably abused for binary sharing.
The moral of my story is: those old protocols were bad, practically all of them.
> NNTP failed, and ultimately ended up centralizing Internet discussion on sites like this, because it was doggedly optimized for text and inevitably abused for binary sharing.
That's not really why it failed though, since those binaries are in separate newsgroups that most servers simply don't carry.
The issue is more about spam and lack of moderation, which makes it somewhat unfriendly to newcomers, since one has to do the spam/troll filtering locally. This over time lead to most newsgroups slowly dying out.
3 replies →
HTTP is a simple, plaintext protocol.
(I've implemented producton-grade HTTP libraries many times. HTTP being a one-size-fits-all protocol means the existing libraries are ridiculously specialized and overspecced.)
HTTP 3 isn’t plain text.
5 replies →
Fun trivia: iirc, John Carmack used his .plan as his then "blog" before Twitter came along.
We also used to put jokes and ASCII art in there. I spent way too much time getting an ASCII Kilroy to look just right.
Indeed! Lots of cowsay moments..
You didn't make an argument for why it's a silly protocol. You didn't make an argument for why it is worse in every possible way than HTTP. You didn't make an argument for why we're better off having replaced everything with HTTP. You didn't make any arguments about they they are "pretty dumb."
Your entire post amounts to "I like HTTP" and "old stuff bad."
FTP is an absolutely bonkers protocol. I’ve written lengthy posts in here in the past detailing why that protocol needs to die.
Email is another clusterfuck of a protocol (well, several protocols) that barely functions despite dozens of modern pseudo-standards plastered over it. I’ve written extensively about that too.
DNS is frequently the source of amplification DDoS attacks. It’s another protocol that made sense once upon a time but has struggled to keep pace with modern advancements in technology
IRC is probably the best of the bunch here but even that has struggled to keep pace and can be subject to undocumented behaviours (like line length).
…and these are the protocols still in use. The ones replaced by HTTP were either crazier or over simplistic that they offered nothing over HTTP.
I’ve written my own clients for every one of those examples and had to deal with the pains of their protocols. I’ve also written my own web browser. And while HTTP has some warts too, I’d take that over FTP and SMTP any day of the week.
> Email is another clusterfuck of a protocol (well, several protocols) that barely functions despite dozens of modern pseudo-standards plastered over it. I’ve written extensively about that too.
SMTP is one of last of decentralized open communication protocols that is still widely used by business. It evolved over time, gained some additions and stayed alive. The biggest issue I have with e-mail nowadays is companies like Microsoft and Google acting like they go out of their way to break protocols and deliver less and less messages from perfectly well working but decentralized sources.
Microsoft is especially bad of the two, with years-long tradition of acting against standards (Outlook Express connecting to recipients' MX, cloud offering accepting messages for delivery and never delivering them [1] etc). Google, I believe, as soon as they find a better way to get hold on user's invoices and receipts, will teach their users that they should use something else instead.
Stating that standard barely functions just because anti-privacy corporations only pretend to use standards in way there were intended, but concentrate on breaking them, is not how I would describe current state of e-mail-related stuff.
[1] https://news.ycombinator.com/item?id=27980192
7 replies →
I've done POP3 and SMTP and they didn't seem TOO bad but those were just toy implementations which didn't have to work in the real world and I gather things have gotten pretty complex and ugly since then. What would you suggest to replace e-mail while retaining its flexibility?
7 replies →
You might like TMTP from the mnm open source project (my work).
OK, I'll bite.
finger was conceived in a time and environment where you would reasonably assume a lot of things which stopped being true a long time ago.
many users per machine/users actually logged in to that machine/users being in walkable distance or in the same building/no compartmentalization, i.e. your demon has access to every users' home directory
and that's just the top of my head.
if you see finger as "everyone has a place to store a message and people can read it" then yes, you might say it wasn't worse than HTTP - but I think the plan feature wasn't even the original intention, it was more "is person X at their desk right now?".
So all features aside, it has so many assumptions baked in, I'd have to think hard how to replicate it in a modern way for a company and still fit the protocol.
I'm not sure I 100% agree with the protocol being silly (merely not great, BUT it's been years since I read the RFC - it's short, you should), it's kinda simply plain text with some wonky hostname shenanigans, but the whole concept hasn't aged well. But that is if you completely ignore anything about security (see what I wrote above) and privacy.
The way I read it - finger protocol is a small rusty bike; whereas http by now is a fancy sports car. (Heck if we are talking http/2 or 3 it’s a damn flying car at that)
We now all go about our daily bakery shopping in the fancy sports car instead of a small rusty bike.
And people have differing opinions whether this is the best timeline to have...
4 replies →
Imagine if we were stuck in a world with a large bloc of users running MSIE6 regularly accessed web servers running 40-bit SSL2. Neither clients nor servers ever bother updating, because it still works for them.
That's essentially where every other protocol is. HTTP gets all the energy, active development, updates regularly rolled out. Meanwhile if you tried to make, say, FTP more rational by transmitting data over the control connection, nobody would be able to use it since all the servers are still running 25 year old wuftpd with the minimal patches to not get pwned and they have no interest in updating (if they even remember the servers exist).
Personally I think we've lost something valuable when only one protocol exists, but I'm one of those Luddites who still reads email with Thunderbird so what do I know.
You didn't make an argument why it isn't a silly protocol. You didn't make an argument for why it is better in any way than HTTP. You didn't make an argument why we are worse off having replaced everything with HTTP.
Your entire post was stupid and had no point other than trying to be a gotcha.
The burden of proof is always on the person making a claim. I've made no claim on this subject. I haven't even entirely formed my opinion on this and am not even playing Devil's advocate. The point of my post was to try to improve the quality of the discussion here. Unsupported random opinions aren't generally relevant to strangers.
9 replies →
I agree the novelty of implementing these protocols wears off as soon as one looks into the security nightmare a poorly implemented protocol can cause.
But I still would like to see efforts happening in applications like Nokia's mobile web server. Another such effort from a decade ago was Opera Unite https://linkdekho.in/1e2vAy
> suggesting Word .DOC was going to replace all text files
Outside of the tech world, it pretty much did.
And in my eyes, that's pretty terrible - we're stuck with a number of proprietary formats for commercial software, the adoption and more widespread support for which has been an uphill battle every single step of the way, since MS isn't incentivized to do that properly.
Honestly, i avoid .doc and .docx as well as most of MS Office formats whenever possible, at this point i just have LibreOffice installed and use all of those native formats: https://en.wikipedia.org/wiki/OpenDocument
Not only that, but most of these formats are problematic on a technical level - when compared with something like simpler Markdown files or any other text based format, looking things up is needlessly hard, so you can forget about easily searching for some text within a directory of 100s of such files on a server without some niche tool.
It's the Windows vs Linux points of view. HTTP is a kitchen-sink, and extremely complex. I know, you're saying 'Wait, HTTP is simple.' Understanding basic HTTP use of GET and POST is simple, the implementation details of the spec needed to be HTTP compliant are complex. Think of features like proper MIME handling, compression handling, redirects, all the authentication options to handle, proxy support, caching, content-negotiation, headers to selectively GET, web sockets, etc. The spec for HTTP/1.1 weighs in at 176 pages.
Finger on the other hand does one thing, and does it well.
I would argue that we need more smaller protocols and less kitchen sink protocols.
The drivers for kitchen sink protocols are not necessarily technical, they could be financial. As a bigger protocol gets more name recognition it becomes a less risky pitch in the eyes of management to adapt the protocol instead of going with a smaller one, or inventing your own. This adaptation sometimes leads to the bigger protocol getting extensions and growing even larger. The other reason HTTP is often used is security policies - the port is open, so no additional ports are needed, and security is already set up to scan HTTP traffic.
Is HTTP any better or is it just an old protocol ("product of its time") that happened to get lucky in its adoption?
HTTP is like the PC: its main quality, and its worse defect, is extensibility.
I don't see it. When is/was HTTP ever really extended? HTML/CSS/JS I could accept the analogy, and honestly I think HTTP only really won because of those. They had all the elegance and practicality of the PC[0], and HTTP was dragged along for the ride. The other thing they had in common was being at the right place at the right time, not to mention 'politically' acceptable.
[0] Not a compliment
6 replies →
worse is better.
it is a protocol for a specific purpose, and because it has that specific purpose, it was used for that, and desired for that. http can do it, but without the constraints, of course nobody will use it for reinventing finger.
I was messing around with servers that had a finger server running a few days ago. I think the university of Wisconsin has a finger server running that exposes the name/address for all their faculty and students
For a long time, the university I worked for had multiple big Solaris boxes that were used as shell boxes for faculty and students. After I left, I would still use the finger protocol to see what my old coworkers were up to!
On the ARPANET (the original one running the NCP protocol), not only didn't you need a special protocol to have an online chat with somebody at the other end of the country, you didn't even need a host or a talk daemon running on a server!
From an earlier post:
https://www.youtube.com/watch?v=s3OMSMq9zPA
Finger is much better than HTTP from a security point of view, because it’s incomparably less complex (does one thing only), which eg removes all the risks coming from scripting, and makes sandboxing trivial - on both ends of the connection.
The Morris worm spread through a bug in finger(d). Turned out doing one thing only could still be a vector for a system compromise.
Is it?
True, most finger implementations are trivial. But there is nothing stopping to create a finger daemon which does something dynamic based on the query the user sends. The same set of vulnerabilities is possible. It is also possible to write a simple web server for a single purpose without scripting, which is similarly secure to a finger daemon. Also finger clients are relatively secure as they don't do any interpretation of the data, (which might mean that they don't do any validation, which would allow console injections with escape sequences....) but there isn't anything stopping to send the response in HTML. Also you can write an as secure HTTP client for that tight use case.
In addition we have tons of tools to work with HTTP for debugging, proxying, caching, filtering, ... none of those for finger (which of course is a responds to nobody using finger and everybody using HTTP) which allow better handling.
"Scripting" isn't part of HTTP.
HTTP does a lot of things right, but it’s almost completely oblivious to the contents of requests/responses. Things like DNS also have to specify what a query looks like, and the format for the response.
Be glad you never got SOAP Fingered!