DevTools と GitHub で「送らない」を自分で監査する
「データを外部に送信しません」と書かれているだけでは、結局のところ運営者を信用するしかありません。NoSend Tools がコード公開と DevTools での確認可能性を両立させている理由と、具体的な監査手順を整理します。
「送らない」と書かれていることと、送らないことの間のギャップ
プライバシー重視を謳うオンラインツールは増えていますが、その多くは「クライアントサイドで処理します」「データは外部に送信されません」とプライバシーポリシーに書かれているだけで、第三者が後から検証する手段がないことがあります。サイト側のコードはブラウザで実行されているので原理的には監査可能ですが、ミニファイされた JS だけを読み解くのは現実的なコストではありません。
つまり、宣言と検証可能性はセットで提供されないと意味が薄い、という構造的な問題があります。NoSend Tools はこの 2 つを同時に成立させることを設計目標にしています。
Network タブで実際に流れているリクエストを見る
気になるツールのページで Chrome / Firefox / Safari の DevTools を開き、Network タブを記録状態にして「Preserve log」を有効にします。その状態でツールを通常通りに操作 (ファイル選択 → 実行 → 結果ダウンロード) すると、出ているリクエストは ツール本体の HTML / JS / CSS / WASM などの初回ロード分と、サイト共通の解析用ピクセル程度になります。ユーザーが入力した内容そのものを送るリクエストは現れません。
もしどこかでそれが現れたら、それはこのサイトの主張が崩れた瞬間です。ブラウザは送信先の URL とリクエストボディを開発者に見える形で表示してくれるので、専用のセキュリティツールがなくても誰でも実行できます。同じ手順を、競合サービスでも実行してみると、設計の差が可視化されます。
GitHub で実装を読む
DevTools での検証は「実行時の振る舞い」を見るアプローチですが、補完として GitHub 上のソースコードも公開されています (otomomik/nosend-tools)。各ツールの実装は `src/tools/<category>/<slug>/` 配下にあり、入出力やライブラリ呼び出しを直接読めます。ファイルアップロード用のエンドポイントが定義されていないこと、各ツールの本体が `fetch` でユーザー入力を投げ出していないこと、を実装レベルで確認できます。
依存しているオープンソースライブラリはすべて `/libraries` ページに一覧化されていて、ライセンスとリポジトリ URL がまとまっています。そこから各 npm パッケージのソースを辿ることもできます。「ブラウザで動いている JS が、サーバーで動いているコードと同じであることを保証する」のは別の問題 (デプロイ署名・SRI など) ですが、少なくともコードレベルの監査と動作確認の両方の入口は揃っています。