User Tools

Site Tools

tools:finger

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
tools:finger [2026/03/31 11:20] – [Dynamic Finger Responses] Humphrey Boa-Garttools:finger [2026/04/01 07:53] (current) – [More Reading] Humphrey Boa-Gart
Line 1: Line 1:
 ====== Finger ====== ====== Finger ======
  
-{{wst>expand}}+The **Finger Protocol** is the structured TCP layer used by the ''name'' and ''finger'' applications on old [[tactics:unix-philosophy|Unix]] systems. The ''finger'' program was developed by [[wp>Les_Earnest]] in 1971 as a way for remote users to see who was signed into a shared server. It could also be used to see a full list of that server's users & their email addresses. This concept laid the framework for the modern social internet as we know it. The plaintext request/response protocol used by the ''finger'' application to query a Finger-equipped server was standardized on **TCP Port 79** as [[rfc>742|RFC 742]] in 1977. 
 + 
 +Openly sharing email addresses and live session data was considered fine in the early years of the internet. But by the early 90's, hackers & corporate spies were abusing the utility to exfiltrate sensitive internal data from corporate, government & military networks. When the daemon itself was found to be hackable - enabling full remote hijacking - it was the final straw and Finger daemons were gradually abandoned. By the turn of the millennium it had mostly vanished, surviving mostly on older systems until gradually most of them were tracked down and exploited as well. 
 + 
 +Despite all this, the beleaguered protocol still has a small yet avid fanbase that overlaps with the remnants of the once-legendary [[tools:gopher|Gopherspace]]. This owes to the fact that, when you strip away the software, Finger as a //protocol// is just a simple plaintext request/response handshake. You just ask the server about ''USER'', and the server responds with a plaintext response containing what it knows about ''USER''. However, the protocol specifications do not dictate //where// this data has to come from or how it is phrased. So hobbyists in the 21st century have developed custom finger daemons that just treat ''USER'' like a generic slug or search key, and run it against a dynamic application. Blogs, support portals, social networks, and even weather beacons, are just some examples of what is now being deployed over Port 79. Finger is even suitable for vibe-coding experiments, as the protocol is so simple that it barely makes a dent in your Agent's context window.
  
  
Line 36: Line 40:
 Despite Finger's initial conception as a way to dig up user & session information from remote computers, the actual transmission of data is a strictly-defined plaintext request/response protocol. This means your server can respond to Finger requests with **whatever it wants**. As long as the server responds in only plaintext, any compliant Finger client will be able to display it. Despite Finger's initial conception as a way to dig up user & session information from remote computers, the actual transmission of data is a strictly-defined plaintext request/response protocol. This means your server can respond to Finger requests with **whatever it wants**. As long as the server responds in only plaintext, any compliant Finger client will be able to display it.
  
-The emerging scene of //"modern"// Finger daemons take the Gopher/Gemini approach, where the daemon simply checks requests against a predefined folder of plaintext files and/or dynamic CGI scripts. This means you could key a specific Finger request to a CGI script that process the request and responds with data from an SQL database, or even applications built in other languages.+The emerging scene of //"modern"// Finger daemons take the Gopher/Gemini approach, where the daemon simply checks the "username" of the request against a folder of matching plaintext files and/or dynamic CGI scripts. This means you could key a specific Finger request to a CGI script that processes the request and responds with data from an SQL database, or even from applications written in other languages.
  
-For example, modern PHP installs come with ''php-cli'', a command-lined version of PHP which spits out plaintext data in a form //especially// suited for Finger. You just make a CGI wrapper for your PHP script, and pass it to ''php-cli'' like this:+For example, modern PHP installs come with ''php-cli'', a command-line version of PHP which spits out plaintext data in a form //especially// suited for Finger. You just make a CGI wrapper for your PHP script, and pass Finger requests to ''php-cli'' like this:
  
 <file cgi loader.cgi> <file cgi loader.cgi>
