HOW IT WORKS
ブラウザ内だけでどう動かしているか
NoSend Tools の各ツールがサーバーを介さずに動く仕組みを、使用しているブラウザ標準 API、取り込んでいる WebAssembly ライブラリ、入力データが通る経路の 3 つの観点で説明します。
1. ブラウザ標準 API で完結するツール
テキスト系・暗号系・時間系のツールの多くは、追加ライブラリを必要とせず、ブラウザに組み込まれている API だけで動きます。Base64 エンコードは TextEncoder で UTF-8 バイト列に変換した結果を btoa に渡す、JWT 署名検証は SubtleCrypto (Web Crypto API) の `verify(...)` を呼ぶ、ハッシュ計算は `subtle.digest('SHA-256', bytes)` を直接呼ぶ、タイムゾーン変換は Intl.DateTimeFormat と IANA タイムゾーン名でブラウザのネイティブ実装に任せる、といった構成です。
ブラウザ標準 API はサンドボックス内で完結しており、関数呼び出しの引数や戻り値が自動的にサーバーへ送信されることはありません。各ツールのコードからもネットワーク呼び出し (`fetch` / `XMLHttpRequest`) はユーザー入力を投げ出す方向には書かれていないため、入出力は完全にページのメモリ内に閉じます。
2. WebAssembly で動く重いライブラリ
動画変換 (ffmpeg.wasm)、HEIC デコード (libheif-js)、PDF 操作 (pdf-lib / PDF.js)、PDF パスワード解除 (qpdf の WASM ビルド)、日本語形態素解析 (kuromoji.js)、音声/画像 ML モデル (transformers.js + Whisper / RMBG) などは、ネイティブ実装の C / C++ / Rust ライブラリを WebAssembly にコンパイルしてブラウザに取り込んでいます。
WebAssembly は ECMAScript と同じプロセス内で動くサンドボックスで、ホスト (ブラウザ) が許可した capability (DOM 操作・ファイル選択・メモリ確保) しか使えません。WASM モジュール自体にネットワークソケットを開く能力はなく、データは WASM のリニアメモリと JavaScript の TypedArray の間で copy / view される範囲に閉じます。30 MB の ffmpeg.wasm を初回読み込むのと、ユーザーが選んだ動画ファイルをサーバーに送るのは別の話で、前者はツールコード自体のダウンロードに過ぎません。
3. データが通る経路 — 「外に出る経路がコードに無い」
ユーザーがファイル選択ダイアログで選んだファイルは、`<input type="file">` か Drag & Drop の `FileSystemFileEntry` 経由でブラウザのページプロセスに渡されます。NoSend Tools は、その後の経路を「ブラウザ内処理 → ローカルダウンロード」だけに限定しています。ファイル内容を `fetch` の body に乗せる経路はどのツールにもありません。Report ダイアログから送信するのは、ユーザーが手で書いたテキスト本文のみで、ツールの入力データを自動添付する仕組みはありません。
確認手順も明確です。気になるツールのページで DevTools の Network タブを記録状態にしておき、入力 → 実行 → 結果ダウンロードを行うと、リクエスト一覧にはツールコード本体の初回ロード分しか並びません。第三者監査の入口として、サイト全体のソースコードは GitHub (otomomik/nosend-tools) で公開しています。
4. 静的サイト + Cloudflare Workers Static Assets
サイト本体は Astro による静的サイトジェネレーション (SSG) で全 743 ページが事前ビルドされ、Cloudflare Workers Static Assets で配信しています。Worker スクリプト側で動的にレスポンスを組み立てる経路は最小限に抑え、ユーザーが触るすべてのページは静的 HTML として配信されます。
唯一の動的経路は Report ダイアログのフォーム送信で、これは Cloudflare D1 に書き込みます (詳細はプライバシーポリシーを参照)。ツール本体の入出力データは引き続きブラウザ内に閉じます。広告 (Google AdSense) は外部 SDK が読み込まれますが、ツールの入力データを送信する経路はサイトのコードに存在しません。