オンラインメモのセキュリティ完全ガイド｜暗号化・7日削除・ゼロ知識の選び方

「暗号化 メモ ブラウザ」「一時共有 メモ」「Privnote 代替」「ゼロ知識」「メモ 自動削除」「オンラインメモ セキュリティ」——検索キーワードはばらつきますが、エンジニアやサポート担当が直面する問いは一つです。この URL にログと API キーを貼って、Slack で渡して大丈夫か？

答えは サービスの設計次第 です。HTTPS だけでは足りません。「暗号化対応」と書いてあっても サーバー側で復号できる タイプもあれば、ブラウザ内 E2EE（エンドツーエンド暗号化） で運営も読めないタイプもあります。さらに 7日自動削除 や Burn-after-read といった 寿命設計 が、漏洩面を時間軸で狭めます。

本記事は、一時的な オンラインメモ共有 を 脅威モデル から整理し、Privnote、OneTimeSecret、Burner Note、textdrop.sh、aNotepad、Kawa Dev Tools の オンラインメモ帳 を横並びで比較する セキュリティ完全ガイド です。煽りはせず、個人・小規模サイト運営の現実も含めて書きます。

---

この記事でわかること

• 一時共有メモ の 脅威モデル（誰が・いつ・どこから読めるか）
• E2EE vs サーバー上パスワード vs 平文ペーストサイト の違い
• AES-GCM と クライアントサイド暗号化 の仕組み（開発者向けに正確に）
• 7日自動削除 を採用する理由（プライバシー・運用・用途境界・E-E-A-T）
• Burn-after-read と 時間ベース削除 の比較
• URL フラグメント鍵 vs 共有コード＋パスワード モデル
• 貼ってはいけないもの（API キー、本番シークレット）
• 漏洩疑い時のインシデント対応
• 主要5サービス＋Kawa の ComparisonTable
• DevTools による実装検証手順

関連する選び方の総合比較は オンラインメモ帳の選び方 を、操作手順は 共有コードで渡す Web メモの使い方 を参照してください。

---

1. 一時共有メモの脅威モデル

セキュリティ議論の前に、何を守り、誰を信頼しないか を決めます。これが Threat Model（脅威モデル） です。

1.1 守りたい資産（Asset）

一時共有メモで扱う典型的な資産は次のとおりです。

• テキスト: エラーログ、設定 JSON、社内 URL、個人情報を含む問い合わせ内容
• 画像: 画面キャプチャ、QR コード、証明書の写し
• 短命クレデンシャル: 検証環境の API キー、一回限りのトークン、VPN パスワード

これらは 機密度はバラバラ ですが、共通して 「永続保管したくない」「漏れたら困る」 という性質を持ちます。

1.2 攻撃者と経路（Threat Actor & Vector）

攻撃者 / 経路	具体例	平文サイトへの影響	E2EE + 短期削除への影響
ネットワーク盗聴	公共 Wi‑Fi、不正 AP	HTTPS なら低リスク	同左
サーバー侵害	DB 漏洩、RCE	平文は全滅	暗号文のみなら鍵なしでは読めない
運営者・従業員	サポート閲覧、バックアップ	平文・サーバー鍵なら可能	ゼロ知識設計なら不可
URL / リンク漏洩	Slack 転送、履歴、スクショ	リンク＝鍵 のサイトは終了	パスワード二要素なら緩和
Referer 漏洩	メモ内リンククリック	現在 URL が外部へ	公開 URL 型で顕著
受信者端末	マルウェア、同期履歴	復号後は平文	復号後は平文（同じ）
ブルートフォース	短いパスワード、短いコード	サーバー PW 型は運営依存	PBKDF2 + 強 PW で緩和
法的アクセス	召喚状、データ開示請求	平文提供の可能性	暗号文のみ提供の可能性

ポイントは、E2EE は「サーバーと配達経路」を信頼しない設計 である一方、復号後の端末・チャット・スクリーンショット までは守れないことです。textdrop.sh の DEV レビュー も、「サーバー側ゼロ知識は、Slack 履歴やクラウド同期ブラウザ履歴まではカバーしない」と明記しています。

