·19 分鐘閱讀·drrop.cc

匿名分享的隱私技術：從 HTTPS 到 client-side 的 7 層保護

「匿名分享」比想像中難。本文 4000 字拆解 7 層隱私技術 — HTTPS / Referrer 控制 / 密碼 hash / token 一次性 / e2e 加密 / client-side 處理 / 合規規範 — 以及 attack 場景。

「我想匿名分享一段影片給朋友」聽起來簡單 — 上傳 → 拿連結 → 傳朋友。但真正「匿名」涉及 7 層獨立的技術考量，每一層都可能洩漏隱私，每一層都有 attack scenario。

這篇 4000 字從 HTTPS 講到端對端加密、從不存 IP 到 client-side 處理、從合規規範到 attack scenarios — 把「匿名分享」這個看似簡單的需求完整拆開。

為什麼匿名分享比想像難

普通的「分享一個檔案」流程：

  1. 你上傳檔案到服務 X
  2. 服務 X 給你一條連結
  3. 你傳給朋友
  4. 朋友點開看

每一步都有隱私洩漏點：

  • 步驟 1：服務 X 知道檔案內容、你的 IP、上傳時間
  • 步驟 2：連結本身可能含 user 識別資訊
  • 步驟 3：你傳給朋友的管道（LINE / Email / SMS）可能被 host 看到
  • 步驟 4：朋友的 IP、看的時候、看了多久全在服務 X 的 log

「匿名」= 切斷所有可識別 user 身份的線索。實作上需要 7 層獨立技術。

Layer 1：HTTPS / TLS（基礎）

為什麼重要

如果你跟服務之間的連線是 HTTP（非加密），網路上任何中間節點都能看到傳輸內容：

  • 你 ISP（譬如中華電信）
  • WiFi 熱點主人（譬如咖啡廳 router）
  • 國家級監控

HTTPS 用 TLS 加密 — 中間節點只看到「有東西在傳」，看不到內容。

攻擊場景

  • 公開 WiFi MITM：攻擊者架假 hotspot、user 連上後攔截所有非 HTTPS 流量
  • DNS hijacking：某些國家 ISP 改 DNS 把 user 導去仿冒站
  • State-level surveillance：政府要求 ISP 留存 user 流量 metadata

防禦

  • 服務必須強制 HTTPS：HTTP → 301 redirect → HTTPS
  • 啟 HSTS（Strict-Transport-Security）：瀏覽器記住「以後永遠用 HTTPS」
  • 用 TLS 1.3（不要 TLS 1.0 / 1.1，已 deprecated）

drrop.cc 實作：

  • Cloudflare 自動 HTTPS（必要時 redirect）
  • CF 預設 TLS 1.3 + HTTP/2 + HTTP/3
  • TLS cert 由 Google Trust Services 簽發

但 HTTPS 不足以匿名

HTTPS 只保護傳輸內容。它不保護：

  • 你訪問了哪個 host（SNI 仍是明文）
  • 你的 IP 在 server log（即便 TLS 之後仍記）
  • DNS query 可能洩漏（除非用 DoH / DoT）

HTTPS 是必要條件，不是充分條件。

Layer 2：不存 IP / Referrer 控制

為什麼重要

即便 HTTPS 保護傳輸，伺服器 log 仍會記 user IP。從 IP 可推算：

  • 地理位置（city-level 準確）
  • ISP
  • 大致裝置類型
  • 多次訪問可以指紋化使用者

對「真匿名」需要服務端不存 IP。

實作策略

Strategy A：完全不記任何 user metadata

最嚴格。但連 rate limit 都做不到 — 任何人可以無限次 abuse。

Strategy B：Hash IP 後存

stored_value = HMAC-SHA256(IP + secret_salt)

這個 hash:

  • 不可反推到原始 IP
  • 但同一 IP 多次訪問仍 collide 到同一 hash → 可做 rate limit
  • 連續訪問模式仍可追蹤（但不知是誰）

drrop.cc 用這個策略。

Strategy C：完全匿名 + 沒 rate limit

像 Tor hidden service 那種。但代價是被 abuse 機率高。

Referrer 洩漏

當 user 從 page A 點連結到 page B，瀏覽器自動把 page A 的 URL 送給 page B 作 referer header：

GET / HTTP/1.1
Host: target.com
Referer: https://drrop.cc/l/abc123  ← 洩漏 short URL

如果 short URL 本身敏感（譬如含 user ID），就洩漏了。

drrop.cc 設 Referrer-Policy: no-referrer — 跳轉時完全不送 referrer。

攻擊場景

  • IP 反推：服務 log 被駭 / 政府要求調閱 → IP → user
  • Cross-site tracking：服務跟廣告 network 共享 IP → user 跨站行為被追蹤

詳見 點擊統計重要嗎。

Layer 3：密碼 hash 與 token 一次性

為什麼重要

「密碼保護」是常見需求 — 但密碼怎麼存決定了真隱私還是假。

錯誤做法 1：明文存密碼

INSERT INTO videos (password) VALUES ('mySecret123')

