Resumo

  • Na RFC 742, uma linha composta apenas por CRLF pedia a um host específico a relação de pessoas que usavam aquele sistema naquele momento.
  • A rede transportava a pergunta; o host produzia a resposta. A RFC 1288 tornou explícitos o direito de recusar a lista geral e a escolha local dos campos adicionais.

A consulta vazia tinha um destino

Para entender o Finger, vale começar pela menor pergunta possível. O cliente se conectava a uma máquina, enviava apenas retorno de carro e quebra de linha e aguardava. Na especificação de dezembro de 1977, essa linha vazia significava: mostre quem está usando este sistema agora. O pedido era dirigido a um host determinado. Não varria toda a ARPANET nem consultava uma lista central de pessoas presentes.

A RFC 742, de Ken Harrenstien, descrevia uma interface de rede para os programas NAME e FINGER já usados na SAIL, na SRI e em sistemas ITS do MIT. O texto aproximava a consulta vazia de um comando local de situação do sistema, como systat no TOPS-10 ou TENEX. A lista poderia trazer nomes completos e a localização dos terminais; nome do trabalho e tempo sem atividade também eram dados úteis. A consulta por uma pessoa específica tinha outra finalidade: podia informar a sessão atual ou, se ela já tivesse sido encerrada, a última saída e um plano escrito pelo próprio usuário.

É aí que a escala muda. Uma consulta pelo nome começa com uma conta que o solicitante já conhece. A consulta vazia pede que o host revele um conjunto de usuários. O protocolo facilitava o transporte dessa pergunta, mas não transformava a resposta em um cadastro universal. A RFC 742 diz que o resultado variava conforme o sistema e não exige um formato comum. Os exemplos mostram terminais, salas, trabalhos e intervalos de inatividade; são exemplos do documento, não evidência de que todos os servidores devolviam os mesmos campos.

Um estado legível não autentica uma pessoa

Uma linha com nome, terminal e minutos ociosos pode parecer um registro objetivo. A especificação, porém, descreve um programa remoto que fornece um relato legível por pessoas, não uma autoridade independente que certifica quem está diante do teclado. Ela não define um vínculo criptográfico entre o nome exibido e a pessoa real, nem uma medição de presença para a rede inteira. Ler a resposta como o relato de um host é uma inferência a partir do alcance e do formato do protocolo; tratá-la como prova de identidade ou como retrato completo da Internet iria além das fontes.

Os campos também representavam evidências diferentes. Nome de acesso ou nome completo podia ajudar um colega a reconhecer uma conta. A localização do terminal e o tempo sem atividade podiam sugerir onde alguém estava e se trabalhava. Um arquivo de plano podia trazer texto do usuário; o estado da sessão vinha do sistema. A mesma resposta podia, portanto, misturar dados de autores, ritmos de atualização e níveis de sensibilidade distintos. A RFC 742 deixou boa parte dessa composição a cargo de cada instalação.

A especificação acompanhou os programas em uso

A evolução não começou do zero. Publicada em novembro de 1990, a RFC 1194 procurou esclarecer a comunicação sem invalidar as muitas implementações existentes nem acrescentar restrições desnecessárias. Ela observou que as implementações então mais difundidas pareciam derivar principalmente do trabalho BSD UNIX de Berkeley. Essa observação é situada no tempo; não é uma contagem de instalações. A RFC 1196, de dezembro daquele ano, corrigiu e esclareceu pontos menores. Em dezembro de 1991, a RFC 1288 substituiu os três textos anteriores.

Na versão mais detalhada, a consulta vazia {C} pedia a lista de todos os usuários online. O programa remoto precisava responder ou recusar de modo explícito. Se respondesse, tinha de fornecer ao menos o nome completo; os administradores deveriam poder escolher outros campos. A seção de segurança também previa a recusa da lista geral e alertava que as informações dos usuários podiam ser sensíveis. A RFC 1288 citava uma implementação que mostrava horários de acesso e leitura de e-mail, mensagens não lidas e o remetente da última mensagem. Isso ilustra uma possibilidade de divulgação, não um comportamento universal.

Esse controle era concreto, mas não eliminava riscos. O host consultado podia executar o serviço, negar a consulta geral ou limitar os campos. A RFC 1288 também tratou de ataques contra a implementação, inclusive do worm Morris; esse é outro caminho de risco. Uma falha que permite executar código ou invadir um servidor não é o mesmo que um serviço funcionando normalmente e devolvendo informações escolhidas pela administração.

O caminho era comum; o relato, local

O protocolo uniformizou o bastante para que o cliente fizesse uma pergunta reconhecível e o servidor soubesse se devia responder sobre uma conta ou sobre todos os usuários daquele host. Não uniformizou o significado, a abrangência nem a atualidade do relato. É um padrão precoce da história da Internet: uma sintaxe compartilhada pode coexistir com o controle local sobre quais dados são produzidos e divulgados. O caminho da pergunta é comum; a observação continua vinculada à máquina que responde.

As RFCs não informam quantos sites executavam Finger, quantas consultas vazias eram feitas, se os administradores usavam a opção de recusa ou quão recentes eram todas as respostas. Elas documentam um serviço e a evolução de sua especificação, não sua adoção em escala. A afirmação histórica mais segura é menor e mais precisa: desde 1977, uma solicitação simples podia tornar remoto o relatório de usuários de um host; em 1991, recusar a lista e escolher campos apareciam claramente como controles locais do serviço.

Fontes