1.3 信頼境界（Trust Boundary）

一時共有メモで現実的な信頼境界は次の3層に分けられます。

[Layer A] ブラウザ内暗号化 ─ 運営サーバーを信頼しない
[Layer B] HTTPS + サーバー側アクセス制御 ─ 運営は信頼するがリンク漏洩は防ぎたい
[Layer C] 公開 / 限定 URL の平文 ─ 機密は載せない

Layer A が ゼロ知識 に近い。Layer B は Privnote のパスワード付きリンクや aNotepad のパスワード保護。Layer C は社内手順書の共有など。

「オンラインメモ セキュリティ」を検討するとき、まず どの Layer が必要か を決めると、サービス選定が一気に楽になります。

1.4 一時共有に特有のリスク

永続ノートアプリ（Notion、Keep）と違い、一時共有メモ には次の固有リスクがあります。

1. 共有の急ぎ — セキュリティより速度が優先され、平文サイトが選ばれる
2. 2要素の片方忘れ — コードだけ送る、URL だけ送る、パスワードを同じチャットに書く
3. 寿命の誤解 — 「7日あるから明日でいいか」→ 削除後に問い合わせ
4. 使い捨て値のつもりが本番 — 検証用キーをそのまま本番に
5. 個人運営サイトの継続性 — サービス終了でデータごと消える（必ずしも悪ではないが計画要）

---

2. E2EE vs サーバー上パスワード vs 平文ペースト

「暗号化 メモ ブラウザ」と検索すると、似た文言のサービスが並びます。しかし 暗号化の意味は実装で三種類 に大別できます。

2.1 平文ペーストサイト（①）

aNotepad のような リンク共有型オンラインメモ は、手軽さが最大の武器です。URL を知っていれば読める。非公開・パスワード設定がある場合も、暗号化というよりアクセス制御 に近いことが多いです。

向く用途: 公開しても困らない手順、サンプルコード、社内限定でもリスクの低いテキスト

向かない用途: 個人情報、未公開 API、本番ログ、認証情報

HTTPS は 配達中の封筒 です。届いたあと サーバー上のノートが平文 なら、DB 漏洩・バックアップミス・内部不正で読まれます。

2.2 サーバー上パスワード型（②）

Privnote は リンク1本 で秘密を渡す定番です。オプションで パスワード を付けられますが、本文がサーバー側でどう保持されるか は利用者が直接確認しにくい部分があります。Privnote の強みは 一度読むと（設定により）削除 される Burn-after-read モデルで、寿命を短くする こと自体がセキュリティ施策です。

OneTimeSecret も シークレット配送 に特化し、TTL（有効期限） や 閲覧回数 で寿命を制御します。開発者が CI/CD から短命トークンを渡す例で引用されることが多い 一時共有メモ の代表格です。

向く用途: 短いトークン、一回限りのパスワード、手順のテキスト

注意: リンク漏洩 + パスワードなし = 即読み取り。画像や長文、共同編集には弱い。

2.3 クライアント E2EE / ゼロ知識（③）

textdrop.sh は ブラウザ内 AES-256-GCM で暗号化し、復号鍵を URL フラグメント（# 以降） に載せます。フラグメントは HTTP リクエストに含まれない ため、サーバーは暗号文しか受け取りません。パスワード保護時は PBKDF2 で鍵をラップ し、URL だけでは復号できません。

Kawa Dev Tools の オンラインメモ帳 は 共有コード＋パスワード モデルです。保存前に Web Crypto API で AES-GCM 暗号化し、3文字コード で暗号文を取得、パスワード で復号します。公開 URL は発行しない ため、Referer や URL 漏洩だけでは読めません。

向く用途: ログ断片、スクショ付きメモ、数日以内に何度か読む共有

注意: パスワードを弱くする、コードと PW を同じチャットに書く、7日後に消える——運用ミスは技術で救えません。

2.4 「E2EE」と謳うが確認が必要な点

マーケティング上の E2EE と、暗号学者が言う E2EE はズレることがあります。確認すべきは次の4点です。

