ジェネレーター

ジェネレーターは、処理がどこで行われるかが問題にならない唯一の種類のツールに見えます。実際には2重に問題になります。

第1の理由は、サーバーサイドのジェネレーターはあなたに渡した識別子をすべて目にしていることです。それらが主キー、APIキー、招待トークン、あるいは権限の伴う他の何かになった場合、第三者がそのリストを握っていることになります。悪用される可能性は低いとしても、完全に回避できた露出であることに変わりはありません。ブラウザには十分に優れた暗号学的乱数ソースが組み込まれているのですから。

第2は品質です。嘆きたいほど多くのオンラインジェネレーターがMath.random()を呼び出しています。高速な非暗号学的PRNGです。出力はランダムに見える程度に一様で、先行する短い値列から予測できます。テストフィクスチャには無害です。アクセスを制御するものには脆弱性であり、出力を見ても両者を区別する手がかりはありません。これらのツールはcrypto.getRandomValues()だけを使います。

UUIDのバージョン選択は、最も正しく決める価値のある決断でありながら、たいてい偶然に任されています。v4（純粋なランダム）はほぼどこでもデフォルトですが、規模が大きくなると構造的な理由で主キーとして不適です。ランダムな値はB-treeインデックス上に散らばるため、挿入のたびに異なるページに触れ、キャッシュヒット率が崩壊し、インデックスは断片化します。チームがこれに気付くのは、たいてい数百万行を過ぎたあたりで、書き込みスループットが原因不明のままゆっくり劣化する形です。

v7は先頭48ビットにミリ秒のタイムスタンプを置くことでこれを解決します。時間的に近い識別子はソート順でも近くなり、挿入はインデックスのホットな末端に追記されていきます。RFC 9562のもとでデータベースキーの正しいデフォルトはv7です。ただしトレードオフは現実にあり、明記する価値があります。v7の識別子は、読める人には自分の生成時刻を公表します。公開に露出する識別子でそれが問題になるなら、v4が依然として正解です。

v1は完全性のために、またレガシーデータを読むために含まれています。v1はタイムスタンプを、本来の形では生成したマシンのMACアドレスをエンコードします。それが支持を失った理由であり、v1を作れることよりも検査できることの方が有用である理由でもあります。生成した値を別の表現に変換する必要があれば、Base64ツールが隣にあり、JSONフォーマッターは識別子を貼り込んだシードファイルを整えてくれます。