DB 被駭 → 攻擊者拿到所有 user 密碼。常見災難級案例。

錯誤做法 2：MD5 / SHA-1 hash

INSERT INTO videos (password_hash) VALUES (md5('mySecret123'))

MD5/SHA-1 太快 — 攻擊者用 rainbow table（pre-computed hash table）秒解。

正確做法：PBKDF2 / bcrypt / Argon2 with salt

const salt = randomBytes(16);
const hash = pbkdf2('mySecret123', salt, 100000_iterations);

慢、加 salt、每個密碼 hash 不同。攻擊者拿到 DB 每個密碼要單獨破解 + 慢 100k 倍。

drrop.cc 用 PBKDF2-SHA-256 + 100,000 iterations。

Token 一次性

服務通常給 user 一個「deletion token」或「access token」。設計關鍵：

  • 長度足夠：32 bytes random（128 bits entropy） → 不可猜
  • 一次性：一旦使用 → 失效（避免被截獲後 replay）
  • HMAC 簽章：server 驗證 token 是自己發的（不是攻擊者偽造）

drrop.cc 的 deletion token 是 UUID v4（128 bits），存 D1，使用後 row 即被刪。

攻擊場景

  • DB 被駭 → 密碼 hash 被偷 → 慢慢破解（每個密碼幾分鐘到幾年）
  • Token 截獲 → 攻擊者用偷來的 token 刪 / 偷你的內容

Layer 4：後端隔離與 redirect 設計

Worker proxy + R2 隔離

drrop.cc 影片放 R2，但不公開 R2 URL。流程：

user → drrop.cc/api/stream/abc → Cloudflare Worker
                                  ↓ 驗證 HMAC token
                                  ↓ 動態 sign R2 URL
                                  ↓ proxy stream content
                                ← 回給 user

R2 物件本身 private — 沒 valid token 任何人都拿不到內容。

Range request 支援

影片串流需要 HTTP Range（譬如 user 拖到中段播放）。Worker proxy 必須支援：

  • 收到 Range: bytes=12000-16000 → 從 R2 fetch 同範圍 → 回給 user
  • 確保 random access OK

drrop.cc 實作：Worker handle Range header + 對應的 206 Partial Content response。

Cache 控制

對 redirect endpoint：

Cache-Control: no-store, no-cache, must-revalidate

避免：

  • 瀏覽器 cache（user 刪了還是看到舊版）
  • CDN cache（你刪了還是 serve cached）
  • 過期狀態不一致

攻擊場景

  • R2 URL 洩漏 → 攻擊者直接拿物件、繞過所有驗證
  • Cache hit 過時資料 → user 已刪內容但仍可被看到

Layer 5：端對端加密（e2e）— drrop.cc 沒做的部分

為什麼 e2e 是隱私 gold standard

前面 4 層保護「服務不洩漏給第三方」。但服務自己仍能看內容 — server 上的 R2 物件、D1 row、log 都對服務 admin 可見。

真正的「服務看不到」 = 端對端加密（e2e）：

  • 內容在 user 裝置加密（用 user 持有的 key）
  • 加密後傳到服務
  • 接收者在自己裝置解密（用同一個 key 或對稱配對 key）
  • 服務從頭到尾只看到 cipher text

為什麼 drrop.cc 不做 e2e

技術上做得到，但有 trade-off：

1. UX 變複雜

  • 上傳前要產 key、user 要管理
  • 分享 key 給朋友的管道安全嗎（key 也要 e2e 嗎？）
  • 忘了 key 沒法救（沒法 reset password）

2. 中央 abuse 處理變難

  • 服務看不到內容 → CSAM、NCII 通報後沒法看到實際內容驗證
  • 法規要求審查 / 通報 → 做不到

3. 預覽 / streaming 變難

  • 影片需要 HTML5 player 即時解密 stream → 性能挑戰

哪些工具有 e2e

  • Signal（messenger）
  • Wormhole.app（檔案傳輸）
  • CryptPad（協作文件）
  • ProtonMail（email）

drrop.cc 沒做 e2e — 我們用 Layer 1-4 + Layer 6-7 補。

Attack 場景（e2e 不能做時）

  • 服務被駭 → 內容外洩
  • 內部威脅（rogue admin） → 內容被看
  • 政府要求調閱 → 服務被迫提供

對「絕對機密」場景，仍應用 e2e tools（Wormhole / Signal）。

Layer 6：Client-side 處理（QR generator 為例）

為什麼 client-side 是隱私 max

Server-side 流程：

你 → POST /generate-qr → server → 算 QR → 回 PNG

過程中 server 看到你的內容（URL / Wi-Fi 密碼 / 任何文字）。

Client-side 流程：

你瀏覽器內 JavaScript：
  - 用 qrcode.js library 算 QR
  - 直接 render SVG / canvas
  - 完全不送 server

Server 從頭到尾不知道你產過什麼 QR。

drrop.cc/qr 是純 client-side — 開頁面後可斷網仍能用。