1. 暗号化はいつ？ — 送信前（ブラウザ内）か、サーバー到着後か
2. 鍵は誰が持つ？ — ユーザーだけか、サーバーもデータ鍵を持つか
3. 復号はどこで？ — ブラウザだけか、サーバーが復号して HTML を返すか
4. メタデータは？ — IP、作成時刻、サイズ、形式は残る（多くのサービスで不可避）

textdrop.sh の Security FAQ は、この点をかなり明示的に書いています。新規ペーストはサーバーが復号できない とし、旧 v1 モデルはサーバー側にデータ鍵がある 可能性にも触れています。サービス選定では いつの実装か も確認対象です。

---

3. AES-GCM とクライアントサイド暗号化の仕組み

「暗号化 メモ ブラウザ」の中身を、実装レベルで理解すると Privnote 代替 を誤選しにくくなります。

3.1 なぜ AES-GCM か

AES（Advanced Encryption Standard） は対称鍵暗号のデファクトスタンダードです。GCM（Galois/Counter Mode） は 認証付き暗号（AEAD） で、改ざん検知 付きで暗号化します。暗号文を1ビット書き換えても復号時に検知できる——ペーストサイトで重要です。

Web ブラウザでは Web Crypto API の crypto.subtle.encrypt({ name: "AES-GCM", ... }) で利用します。textdrop.sh も Kawa Dev Tools のメモも AES-256-GCM を採用しています。

3.2 鍵導出：PBKDF2

ユーザーが覚える パスワード はそのまま AES 鍵にはしません。PBKDF2（Password-Based Key Derivation Function 2）で ソルト付きハッシュ反復 から鍵を導出します。

Kawa Dev Tools のメモ実装（2026年7月時点）では:

• PBKDF2 + SHA-256
• 100,000 イテレーション
• 16 バイトランダムソルト（メモごと）
• 12 バイト IV（GCM 推奨サイズ）
• 出力形式: salt:iv:ciphertext（Base64 連結）

パスワード + ランダムソルト
    ↓ PBKDF2 (100,000回)
AES-256 鍵
    ↓ AES-GCM 暗号化
暗号文（サーバーへ送信）

パスワードが弱い と PBKDF2 も救いきれません。1234 や password は オフライン総当たり 対象です。

3.3 クライアントサイド暗号化のフロー

Kawa Dev Tools（コード＋パスワード型） の流れ:

1. ユーザーがテキスト・画像を入力
2. ブラウザ内で PBKDF2 → AES-GCM 暗号化
3. 暗号文のみ POST（Cloudflare Workers 等）
4. サーバーは 3文字 ID と暗号文・期限メタデータを保存
5. 受信者がコード + 同一パスワードを入力
6. ブラウザが暗号文を GET → ローカル復号 → 表示

textdrop.sh（URL フラグメント鍵型） の流れ:

1. ブラウザ内でデータ鍵を生成し AES-GCM 暗号化
2. 復号鍵（または PW でラップした鍵）を URL の # 以降に載せる
3. サーバーには paste ID と暗号文のみ
4. 受信者がフル URL を開く → # 以降を JS が読み取り復号
5. # 以降は HTTP リクエストに載らない

3.4 ゼロ知識との関係

ゼロ知識（zero-knowledge） とは、サービス提供者が ユーザーの秘密（パスワードや復号鍵）を知らない 設計を指すことが多いです。厳密な暗号学の「ゼロ知識証明」とは別語彙ですが、オンラインメモ セキュリティ の文脈では 「サーバーだけ見ても読めない」 意味で使われます。

textdrop.sh のプライバシーポリシー は、新規ペーストについて 平文を保持しない、召喚状が来ても復号鍵を渡せない（鍵は URL フラグメントのみ）と説明しています。一方 メタデータ（形式、サイズ、期限、作成時刻）は残ります。完全匿名 ではありません。

3.5 画像の暗号化

テキストだけでなく 画像添付 も同じ鍵体系で暗号化できます。Kawa Dev Tools のメモは最大10枚（JPEG/PNG/GIF/WebP）を リサイズ・圧縮後に暗号化 します。一時共有メモ で PC→スマホにスクショを渡す用途では、平文 URL 型より E2EE の方が合理的です。

