Resumo

  • O RFC 742 definiu que uma linha vazia encerrada por CRLF pedia a lista de todos os usuários online, com nomes e locais de terminal, podendo incluir trabalho e tempo sem atividade.
  • O RFC 1288 preservou a troca TCP de uma linha, mas exigiu resposta ou recusa ativa para a lista geral e o encaminhamento, além de recomendar seleção administrativa de cada informação.
  • A porta 79 coordenava onde perguntar. Ela não autenticava a pessoa, não garantia a resposta, não concedia direito aos dados e não tornava seguro exibir texto recebido de fora.

O branco tinha a consulta mais ampla

O RFC 742, de 30 de dezembro de 1977, descreveu um serviço deliberadamente simples e humano. O cliente se ligava ao socket 117 em octal, 79 em decimal, enviava uma linha terminada em CRLF, recebia um relatório variável e esperava o servidor fechar.

Se a linha não tivesse nome algum, o relatório padrão deveria listar todas as pessoas que usavam o sistema naquele momento. Nome completo e localização física do terminal eram o mínimo pretendido. Nome do job e minutos desde a última digitação ou atividade também pareciam razoáveis e úteis.

Com um usuário, a consulta virava individual. A resposta podia dizer se estava conectado, quando saiu pela última vez e mostrar um recado curto guardado num arquivo especial, o plan. Era um status pessoal antes de existir uma camada própria para esse tipo de presença.

O contexto era uma comunidade concreta. O RFC citava SAIL, SRI e sistemas ITS; ligava o FINGER escrito por Les Earnest à inspiração do NAME em ITS e creditava Earl Killian e Brian Harvey pelo protocolo. Entre grupos de pesquisa próximos, saber quem estava presente podia poupar tempo e facilitar conversa.

Mas a consulta vazia não carregava objetivo nem vínculo. O padrão não perguntava por uma pessoa: pedia a população. Quando o alcance da rede cresceu, o mesmo gesto amigável ficou disponível a uma plateia que os usuários não conheciam.

A resposta humana não tinha teto semântico

O Finger não impunha formato. Máquinas diferentes guardavam dados diferentes, e a saída servia à leitura humana. Essa liberdade permitiu combinar login, nome civil, terminal, sala, telefone, diretório, shell, estado de correio e mensagem pessoal.

O token /W solicitava maior detalhe. O documento inicial o chamava Whois switch. No RFC 1288, ele aparece no começo da consulta; o último serviço pode aumentar a verbosidade ou ignorar. Não existe uma segunda autenticação que autorize a riqueza adicional.

A pesquisa também podia aceitar sobrenome ou nome completo além do login. Uma entrada ambígua produzia candidatos. A conveniência para encontrar alguém sem conhecer a conta exata também permitia enumerar nomes aos poucos, mesmo com a lista geral desligada.

Texto compreensível não significava medida uniforme. Idle podia contar teclado em um host e atividade de job em outro. Ausência podia significar ninguém online, desconhecimento ou política de ocultação. A resposta descrevia a visão local do servidor.

A recusa explícita corrigiu o significado do silêncio

O RFC 1196, publicado em dezembro de 1990, tomou como base o comportamento BSD predominante. Queria esclarecer a interoperabilidade sem invalidar muitas implementações e destacou que retornar informação sobre usuários era uma questão sensível por definição.

Em dezembro de 1991, o RFC 1288 corrigiu /W, espaço e fechamento da conexão. O fluxo continuou pequeno: TCP 79, ASCII, uma linha com CRLF, resposta e encerramento. O que mudou foi tornar a política uma parte observável do resultado.

Para {C}, a consulta vazia, o serviço devia responder ou recusar ativamente. Se respondesse, fornecia ao menos nomes completos. O administrador deveria controlar a inclusão de terminal, escritório, telefone, job e tempo ocioso. Se a lista estivesse desligada, o host podia declarar a recusa em vez de fingir que não havia ninguém.

Uma lista vazia parece uma afirmação operacional. A recusa é uma afirmação de política. Separá-las evita que a proteção de privacidade vire dado falso.

O RFC recomendou ainda descarga atômica: escolha por item. Um local podia divulgar telefone residencial e horários; outro, apenas escritório e contato profissional; outro, somente o nome mínimo. O protocolo comum deixou de impor um pacote único de exposição.

Encaminhar uma pergunta atravessava alcance

Uma consulta Q2 podia encadear @hostname. O RUIP receptor abria outra conexão Finger, passava o restante da linha e devolvia a resposta. A gramática não colocava limite arbitrário na quantidade de hosts.

