Gemini導入のためのベストプラクティス

はじめに

　この文書では、Geminiプロトコルを実装して使用するための様々な規約やアドバイスについて説明します。これらは、プロトコル仕様では義務付けられていませんが、一般的には良いアイデアと考えられています。もしあなたがGeminiソフトウェアを書いていたり、Geminiサイトを構築しているのであれば、正当な理由がない限り、一般的にここで示されたアドバイスに従うべきでしょう。

ファイル名

　Geminiサーバーは、クライアントに提供するファイルのMIMEタイプを通知する必要があります。サーバーがファイルの MIME タイプを知るための最も便利な方法は、ファイル名の拡張子を利用することです。これらのマッピングはほとんど標準化されています（UNIXシステムではしばしば/etc/mime.typesファイルがそれらでいっぱいです）が、Geminiで定義されたtext/geminiタイプで提供されるファイルをサーバーがどのように認識すべきかについては疑問が残ります。

　現在のGeminiサーバーは、この目的のために.gmiまたは.gemini拡張子を使用しているようです。新しいサーバーは、新しいものを追加するのではなく、これらのオプションのいずれかまたは両方をサポートすることが強く推奨されます。

　ウェブサーバの慣習に従って、サーバのファイルシステム上のディレクトリにマップするパスのリクエストを受け取り、そのディレクトリに index.gmi または index.gemini という名前のファイルが存在する場合、そのパスに対して提供されます。

ファイルサイズ

　Geminiサーバーは、提供しているファイルのサイズをクライアントに通知しません。そのため、サーバーの障害によって接続が早期に切断された場合に、それを検出することが困難になることがあります。このような事態が発生するリスクは、ファイルサイズが大きくなるほど高くなります。

　Geminiはまた、大きなファイルの圧縮や、ファイルの破損を検出するためのチェックサムもサポートしていません。

　これらの理由から、Geminiは「非常に大きな」ファイルの転送にはあまり適していません。何をもって「非常に大きい」とするかは、インターネット接続の速度と信頼性、およびユーザーの忍耐力にある程度依存します。経験則から言うと、100MBを超えるファイルは他の方法で転送するのがベストだと思われます。

　もちろん、GeminiはURLスキームを持つあらゆるプロトコルを介して他のオンラインコンテンツへのリンクをサポートしているので、GeminiドキュメントからHTTPS、BitTorrent、IPFSなど、あなたの好きなものを介して提供される大きなファイルへリンクすることが可能です。

テキストエンコーディング

　Geminiは、text/* MIMEタイプの「charset」パラメータを使用して、任意のテキストエンコーディングをサポートしています。これにより、「レガシー」なテキストコンテンツを、不明瞭な地域別エンコーディングで提供することができます。

　新しいコンテンツには、どうか、どうか、どうか、UTF-8を使用してください。Geminiの仕様では、クライアントがUTF-8テキストを処理できることが必須となっています。他のエンコーディングのサポートはクライアント次第であり、保証されていません。UTF-8でコンテンツを提供することは、そのアクセシビリティを最大化し、UTF-8のみをサポートするシンプルなクライアントの実用性を最大化します。

リダイレクト

一般的な注意事項

　リダイレクトは、主に、既存のリンクを壊すことなく、サイトの再構築やサーバー間のサイトの移行を可能にするためにGeminiに搭載されました。このような機能を持たない大規模な相互接続された文書空間は、必然的に「もろい」ものになります。

　しかし、リダイレクトは、一般的に言って、厄介なものです。プロトコルの透明性を低下させ、人々がどのリンクをたどればいいのか、十分な情報に基づいて選択することを難しくしますし、人々のオンライン活動に関する情報を第三者に漏らしてしまうこともあります。Geminiでは、HTTPほどひどくはありませんが（クッキーやリファラーヘッダーがないため）、せいぜい必要悪にとどまっています。

　そのため、リダイレクトを軽率に使用することは控えてください。URL短縮のようなものは、ほとんど何のメリットもありません。一般に、リンク切れを防ぐ以外の目的でリダイレクトを使うのは、よく考えてからにしてください。

リダイレクトの制限

　クライアントは、リダイレクトに従うかどうかの判断をユーザに求めることもできますし、自動的にリダイレクトに従うこともできます。自動的にリダイレクトに従うクライアントを書く場合、以下の問題に留意してください。

　誤った設定や悪意のあるGeminiサーバーは、リダイレクトに盲従するクライアントがリダイレクトの無限ループに陥ったり、非常に長いリダイレクトの連鎖を完了しなければならないような方法でリダイレクトを提供する可能性があります。堅牢なクライアントは、このような状況を検知し、それに応じて行動するのに十分な賢さが必要でしょう。最も単純な実装は、N個以上の連続したリダイレクトを拒否することです。Nは5以下に設定することが推奨されます。これは、HTTPのオリジナル勧告（RFC-2068参照）に沿ったものです。

クロスプロトコルリダイレクト

　クロスプロトコルリダイレクト（すなわち、GeminiからGopherなどの他のものへのリダイレクト）はGemini内で可能ですが、可能としないことが非常に強く推奨されます。しかし、誤った設定や悪意のあるサーバは常にそのようなリダイレクトを提供することができますので、よく書かれたクライアントはそれを検知して適切に応答する準備ができている必要があります。

　一般にリダイレクトに従うクライアントであっても、HTTPやGopherのようなTLSで保護されていないプロトコルへのリダイレクトを提供された場合、自動的にユーザーに警告し、明確な確認を求めることが強く推奨されます（クライアントがこれらのプロトコルのサポートを実装している場合）。これにより、意図しないプレーンテキストの転送を回避することができます。

TLS 暗号スイート

　TLS 1.3は劇的にシンプルで、多くの安全でない暗号プリミティブを削除しているにもかかわらず、GeminiではTLS 1.2が不本意ながら許可されています。これは、現在OpenSSLだけがTLS 1.3をうまくサポートしているようなので、TLS 1.3以上を要求すると、LibreSSLやBearSSLのようなライブラリの使用を妨げることになるからです。
　TLS 1.2をサポートすることを選択したクライアントとサーバーの作者は、理想的にはTLS 1.3と同様のセキュリティを提供する暗号スイートのみを使用することを許可すべきです。特に、そのようなソフトウェアは以下のようにすべきです。

・前方秘匿を実現するために、鍵共有プロトコルにはEphemeral Diffie-Hellman (DHE) か Ephermeral Eliptic Curve Diffie-Hellman (ECDHE)のみを使用する。
・バルク暗号としてAESまたはChaCha20を使用する。
・メッセージ認証には、SHA2またはSHA3系列のハッシュ関数を使用する。

（原典）gemini://gemini.circumlunar.space/docs/best-practices.gmi
（2022年12月13日　初版）

戻る　