---

4. なぜ7日自動削除か——プライバシー・運用・用途境界（E-E-A-T）

タイトルに 7日削除 が入る理由は、Kawa Dev Tools の オンラインメモ帳 が 保存から7日後に自動削除 する設計だからです。セキュリティガイドとして なぜ7日なのか を、Experience・Expertise・Authoritativeness・Trustworthiness の観点で整理します。

4.1 プライバシー：忘れたメモは漏洩面になる

人間は 「あとで消そう」 と思って消しません。GitHub に上がった秘密鍵、Slack に残ったトークン——典型パターンです。メモ 自動削除 は 技術的な忘れ防止 です。

• 7日 — 週末を挟んでも読める。月曜の standup までに共有コードを渡す現場と相性がよい
• 1日 — より機密向きだが、タイムゾーン跨ぎで消える事故も
• 30日 — textdrop.sh の上限のように長めのコード共有向き

7日 は 「一時共有だが、数日は再読みたい」 境界線としてバランスが取れています。Privnote の 一度きり より寛容、Keep の 永続 より安全側です。

4.2 運用：個人・小規模サイトの現実

Kawa Dev Tools は 個人運営 で、Cloudflare 無料枠 を中心にホスティングしています。無制限永続保存 は:

• R2 / KV / D1 のストレージコスト
• 転送量（画像10枚×多数メモ）
• 不正利用（巨大ペースト、ボット）

を押し上げ、無料提供の継続性 を脅かします。7日 TTL は コスト上限 でもあり、ユーザーにも 「ここは倉庫ではない」 と明示できます。

OneTimeSecret も TTL を設定可能。Burner Note はより短いタイマー。textdrop.sh は 1時間〜30日を選択式——寿命はプロダクトの約束 です。

4.3 用途境界（E-E-A-T の Expectation）

Google の E-E-A-T 観点で言えば、ユーザー期待値の一致 が信頼に直結します。

期待	適した設計	7日削除型の位置
永久に残るナレッジ	Notion, Keep	✗ 不向き
今日中に1回だけ見せる	Privnote, OTS	△ 長すぎる場合あり
今週中に数回参照	7日削除	◎
コードを Markdown で渡す	textdrop.sh	△ TTL 選択可

7日で消える ことを UI と FAQ で明示 することは、「消えたのはバグではない」 という Trust の一部です。サポート問い合わせの削減にもなります。

4.4 7日を過ぎたら

復元不可 です。サーバーから 暗号化 blob ごと削除 され、運営も戻せません。残したい内容は 期限内にコピー し、Obsidian・Keep・社内 Wiki 等へ移してください。詳細は 共有コード Web メモの使い方 を参照。

---

5. Burn-after-read vs 時間ベース削除

メモ 自動削除 には トリガーが2系統 あります。混同すると Privnote 代替 を誤選します。

5.1 Privnote / OneTimeSecret の Burn モデル

Privnote の既定イメージは リンクを開いたら消える です。リンクを開かれない 場合、設定次第で 期限まで残る こともあります——未開封 URL の漏洩 リスクは残ります。

OneTimeSecret は シークレットページの表示回数 を明示的に制限できます。CI から API で secret を登録 し、受信者 URL を別経路で渡す 開発者向け フローが確立しています。

長所: 読まれた時点で サーバーから消える — 二次漏洩面が短い

短所: 受信者が 開く前に送信者が確認できない（「読んだ？」の確認）。誤クリック（プレビュー bot）で消える事故もゼロではない

5.2 Burner Note のタイマー消滅

Burner Note は 自己消滅メモ として紹介される 一時共有メモ です。Privnote ほど 一度きり に徹せず、時間経過で消える イメージが強いサービスです（機能詳細は変更されうるため、利用前にサイト表示を確認してください）。

向く用途: 短時間だけ残すメモ、カジュアルなテキスト

注意: 暗号化・画像・長文への期待は控えめ。本番秘密 は載せない

5.3 7日削除（Kawa）の位置づけ