O RFC 1288 exigiu oferecer ou recusar claramente o encaminhamento e recomendou recusa por padrão. Num gateway, permitir Q2 oferecia uma passagem do lado externo para serviços internos.

O intermediário não autenticava o solicitante, nem transformava informação interna em pública. Apenas emprestava sua conectividade. Todos os saltos podiam cumprir a sintaxe e ainda assim cruzar uma fronteira sem autoridade legítima.

Por isso, o inventário deve testar quem encaminha, quem responde no fim, como o não aparece e como os logs ligam as etapas, não apenas quais portas 79 aceitam conexão direta.

Escrever o plan não era escolher toda a audiência

O plan dava autoria ao usuário: horários, viagens, contato, projeto. Porém quem escrevia não necessariamente conhecia todos os clientes capazes de consultar o host. Conteúdo e distribuição tinham donos diferentes.

O RFC 1288 advertiu que devolver arquivo modificável pelo usuário podia equivaler a distribuir livremente qualquer informação sobre o sistema. Um recado podia vazar detalhe interno, enganar o leitor ou explorar suposições frágeis do código que localizava o arquivo.

Algumas implementações deixavam executar programa do usuário em resposta. A leitura remota virava gatilho de execução. O administrador precisava poder desligar, e o programa jamais poderia comprometer a segurança.

Três autoridades devem continuar separadas: o usuário escreve, o operador decide o que sai do host e o cliente decide como renderizar. O consentimento de uma não substitui as outras.

Texto para gente ainda era entrada não confiável

O RFC 1288 recomendou filtrar caracteres não imprimíveis por padrão, deixando ASCII visível, tab e CRLF. Sequências de escape podiam alterar nomes de janelas X ou provocar ações confusas no terminal.

No envio, o RFC 742 já alertava que um cliente Telnet genérico podia inserir negociação IAC e estragar a linha do Finger. Dois protocolos que transportam texto não compartilham automaticamente seus controles invisíveis.

“Feito para humanos” define o leitor, não garante segurança. O emissor deve produzir a linha correta; o receptor deve impedir que dados remotos virem ordens para a interface.

Código robusto e divulgação mínima eram provas distintas

Ao citar o worm Morris, o RFC 1288 colocou o Finger no perímetro de segurança do host, junto de Telnet, FTP e SMTP. Um daemon pequeno ainda exigia defesa contra entrada malformada e teste de penetração.

Mesmo perfeito, ele podia contar demais. O documento menciona implementação que revelava último login, última leitura de e-mail, mensagens não lidas e remetente da mais recente. Isso permitia inferir conversas e foco sem explorar o processo.

Da mesma forma, poucos campos não provavam segurança do código. Parser, encaminhamento, hooks e controle de saída continuavam superfícies separadas. Minimização e robustez se reforçavam sem se substituir.

Logs ajudavam a encontrar nomes repetidos, ambiguidades exploradas, /W e Q2. Mas registravam interesse por pessoas e exigiam finalidade, acesso restrito e prazo de retenção.

O registro da IANA guardou a porta, não o direito

O registro de nomes de serviço e portas da IANA mantém finger na porta 79 para TCP e UDP. O RFC 1288 define TCP. A linha coordena o endereço histórico do serviço.

Ela não prova que um host o executa hoje, que a resposta é correta ou que o visitante merece qualquer campo. A porta mostra onde perguntar se houver serviço; operador, usuário e receptor continuam decidindo exposição, conteúdo permitido e consequência.

O Finger mostrava uma visão momentânea das sessões e, às vezes, uma autodescrição. Não era identidade assinada nem registro administrativo com cadeia de alterações.

A pergunta sobreviveu porque perdeu a autoridade automática

A história não cabe em “inocência e depois segurança”. O texto de 1977 já via formatos variados e a interferência do Telnet. A revisão posterior preservou a utilidade humana e expôs as decisões ao redor dela.

A lista geral continuou, mas recusável. O perfil continuou, mas configurável. O encaminhamento continuou, mas com negativa recomendada. O plan continuou, sem transformar autoria em distribuição irrestrita. A saída livre continuou, com filtragem no cliente.

O protocolo não criou privacidade sozinho. Passou a dizer onde ela precisava ser governada. A porta 79 dizia onde perguntar; o operador decidia se revelava; o cliente decidia como exibir. Nenhum herdou o poder dos demais por compartilhar a gramática.

Fontes e limites

As fontes demonstram história, gramática, recomendações de segurança e registro de porta. Não medem implantação atual, frequência de ataque ou política de um site. O verbete da IANA não vira censo, e os exemplos não são atribuídos a toda implementação histórica.