💾 Archived View for geminiprotocol.net › docs › pt-PT › boas-praticas.gmi captured on 2023-11-04 at 11:51:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
Este documento descreve várias convenções e pequenos conselhos para a implementação e uso do protocolo Gemini que, embora não sejam de caráter obrigatório à luz da especificação do protocolo, são geralmente considerados uma boa prática. Se está a escrever um software ou a construir um site para Gemini, deverá seguir os conselhos que aqui encontrará, a menos que tenha bons motivos para o não fazer.
Os servidores Gemini têm necessidade de informar os clientes sobre qual o tipo MIME dos ficheiros que estão a disponibilizar. A forma mais conveniente de o saberem é através da extensão do ficheiro. Trata-se de mapeamentos que, na sua maioria, estão bem padronizados (os sistemas unix geralmente guardam um ficheiro /etc/mime.types com todos esses mapeamento), mas subsiste uma questão, que é a de saber como é que os servidores reconhecem os ficheiros cujo tratamento deverá ser de tipo text/gemini, de acordo com o definido pela especificação do Gemini.
Ao que tudo indica, os servidores Gemini atuais estão a usar as extensões .gmi ou .gemini para essa finalidade, motivo pelo qual se recomenda fortemente que os novos servidores ofereçam suporte a pelo menos uma dessas extensões, de preferência a ambas, em vez de preverem novas extensões, acrescentado, dessa forma, complexidade à equação.
A exemplo do que acontece na lógica dos servidores web, se o pedido recebido pelo servidor referenciar um caminho para uma determinada pasta do sistema, e nessa pasta existir um ficheiro denominado index.gmi ou index.gemini, será esse o ficheiro que será exibido.
Os servidores Gemini não informam os clientes acerca do tamanho dos ficheiros que disponibilizam, o que pode ser um obstáculo à perceção de que o encerramento permaturo da conexão esteja relacionado com uma falha do servidor. O risco de isso acontecer aumenta com o tamanho do ficheiro.
O Gemini também não tem suporte para compactação de ficheiros grandes ou suporte para somas de verificação que permitam detetar uma possível corrupção do ficheiro, cujo risco é proporcional ao tamanho do ficheiro.
Por todos esses motivos, o Gemini não é adequado para a transferência de ficheiros "muito grandes". O conceito de "muito grande" depende, até certo ponto, da velocidade e da confiabilidade das conexões de internet envolvidas e da paciência dos utilizadores. Como regra geral, ficheiros com mais de 100 MBytes devem ser disponibilizados por outros meios.
O facto do Gemini suportar um esquema de URL com a possibilidade de ligação a conteúdo online disponível noutros protocolos permite disponibilizar ficheiros de grande dimensão. Assim, o link dentro do documento Gemini fará referência a URLs de HTTPS, BitTorrent, IPFS ou qualquer outro modo de servir ficheiros.
O Gemini suporta qualquer codificação de texto, usando para tal o parâmetro "charset" dos tipos text/* MIME. Isso permite disponibilizar conteúdo de texto "legacy" em esquemas de codificação regionais menos claros.
Para novos conteúdos, por favor, mas por favor mesmo, use apenas UTF-8. A especificação do Gemini exige que aos clientes a capacidade de lidar com texto UTF-8. O suporte para qualquer outra codificação depende do cliente e não pode ser garantido. O facto do seu conteúdo ser disponibilizado como UTF-8 maximiza a sua acessibilidade e maximiza a utilidade dos clientes simples que suportam apenas UTF-8.
Os redirecionamentos foram incluídos no Gemini principalmente para permitir que a restruturação de sites, ou a migração de sites entre servidores, se efetue sem a quebra dos links existentes. Um espaço grande e interconectado de documentos, sem esse recurso, tornar-se-ia, inevitavelmente, "frágil".
No entanto, os redirecionamentos são, de modo geral, situações desagradáveis. Eles reduzem a transparência de um protocolo e tornam mais difícil escolhas informadas acerca dos links a seguir (aumentando o risco de vazamento de informações sobre a atividade online para terceiros). No Gemini, esses problemas não são tão pronunciados como em HTTP (devido à falta de cookies, cabeçalhos de referência etc.), mas continuam a ser, na melhor das hipóteses, um mal necessário.
Assim, evite usar redirecionamentos levianamente! Funcionalidades como encurtadores de URL são totalmente desnecessários. Evite o uso de redirecionamentos, a não ser quando essa for a única opção para evitar quebras de link.
Os clientes podem deixar na mão dos utilizadores a decisão de seguir, ou não seguir, um redirecionamento, ou podem redirecionar de forma automática. Se escreveu um cliente que segue redirecionamentos automaticamente, deve ter em conta os problemas que a seguir se descrevem.
Os servidores Gemini mal configurados, ou mal-intencionados, podem efetuar redirecionamentos de forma a fazer com que um cliente, que os siga cegamente, fique preso num loop infinito, ou tenha que completar uma longa cadeia de redirecionamentos. Clientes robustos terão de ser suficientemente inteligentes para detetar essas condições e agir em conformidade. A implementação mais simples é fazer com que o cliente se recuse a seguir mais de N redirecionamentos consecutivos. Recomenda-se que N não seja superior a 5. Este procedimento está de acordo com a recomendação original para HTTP (consulte RFC-2068).
Redirecionamentos de protocolo cruzado (ou seja, redirecionamentos do Gemini para outro protocolo, como o Gopher) são possíveis, mas são fortemente desencorajados. No entanto, os servidores mal-configurados ou mal-intencionados serão sempre capazes de atender a esses redirecionamentos. Contudo, se o cliente estiver bem escrito, ele deverá estar pronto a detetá-los e a responder adequadamente.
É altamente recomendável, mesmo para os clientes que geralmente seguem redirecionamentos, que quando exista um redirecionamento para um protocolo não protegido por TLS, como o HTTP ou o Gopher, seja dado um alerta automático ao utilizador e seja pedida uma confirmação explícita para que o redirecionamento seja efetuado. Isto, claro está, assumindo que o cliente tenha implementado o suporte para esses protocolos. Dessa forma, evitar-se-ão transferências de texto simples não intencionais.
O TLS 1.2 é permitido no Gemini, ainda que de forma relutante. Contudo, o TLS 1.3 é drasticamente mais simples e remove muitos criptográficos primitivos inseguros. Porque se permite então o TLS 1.2? Porque apenas o OpenSSL parece ter, atualmente, um bom suporte para TLS 1.3 e, assim sendo, exigir TLS 1.3 ou superior faria com que o uso de bibliotecas como LibreSSL ou BearSSL não fosse adequado.
Os autores de clientes e servidores que optem por oferecer suporte ao TLS 1.2 devem, idealmente, permitir o uso de conjuntos de cifras que ofereçam segurança semelhante ao TLS 1.3. Em particular, o software deve:
Usar apenas Ephemeral Diffie-Hellman (DHE) Ephermeral Eliptic Curve Diffie-Hellman (ECDHE) para acordo de chave, a fim de fornecer sigilo de encaminhamento.
Usar AES ou ChaCha20 como cifras em massa
Usar as funções hash da família SHA2 ou SHA3 para autenticação de mensagens.