Kawa Dev Tools のメモは 閲覧回数では削除しません。保存から7日 で必ず消えます。

• 未読でも7日で消える — Burn 型より 送信者に優しい（相手が忙しくても猶予）
• 何度でも読める — 同じコード + PW で期限内再取得
• 上書き不可 — 修正は新規作成

「一度だけ」 が必要なら Privnote / OneTimeSecret。「今週中なら何度でも」 なら 7日 TTL 型。

5.4 textdrop.sh のハイブリッド

textdrop.sh は burn-after-read と 1h / 1d / 7d / 14d / 30d の expiry を組み合わせ可能です。Security ページでは 機密には burn + 短い expiry + パスワード を推奨しています。Privnote 代替 としてコード共有まで視野に入れるなら、Markdown・シンタックスハイライト対応は textdrop.sh の強みです。

---

6. URL フラグメント鍵 vs 共有コード＋パスワード

ゼロ知識 系サービスでも 鍵の渡し方 は2大モデルに分かれます。

6.1 URL フラグメント（# 以降）の特性

RFC 的に fragment はサーバーに送られません。だから textdrop.sh はサーバーに鍵を載せない 設計が成立します。

利点:

• リンク1本で 鍵付き共有（PW なし standard paste）
• サーバー侵害・召喚状から コンテンツを守りやすい

欠点:

• フル URL が秘密 — # 以降を落とした不完全 URL では復号できない
• Slack / Teams / メール プレビュー がリンクを触るかどうかはクライアント依存
• ブラウザ 履歴同期（Chrome アカウント等）に鍵が載る
• Referer には fragment は載らない が、アドレスバー写り は別問題

DEV Community の textdrop.sh レビュー は、「システムはサーバーを守るが、他のすべての面を守るわけではない」と冷静に書いています。

6.2 共有コード＋パスワード（Kawa 型）

公開 URL を発行しない ため:

• Slack に https://example.com/memo/abc のような 固有 URL が残らない
• 3文字コード はエントropy が低い → パスワードが必須（設計上の前提）
• コードとパスワードを 別経路（例: コードはチャット、PW は電話）で渡す運用が有効

利点:

• URL 漏洩ベクトルが 読み込みページの固定 URL に限定
• 画像添付 + 10万文字 など メモ帳としての機能 が厚い

欠点:

• 2要素渡しの 手間
• コード3文字は 総当たり理論上可能 → レート制限・Turnstile 等のサーバー側防御に依存

6.3 どちらを選ぶか

シナリオ	推奨モデル
Markdown / コードを1リンクで渡したい	textdrop.sh
スクショ複数 + 長文ログ	Kawa（コード + PW）
非エンジニア相手に リンク1本 で済ませたい	Privnote（リスク承知）または textdrop PW 付き
公開手順書	aNotepad 限定 URL

---

7. 貼ってはいけないもの——API キーと本番シークレット

オンラインメモ セキュリティ ガイドで最も重要な 禁止リスト です。E2EE でも載せない ものがあります。

7.1 載せてはいけないもの

カテゴリ	例	理由
本番マスター資格情報	DB root PW、AWS アカウント root	ローテーション不能に近い、影響全領域
長寿命 API キー	本番 Stripe / OpenAI / GitHub PAT（広スコープ）	漏洩時の被害が継続
.private 鍵	SSH private key、TLS 秘密鍵	復号不能なら再発行が大仕事
大量個人情報	顧客 CSV、医療・マイナンバー	法令・契約上、ペーストサイトは不適切
暗号資産シード	12語フレーズ	textdrop.sh も高リスク例として言及

7.2 どうしても一時渡しする場合

1. 使い捨てクレデンシャル — 読み取り専用・最小スコープ・短 TTL
2. 即ローテーション — 読み取り確認後 無効化
3. 専用ツール — 本番は 1Password Connect、AWS Secrets Manager、HashiCorp Vault
4. OneTimeSecret / Privnote — 短い文字列 の 一度きり なら 相对 的にマシ（本番キーは依然非推奨）

7.3 「検証環境だから」は危険