應用場景

  • QR generator（drrop.cc/qr）
  • 密碼產生器
  • Hash 算 / 加密工具
  • JSON formatter
  • Markdown preview

凡是「處理不需要 server 資源」的場景，都該優先 client-side。

Attack 場景

  • Server 被駭 → client-side 工具的 user 不受影響（server 不存資料）
  • Server 收到傳票 → 不知道 user 產過什麼 → 沒得交

詳見 為什麼自己生 QR 比第三方安全。

Layer 7：法規與合規（GDPR / CCPA / 個資法）

主要法規

法規地區重點
GDPR歐盟user 有 access / delete / portability 權利、必須有合法基礎處理個資
CCPA加州類似 GDPR，企業必須 opt-out
PDPA（個資法）台灣較寬鬆但仍要求合法收集、目的限制
APPI日本跨國資料傳輸限制

合規對「匿名服務」的意義

如果服務真不存 user PII（個人可識別資訊），這些法規負擔大幅降低：

  • 不需要 user 同意（沒 PII 處理）
  • 不需要 data export / delete 流程（沒資料可以 export）
  • 不需要詳細 privacy policy（用 layer 1-6 證明就好）

drrop.cc 的策略：最小化收集 = 最大化合規。

合規不等於隱私

法規是最低標準，不是上限。

譬如 GDPR 允許「有合法基礎收集 IP + cookie」 → 多數網站合法地大量追蹤 user。真隱私 = 主動少收，不只是「合法收」。

drrop.cc 走「主動少收」路線 — 即便法規允許存 IP，我們選擇 hash 後存。

串連 7 層的攻擊面總結

Layer主要威脅防禦
1 HTTPS中間人攔截、ISP 監控TLS 1.3 + HSTS
2 IP / Referrer服務 log 洩漏 userHash IP + no-referrer
3 密碼 / TokenDB 被駭密碼外洩PBKDF2 + 一次性 token
4 後端隔離直接拿物件繞過驗證Worker proxy + 不公開 URL
5 e2e 加密服務自己被駭端對端加密（drrop.cc 沒做）
6 Client-side服務 log 知道你做了什麼純瀏覽器處理
7 合規跨境資料移轉、政府調閱最小化收集

drrop.cc 覆蓋 Layer 1-4 + Layer 6-7。Layer 5 沒做 — 對「絕對機密」場景用 Wormhole / Signal 補。

怎麼選一個「真隱私」的工具

5 個自問：

① 它有強制 HTTPS 嗎？

  • 開 http://service.com → 是否 301 → https://
  • 有 HSTS preload 嗎

② 它存 IP 嗎？

  • TOS / Privacy Policy 明寫
  • 沒明寫 → 大概有存
  • 明寫「hashed」「不存」 → 比較可信

③ 密碼怎麼 hash？

  • TOS 寫 PBKDF2 / bcrypt / Argon2 → OK
  • 寫「加密儲存」（vague） → 警戒
  • 不寫 → 警戒

④ 是 client-side 還 server-side？

  • DevTools Network tab 看 POST → 知道答案
  • Client-side 永遠優於 server-side

⑤ 服務商業模式可持續嗎？

  • 廣告變現、付費訂閱 → 可持續
  • 純 VC 燒錢 → 服務可能消失 + 倒前可能賣資料

FAQ

Q：drrop.cc 真的不存 IP 嗎？ A：我們存 HMAC-SHA256(IP + secret_salt) — 雜湊不可反推到原始 IP。可被同一 user 多次訪問做 rate limit，但沒法回推 user 身份。

Q：drrop.cc 為什麼不做 e2e？ A：trade-off 太大（UX 複雜、合規處理變難、預覽功能難）。對「絕對機密」場景建議搭配 e2e 工具（Wormhole 等）。

Q：使用 Tor browser 訪問 drrop.cc 會更隱私嗎？ A：會。Tor 加一層 IP 混淆（drrop.cc 看到的是 Tor exit node IP，不是你真實 IP）。但 Tor 慢、影片串流可能卡。

Q：政府能要求 drrop.cc 提供 user 資料嗎？ A：合法強制力下我們會 comply。但我們沒存原始 IP / user identity — 能提供的只有 short codes + 時間戳 + 國家碼 + access pattern。對追溯特定 user 不夠用。

Q：「匿名」跟「隱私」差別？ A：

  • 匿名：服務不知你是誰（identity-level）
  • 隱私：服務知道但不洩漏 / 不濫用（access-control level）

drrop.cc 走「不知道 = 不能洩漏」路線。

結語

匿名分享不是 binary（有 / 沒有），是層層 trade-off：

  • 越強的隱私 → UX 越複雜
  • 越強的隱私 → 服務功能越受限（譬如不能做精準統計）
  • 越強的隱私 → 合規處理越困難（譬如不能審查 abuse）

drrop.cc 在這個 spectrum 上選了「主動少收 + 純 Layer 1-4 + Layer 6 + 最小合規」 — 不是 absolute privacy，但比絕大多數工具實際得多。

→ 試試 drrop.cc 的隱私導向工具堆疊：drrop.cc