Line 46: Line 50:
  
 For an easy example of serving dynamic data over the Finger protocol, give [[github>noveltylanterns/fingered]] a spin. For an easy example of serving dynamic data over the Finger protocol, give [[github>noveltylanterns/fingered]] a spin.
 +
 +
 +==== Finger Relays ====
 +
 +One lesser-known feature of Finger was its ability to do **relays**, almost like a built-in proxy service. To explain how it worked, lets suppose the client wants to finger user ''alice'' on host ''R7'' via a chain of six other hosts. The client's relay request would look like this:
 +
 +  finger alice@R7@R6@R5@R4@R3@R2@R1
 +
 +Here the client is connecting first to the host ''R1''. ''R1'' then forwards the request to ''R2''. The full sequence looks like:
 +
 +  Client -> R1 : "alice@R7@R6@R5@R4@R3@R2@R1"
 +  R1     -> R2 : "alice@R7@R6@R5@R4@R3@R2"
 +  R2     -> R3 : "alice@R7@R6@R5@R4@R3"
 +  R3     -> R4 : "alice@R7@R6@R5@R4"
 +  R4     -> R5 : "alice@R7@R6@R5"
 +  R5     -> R6 : "alice@R7@R6"
 +  R6     -> R7 : "alice@R7"
 +  R7     -> R7 target logic resolves to user query "alice"
 +
 +Since it is hop-by-hop forwarding, ''R7'' would only see the IP address of ''R6'', ''R6'' of ''R5'', and so forth. This means that Finger clients essentially had a built-in way to obfuscate their IP address from the final host in the chain, years before the existence of VPN's. Like the rest of the protocol, this feature was widely abused //(skilled data exfiltrators could exploit third party servers to mask their locations in access logs)// and many Finger daemons kept relay features turned off.
 +
  
  
Line 52: Line 77:
 The biggest drawback of Finger is that it is unencrypted, and nobody has agreed on a way to encrypt it because few people see a use in doing so. The biggest drawback of Finger is that it is unencrypted, and nobody has agreed on a way to encrypt it because few people see a use in doing so.
  
-But if you are like me, and you see a plaintext request/response protocol with a dedicated port that doesn't waste bandwidth on metadata or headers, then you will see the potential for things like speedy API endpoints. If you are building mobile apps or using [[radio:meshtastic|Meshtastic]], then I don't even have to explain the benefit of maximizing bandwidth efficiency. So one day I got bored and had ChatGPT & Claude help draft a protocol spec for wrapping Finger with TLS 1.3, just to see what it would entail.+But if you are like me, and you see a plaintext request/response protocol with no hardcoded markup logic, a dedicated port, native proxy routing, and no wasted bandwidth on metadata or headers, then you will see the potential for things like speedy API endpoints & JSON beacons. 
 + 
 +If you are building mobile apps or using [[radio:meshtastic|Meshtastic]], then I don't even have to explain the benefit of maximizing bandwidth efficiency. So one day I got bored and had ChatGPT & Claude help draft a protocol spec for wrapping Finger with TLS 1.3, just to see what it would entail.
  
-Well it turns out anyone can define a protocol, and it doesn't even need to be widely adopted if you're just using it internally with custom projects. As long as the spec is coherent, you can build unlimited compatible applications around your own custom API endpoints with dedicated ports, and start saving on bandwidth.+Well it turns out anyone can define a protocol, and it doesn't even need to be widely adopted if you're just using it internally with your own projects. As long as the spec is coherent, you can build unlimited compatible applications around your own custom API endpoints with dedicated ports, and start saving on bandwidth & CPU cycles.
  
-You can see the example in-progress ''fingers'' draft spec at [[github>noveltylanterns/fingers]]. Once we get relays figured out, I think we'll be able to do some great things with this ancient technology.+You can see the example in-progress ''fingers'' draft spec at [[github>noveltylanterns/fingers]]. Once we get relays figured out //(Imagine relay access, but this time secured by public/private certificate pairs!)// I think we'll be able to do some great things with this ancient technology.
  
  
Line 73: Line 100:
 == Web Links == == Web Links ==
  
-  * [[rfc>742|RFC742]] - The original Finger specification (1977) +  * [[https://blog.alexellis.io/the-90s-unix-command-fell-out-of-favour/|The 90s UNIX Utility That Fell Out of Favour]] - Alex Ellis Blog 
-  * [[rfc>1288|RFC1288]] - The last official revision of the Finger specification (1991) +  * [[rfc>742|RFC 742]] - The original Finger specification (1977) 
-  * [[wp>Finger|Finger (protocol)]]+  * [[rfc>1288|RFC 1288]] - Last official revision of the Finger specification (1991) 
 +  * [[wp>Finger (protocol)]]
  
  
  
 {{tag>Tools Protocols}} {{tag>Tools Protocols}}
tools/finger.1774956009.txt.gz · Last modified: (external edit)

Find this page online at: https://bestpoint.institute/tools/finger
CC Attribution-Noncommercial-Share Alike 4.0 International The Anonymous Fruit Company The East Internet Trading Company Erischan Novelty Lanterns

Copyright 2026 Best Point Holdings Limited