検証用キーが 本番と同一 だったり、検証 DB に本番コピー があるケースは珍しくありません。一時共有メモ に載った 検証キー = 本番キー 事故を前提に、環境分離 を先に確認してください。

---

8. 漏洩疑い時のインシデント対応

メモ 自動削除 や Burn-after-read でも、復号後の端末 や チャット に平文が残れば漏洩します。疑いがあるときの 初動 を固定化しておきます。

8.1 ローテーションの優先順位

1. 認証情報（パスワード、API キー、OAuth refresh token）
2. セッション（Cookie、JWT、デバイストークン）
3. 連鎖資産（同じ PW を使い回している SaaS）

Privnote や OneTimeSecret は 既読後削除 でも、読まれた時点で平文 です。「削除済みだから安心」ではなく 鍵の無効化 が本体です。

8.2 ログ保全

個人運営サイトでは 詳細アクセスログ が限られる場合があります。自社側 の Slack Export、プロキシログ、WAF ログの方が証跡になることも。インシデント前 から どこにログがあるか を把握しておいてください。

8.3 再発防止

• 一時共有メモ は Layer A/B の用途に 限定
• DevTools で暗号化確認 をセキュリティレビューのチェック項目に
• 新人向けに 「Slack に本番キーを貼らない」 ルールを 具体例付き で教育

---

9. サービス比較——Privnote / OneTimeSecret / Burner Note / aNotepad / Kawa

参考: textdrop.sh は上表に含めませんが、URL フラグメント鍵 + Markdown + burn/expiry 選択 で Privnote 代替 の 開発者向け 候補です。ゼロ知識の説明は Security ページ が詳しいです。

9.1 Privnote

長所: 登録不要、リンク1本、一度読むと消える 文化が浸透

短所: パスワードなし設定時の URL=鍵、サーバー側実装の透明性、フィッシング偽サイト（privnote.com 似せ URL）問題——公式 URL を確認

向く人: 短いテキストを ワンショット で渡す（本番キーは不可）

9.2 OneTimeSecret

長所: TTL、閲覧回数、API で自動化。エンジニア文化に馴染む

短所: メモ帳機能は薄い。リンク漏洩 リスクはゼロではない

向く人: デプロイ時の 短命 secret、サポートが 一時 PW を渡す

9.3 Burner Note

長所: タイマー消滅 の 一時共有メモ として直感的

短所: Enterprise 向け SLA や監査ログは期待しない。セキュリティ whitepaper があるわけではない

向く人: 数時間以内のカジュアルメモ

9.4 aNotepad

長所: URL で何度も開ける。公開範囲の選択肢

短所: オンラインメモ セキュリティ 厳密派には 平文保管 がネック。Referer・URL 漏洩

向く人: 非機密の 永続に近い Web メモ

9.5 Kawa Dev Tools メモ

長所:

• ブラウザ内 AES-GCM + PBKDF2（100,000）
• 3文字コード + パスワード（URL 非発行）
• 7日自動削除
• テキスト10万文字 + 画像10枚
• Turnstile 等で bot 対策

短所:

• 個人運営 — 24/7 サポート、監査認証、データセンター冗長は期待しない
• 7日固定 — 延長不可
• 上書き不可
• コード3文字 + 弱 PW の組み合わせは 理論上リスク

向く人: 開発者・サポートが 暗号化メモ を 数日 渡す。Privnote 代替 として URL 漏洩に強い 方式が欲しい場合

---

10. 個人・小規模サイト運営を信頼するということ

Kawa Dev Tools、Burner Note、textdrop.sh（Empowered Technology LLC）のような 個人・小規模 サービスをどう評価するか——正直に書きます。

10.1 信頼できる信号

• Security / Privacy ページ が具体的（アルゴリズム名、鍵の扱い、保持期間）
• クライアント側暗号化 が DevTools で確認できる
• データ最小化（メール不要、アカウント不要）
• 自動削除 が明文化されている
• オープンソース または実装の検証可能性

10.2 信頼の限界

• サービス終了 — textdrop.sh Terms も 可用性保証なし と明記
• 無料枠依存 — コスト増でポリシー変更の可能性
• サブポエナ対応 — 個人運営に 24時間 IR チーム は期待しない
• コンプライアンス — HIPAA / PCI 等の 正式認証 は通常ない

10.3 実務的なスタンス

一時共有メモ は 「信頼できる配達便」 として使い、「銀行の金庫」 として使わない。本番秘密は Vault / パスワードマネージャー。オンラインメモ は Layer A/B の短命データ に限定すれば、個人運営サイトでも 合理的なリスク になります。

---

11. DevTools で暗号化を検証する

暗号化 メモ ブラウザ 表示を 信じない でください。自分で確認 する手順です。

11.1 Network タブ

1. Chrome DevTools → Network
2. メモ保存操作を実行
3. POST リクエストの Payload を開く
4. 平文の日本語・API キー・sk- prefix が見えないこと
5. Base64 っぽい 暗号文 またはフィールド名 content が意味不明な文字列であること

textdrop.sh や Kawa のように ゼロ知識 なら、ここに メモ本文そのもの は出ません。

11.2 Sources / 検索

1. Sources パネルで crypto.subtle.encrypt を検索
2. AES-GCM、PBKDF2、deriveKey の存在
3. 暗号化関数が fetch より前 に呼ばれているか（Call Stack）

Kawa Dev Tools のメモは encryptData → deriveKey（PBKDF2, 100000 iterations）→ AES-GCM の流れです。

11.3 フラグメント鍵の確認（textdrop.sh）

1. ペースト作成後、URL の # 以降 に長い鍵素材があるか
2. Network で GET /api/paste/:id のレスポンスに 平文が無い か
3. # 以降を削除 した URL では復号 失敗 するか

textdrop.sh Security FAQ の「Are standard pastes zero-knowledge?」と同じ検証です。

11.4 パスワードがサーバーに行っていないか

Preserve log を ON にし、保存・読み込み両方のリクエストを確認。password フィールドが 平文 PW を送っていないか。Kawa 型は パスワードは復号にのみ使用 し、サーバーには 派生前の PW を送らない 設計が理想です（実装は都度 DevTools で確認）。

11.5 限界

DevTools 検証は その時点の本番 JS に依存します。サプライチェーン攻撃 や 悪意ある JS 差し替え は別問題。重要度が高い ほど、自社ホスト の Vault に寄せるべきです。

---

12. 用途別——Privnote 代替の選び方

12.1 キーワードとの対応

キーワード	本記事での結論
暗号化 メモ ブラウザ	Web Crypto AES-GCM + PBKDF2。Network で payload 確認
一時共有 メモ	寿命（Burn vs TTL）を先に決める
Privnote 代替	URL 漏洩が怖ければ code+PW または textdrop PW 付き
ゼロ知識	サーバーだけでは読めない設計。端末・チャットは別
メモ 自動削除	忘れ防止。7日は再読みと消去のバランス
オンラインメモ セキュリティ	Layer 選定 + 載せないもの + IR + DevTools

---

13. よくある誤解

誤解1: HTTPS なら安全 — 転送中のみ。サーバー上が平文なら終わり。

誤解2: 暗号化対応なら E2EE — サーバーが鍵を持つ サーバー側暗号化 もある。

誤解3: Burn したから漏洩していない — 読まれた時点で 受信者環境 に平文。

誤解4: 7日あるから急がない — 7日は 上限 であり 推奨保管期間 ではない。

誤解5: ゼロ知識ならパスワード不要 — textdrop でも リンク盗難対策 に PW 推奨。

誤解6: 個人サイトは危ないから使わない — 用途を 一時・非恒久 に限定すれば 有効な選択肢。

---

14. 実践チェックリスト——保存前・共有前・削除前

現場でそのまま使える 36項目 を3フェーズに分けます。印刷または Notion にコピーして、チームの 一時共有メモ ポリシーのたたき台にしてください。

14.1 保存前（12項目）

1. 載せる情報は 本当にオンラインメモが必要か（Vault で足りないか）
2. 機密度レベル を決めた（公開 / 社内限定 / 機密 / 禁止）
3. 選んだサービスの 暗号化モデル を理解した（平文 / サーバー / E2EE）
4. DevTools で payload に平文が無いことを確認した（初回のみでも可）
5. パスワード は推測されにくい（12文字以上推奨、辞書語禁止）
6. API キー は使い捨て・最小スコープ・短 TTL か
7. 個人情報 を含む場合、法令・契約・社内規程を確認した
8. 画像 に余計な UI（アドレスバー、通知）が写っていないか
9. 保存期間 が用途と一致している（Burn / 7日 / 30日）
10. サービスが HTTPS のみ か
11. フィッシング URL ではないか（Privnote 偽サイト等）
12. バックアップ不要 なデータか（7日削除型なら特に）

14.2 共有前（12項目）

1. コードとパスワード を別経路で渡す計画がある
2. URL フラグメント 型なら # 以降を欠落させない
3. Slack / Teams で URL プレビュー が問題ないか
4. メール 転送チェーン に載ってもよい相手か
5. 受信者の 端末（私物 / 社給）を意識した
6. Screenshot ツール のクラウド同期を相手に確認したか
7. 一度きり で足りるなら Burn 型を選んだか
8. 何度も読む 必要なら TTL 型（7日等）を選んだか
9. 共有チャンネルに Bot やログ収集 が居ないか
10. Referer が問題になる外部リンクをメモ内に含めていないか
11. 受信者に 期限（7日、burn 等）を伝えた
12. 読み取り後 ローテーション が必要な値か事前に合意した

14.3 削除前・削除後（12項目）

1. 期限内に 必要な内容をコピー した（7日型）
2. 受信者が 読み取り完了 を報告した
3. 使い捨て API キー を revoke した
4. 同じ値の使い回し が無いか確認した
5. Slack / メールから メッセージ削除 を検討した（完全削除は限定的）
6. ブラウザ 履歴 に URL 鍵が残っていないか（共有端末注意）
7. インシデント の有無を確認した
8. 長期保管が必要なら Keep / Wiki へ移行した
9. 次回同じ用途で 同じサービス でよいか再評価した
10. 個人運営サイト の継続性リスクを Accept した
11. チーム内に 振り返り（必要なら）を残した
12. シークレットマネージャー への恒久移行を検討した

このチェックリストは ゼロ知識 や メモ 自動削除 を使っても 人為ミス をゼロにできません。プロセス と 技術 の両方で オンラインメモ セキュリティ を担保してください。

---

15. まとめ——オンラインメモ セキュリティの原則

1. 脅威モデル — サーバー・URL・受信者端末のどこを守るか決める
2. 暗号化の場所 — ブラウザ内 E2EE（textdrop.sh、Kawa）が最強クラス。平文ペーストは非機密のみ
3. 寿命 — Burn-after-read（Privnote、OTS）vs TTL（7日 Kawa、textdrop 選択式）
4. 鍵の渡し方 — URL # フラグメント vs コード + パスワード
5. 載せない — 本番 API キー、秘密鍵、大量 PII
6. 漏洩時 — 即 revoke、ログ調査、Vault へ移行
7. 検証 — DevTools Network / Sources で 自分の目 で確認
8. 信頼 — 個人運営は 一時配達 として使う。金庫にしない

Privnote、OneTimeSecret、Burner Note、textdrop.sh、aNotepad、Kawa Dev Tools の オンラインメモ帳 は、どれも 万能 ではありません。情報の機密度 × 寿命 × 共有の摩擦 の3軸で選べば、一時共有メモ は安全側に倒せます。

→ オンラインメモ帳を試す

---

参考文献・関連リンク

• Privnote — Burn-after-read 型シークレットリンク
• OneTimeSecret — TTL・回数制限付きシークレット配送
• textdrop.sh Security — ゼロ知識・AES-GCM・URL フラグメント鍵
• textdrop.sh Privacy — データ保持と法的開示
• DEV: textdrop.sh Review — 開発者視点の長所・短所
• オンラインメモ帳の選び方（当サイト）
• 共有コード Web メモの使い方（当サイト）
• aNotepad / NotePal vs Kawa（当サイト）