匿名網路社群 anoni.net/Docs

從零打造 Android 上的 Tor VPN，Beta 一年下來學到的事

anoni.net 社群 — Fri, 11 Sep 2026 00:00:00 +0000

從零打造 Android 上的 Tor VPN，Beta 一年下來學到的事¶

以下內容整理翻譯自以下文章，主詞角色為 Tor Project：

Tor VPN Beta: What we've learned building our own VPN for Android from scratch | September 9, 2026，作者 pavel

Tor Browser¹ 多年來是保護隱私與繞過審查最有效的工具之一，而現在多數人上網的入口是各自慣用的 app，不是瀏覽器。把同一套保護延伸到通訊軟體、社群與電子郵件，是 Tor Project 的使用者研究裡反覆出現的要求，使用者想要一個簡單的方式保護整台裝置。Tor VPN 的構想在 2021 年因此成形，第一個平台選 Android，那裡的需求最強烈，也最能觸及受審查地區的使用者。

Tor VPN Beta 作為第一個版本推出時就預期要從真實使用中學習，去年秋天限量發布之後，最主要的使用情境很快清楚起來，使用者要的是解除封鎖。發布至今的開發與支援優先順序因此跟著調整，產品往後的方向也一樣。

app 隔離的設計來自 Tor Browser¶

Tor VPN Beta 底下的模型與商業 VPN 根本不同。裝置上每個 app 各自取得一條自己的 Tor circuit（連線路徑）²，共用同一條通道的做法沒有採用，一個 app 的活動因此不容易被關聯到另一個 app。這種 app 隔離大量參考了 Tor Browser 的跨站追蹤防護，預設就在降低跨 app 的關聯，對行動裝置來說是裝置層網路保護的第一步。

app 層級的控制隨版本演進做得更好用。Apps 畫面現在可以搜尋，要找某一個特定的 app 並決定它是否走 Tor，速度快得多。

出口選擇造成的誤用改變了設計¶

出口選擇是一般人熟悉的 VPN 功能，對想繞過審查的使用者來說不見得是對的做法。官方把這件事列為開發階段的可用性測試與早期回饋帶來的最重要一課。

最初的方向是讓使用者對出口選擇有更多控制權，設計在紙上看起來很合理，做出來卻造成混淆。想繞過封鎖的使用者去調了出口位置，他們需要的功能是橋接（bridges）³。Tor 的運作方式與使用者以為的運作方式之間有落差，目前的設計因此要求先把 app 連上 Tor 網路，之後才能選出口。出口選擇仍在官方的後續規劃裡，前提是引入的方式不會在高風險情境下誘發操作錯誤。

使用者集中在高度審查的地區¶

早期的採用集中在高度審查地區，包含伊朗與土庫曼。Tor Browser for Android 的使用者分布偏向全球北方，Tor VPN Beta 這邊看到的是全球南方使用者更深的投入，網路限制對他們是每天要面對的現實。

規避能力的改善力度因此加倍。一個例子是在早期版本之一（1.4.0 beta）優先加入 WebTunnel⁴ 橋接，它讓 Tor 流量看起來像一般的加密網頁流量，審查方要偵測並封鎖連線因此變得更難。橋接支援整體也修掉幾個錯誤、做了幾項體驗改善，目標是讓橋接用起來更可靠。

穩定性、可重現建置與 F-Droid¶

早期發布之後，相當大一部分的工作投入在提升穩定性。Tor VPN 建立在 Arti 這個以 Rust 撰寫的下一代 Tor 實作之上⁵，底層換成新的、扎實的技術基礎，舊架構上繼續打補丁的路沒有走。立即可見的好處是可靠性提升，崩潰次數減少，對各種網路狀況的處理也更好。

另外投入的兩項是把建置做成可重現⁶，以及把 app 送上 F-Droid⁷。可重現建置讓任何人都能驗證手上執行的二進位檔與公開的原始碼相符，F-Droid 讓使用者不必依賴 Google Play 就能安裝與更新，對一個以隱私與安全為重的工具來說，兩件事都重要。

速度上，Tor VPN Beta 的行為不像為速度最佳化的商業 VPN，而 Tor 網路的效能這幾年確實提升了，這些改善也在持續帶進行動端的體驗。C 語言版 Tor 上的部分效能功能，例如壅塞控制（congestion control）⁸，在 Arti 還沒有，把這些能力移植過去是接下來的工作之一。

Tor VPN 的 UX 團隊負責人與產品經理 Duncan 在文中補充，專案很快就被使用者的真實用法推著走，尤其是需要可靠且涵蓋整台裝置的規避能力的那些人。團隊因此把力氣放在替行動端的 Tor 打好基礎，做成以 Arti 與 Onionmasq⁹ 為核心的模組化 Tor 堆疊，能隨真實使用一起演進。這些元件現在可以被多個應用程式重複使用，生態系的碎片化與長期維護風險都因此降低。官方也寫明工作還沒結束，Tor Browser 目前仍然是這件事能做到什麼程度的標準，讓 Tor VPN 隨時間逼近那個水準是團隊目標的一部分。

接下來的方向¶

Tor VPN Beta 是橫跨數年的協作成果。官方在文中感謝 The Guardian Project¹⁰ 的指引與關鍵的低階行動端函式庫，也感謝 LEAP Encryption Access Project¹¹ 的高品質工作，少了任何一方這個 app 都不會問世。開發持續在公開狀態下進行，由使用者的真實用法塑形。

具體的方向有三個，改善受限環境下的規避能力，把更多效能功能帶進 Arti，以及調整使用者體驗來減少混淆與風險。想參與開發方向的人可以到改版過的下載頁面，除了下載 APK 或從 Google Play 商店安裝，現在也能透過 F-Droid 取得 Tor VPN Beta。

台灣脈絡下值得關注的地方¶

用途的落差要先說明：Tor VPN Beta 最主要的用途是解除封鎖，台灣的處境與伊朗、土庫曼差距很大，主流服務都不封鎖，Tor 直連也可用。DNS 層另有 TWNIC 依主管機關命令執行的 RPZ 停止解析機制，2025 上半年逾五萬個網域被列入屏蔽，多數走緊急請求、未經事前司法審查¹³，那是治理透明度的問題，日常上網遇不到廣泛封鎖，各地情況的對照見出差與研討會的數位準備。在台灣用得上的是它裝置層的 app 隔離，每個 app 各走一條 circuit，降低跨 app 被關聯的機會。要去有封鎖的地區之前先裝好、先熟悉操作。

橋接與出口選擇的混淆同樣會發生在這裡：可用性測試裡出現的誤用，是被封鎖的人去調出口位置。本地推廣或帶工作坊時，這一組概念的先後順序要先交代，連不上要處理的是橋接，出口位置解決的是另一件事。橋接類型的說明見 Snowflake 與橋接。

Beta 的警語仍然有效：官方支援文件到現在還標著可能洩漏資訊、不應用於任何敏感用途¹⁴。對記者、人權工作者這類高風險使用者，現階段它適合測試與熟悉，真正高敏感的任務仍用 Tor Browser 或 Tails¹²。安全稽核的結果見 Cure53 完成 Tor VPN 安全稽核，工具之間的取捨比較見 VPN 選擇指南。

參考資料

原文全文：Tor VPN Beta: What we've learned building our own VPN for Android from scratch，Tor Project 官方部落格，2026 年 9 月 9 日
圖片來源：Tor Project 官方論壇的同一篇討論串，本篇引用論壇上的原始尺寸檔案

Tor Browser 是 Tor Project 維護的瀏覽器，以 Firefox ESR 為基礎，連線經由 Tor 網路送出，並內建跨站追蹤隔離與瀏覽器指紋一致化。站內介紹見什麼是 Tor，官方下載頁見 Download Tor Browser - Tor Project。查證日 2026-09-11。 ↩
Tor circuit（連線路徑）是流量在 Tor 網路裡經過的一組中繼，通常由入口、中間與出口三個節點組成，每一段各自加密。單一節點只知道相鄰的前後一段，沒有任何一個節點同時掌握來源與目的地。站內說明見什麼是 Tor。 ↩
橋接（bridge）是沒有公開列在 Tor 目錄裡的入口中繼。公開的入口 IP 被封鎖時，改用橋接仍然連得上 Tor 網路，取得方式與可用類型見橋接 - Tor Project 官方支援文件。查證日 2026-09-11。 ↩
WebTunnel 是一種可插拔傳輸（pluggable transport），把 Tor 流量包進 HTTPS 連線裡，在網路上看起來像連往一般網站，適合用在會針對 Tor 特徵過濾的網路。站內的架設教學見如何搭建 Tor WebTunnel 橋接，設計說明見 Hiding in plain sight: Introducing WebTunnel - Tor Project 部落格，2024 年 3 月 12 日。查證日 2026-09-11。 ↩
Arti 是 Tor Project 以 Rust 從頭撰寫的 Tor 實作，用來接手 C 語言版 tor 的角色。它以函式庫為主要形式，方便被其他軟體嵌進去使用，Tor VPN 的底層就是它。站內的版本紀錄見 Arti 更新紀錄，原始碼見 arti - Tor Project GitLab。查證日 2026-09-11。 ↩
可重現建置（reproducible builds）指同一份原始碼在不同機器、不同時間建置，都產生位元完全相同的成品。任何人因此可以自行建置一次，比對雜湊值，確認手上的執行檔確實來自公開的那份原始碼。說明見 Reproducible Builds - Reproducible Builds 專案。查證日 2026-09-11。 ↩
F-Droid 是 Android 上的自由軟體 app 商店，收錄的 app 由 F-Droid 自行從原始碼建置，安裝與更新都不需要 Google 帳號。Tor VPN Beta 的頁面見 Tor VPN Beta on F-Droid - F-Droid。查證日 2026-09-11。 ↩
壅塞控制（congestion control）是 Tor 0.4.7 引入的流量控制機制，讓連線依實際網路狀況調整送出速率，降低排隊造成的延遲。說明見 Congestion Control Arrives in Tor 0.4.7-stable! - Tor Project 部落格，2022 年 5 月 4 日。查證日 2026-09-11。 ↩
Onionmasq 是以 Rust 撰寫的隧道介面，攔截裝置或個別 app 的 TCP、UDP 與 DNS 流量並改由 Tor 送出，Tor VPN 的網路層就是它。站內介紹見 OnionMasq 的流量隔離實驗，原始碼見 onionmasq - Tor Project GitLab。查證日 2026-09-11。 ↩
The Guardian Project 是專做行動裝置隱私工具的組織，Orbot 與 Android 上多個低階網路函式庫都出自他們，與 Tor Project 長期合作。組織介紹見 Guardian Project。查證日 2026-09-11。 ↩
LEAP Encryption Access Project 是開發加密通訊工具的自由軟體團隊，主要產品是 LEAP VPN，一套針對受審查環境設計的開源白標 VPN，RiseupVPN 與 Bitmask 共用它的程式基礎。組織介紹見 LEAP。查證日 2026-09-11。 ↩
Tails 是從 USB 隨身碟開機的作業系統，所有對外連線經由 Tor，關機後不在電腦上留下痕跡。站內介紹見什麼是 Tails，官方網站見 Tails。查證日 2026-09-11。 ↩
TWNIC 依主管機關命令對網域執行 DNS 層的停止解析，透明度報告見 RPZ 惡意網域名稱攔截服務 - TWNIC，數字以該站當期公布為準。2025 上半年逾五萬個網域被指定、多數未經事前司法審查的統計出自 Taiwan: Freedom on the Net 2025 - Freedom House，該報告的來源是 TWNIC 的首份 RPZ 透明度報告。查證日 2026-09-11。 ↩
Beta 警語的出處。About Tor VPN - Tor Project 官方支援文件。查證日 2026-09-11。 ↩

把整個文件站與小工具存進裝置，沒有網路的時候照樣可以開啟

anoni.net 社群 — Tue, 08 Sep 2026 00:00:00 +0000

把整個文件站與小工具存進裝置，沒有網路的時候照樣可以開啟¶

網路斷掉的時候，你最想打開的那一頁，常常就是打不開的那一頁。飛機上、山區、換了國家還沒買到網卡，都只是不方便。網路被切斷、被限速、被封鎖的地方，同一件事的代價完全不同。

9 月 4 日到 6 日，我們在葡萄牙 Estoril 參加 Global Gathering 2026，除了最後一天的攤位，也在 Circle 的討論裡分享文件站上的隱私保護內容怎麼寫、怎麼分層。談的過程反覆回到同一個前提，讀者真正需要打開這些內容的時候，網路不一定在。

在 Global Gathering 收到的回饋¶

現場的回應幾乎都是正面的。戰爭、政府干預、網路資源分配不均，三種原因不同的處境指向同一個結果，需要查一份資料的時候，那份資料在網路的另一端而你過不去。

離線閱讀在 8 月底的文件站新增八個小工具那篇已經寫過一段，當時我們把它當成給旅行者的方便功能。會場收到的回饋讓我們把它提到主線，接下來補上的東西都圍繞著它。

以下先用文字說明讀者實際上會看到什麼。後半段是技術的部分，跳過不看也不影響使用。

逐頁閱讀的時候就在背景存下來¶

用一般瀏覽器打開文件站，第一次只存下離線閱讀頁與它需要的樣式，約 1 MB，用意是沒有網路時至少有一個落腳的頁面。

在首頁選過閱讀語言，或在同一個語言裡翻到第二頁之後，該語言的核心章節才會在背景存進裝置，約 12 MB 的文字，涵蓋概念、工具、進階、在地四個章節，加上斷網現場會用到的四個小工具，正體中文版目前是 48 頁。多等一步是刻意的，只看一頁就離開的人不必先付 12 MB 的行動網路流量。

切換語言時才會下載該語言的章節，所以裝置上只會有讀者實際讀過的語言。之後瀏覽過的頁面同樣會被存下來，由離線閱讀頁上的開關控制。

記者、行動者、LGBTQ、家暴幾類場景頁不在預先下載的範圍內，只有讀者自己點開過才會留下。場景頁留在裝置上本身可能就是一個敏感訊號，留與不留由讀者決定。

登機前按一次，整個站帶著走¶

離線閱讀頁上的「全部存到裝置」會把當下語言的所有頁面存進裝置，正體中文版在截圖當下是 232 頁，飛機上、火車上、跨境移動的路上都可以繼續讀。

按鈕存進來的內容不受網站換版影響，網站自動存的那批則會在換版時清掉重新下載。一次只處理當下所在的語言，三個語言都要帶著走的話，切到每個語言的離線閱讀頁各按一次。

自動存的章節預設只存文字，離線開啟時會缺圖。頁面上有一個選項可以連同核心章節的內文圖一起存，大約多 7 MB，預設關著是因為多數人在行動網路上。讀者自己勾選的頁面不受該選項影響，一律連內文圖一起存入。

只想帶走某幾章的話，展開章節逐頁勾選，再按下「套用變更」。從你的身分開始那一頁另有一鍵按鈕，把該路徑連到的頁面一次存進來。

過海關前按一次，全部清掉¶

同一頁上的「清除所有離線內容」會把網站自動存下的與讀者自己勾選的一起清除，並且把自動存下內容的開關關掉，所以清完之後讀過的頁面也不會再留在裝置上。要恢復，回到同一頁把開關打開。

清除按鈕的存在理由跟「全部存到裝置」一樣具體。裝置可能被檢查的時候，一份完整的匿名與隱私指引留在裝置上本身就是要解釋的東西。

離線閱讀頁本身與它需要的樣式不受開關管，下次連上網時會補回，約 1 MB。想清掉裝置上的東西、或想確認還有哪些內容可讀的時候，往往正好是沒有連線的時候，少了落腳頁就只剩瀏覽器的錯誤畫面。

小工具不需要安裝，有瀏覽器就可以使用¶

小工具區目前有 14 個工具，涵蓋威脅模型清單、密語與密碼產生器、本機檔案加密、passkey 鑰匙、我的準備清單、QR code 的產生與讀取與影格串流、檔案雜湊比對、檔案 metadata 清除器、截圖遮蔽、網址清理器、隱形字元偵測，以及列出瀏覽器透露什麼的示範頁。

工具的程式與資料會跟頁面一起存下來，存進裝置之後沒有網路也可以使用。QR code 產生器、讀取器、影格串流與密語產生器四頁跟核心章節一起自動存進裝置，理由是它們在斷網現場會用到。其餘幾頁在離線閱讀的清單裡勾選，之後沒有網路也可以開啟。

沒有安裝步驟這件事，解掉的是幾個平常很難繞過的限制。借來的電腦、公用機器、由組織管控而不允許裝軟體的裝置，都不必先去申請權限。Windows、macOS、Linux、Android、iOS 有瀏覽器就一樣。裝置上不會多出一個隱私工具的圖示，多出來的圖示本身就是一個訊號。也不會發生手上是三年前的舊版本、而修正過的問題還留著的狀況。

工具斷網之後照常運作，本身就是「沒有偷偷送出資料」的一種證明。想自己確認的話，瀏覽器的開發者工具裡有一個網路分頁，會列出頁面送出的每一個請求，用任何一個工具處理一次資料，看清單有沒有動靜就知道了。

把網站加到主畫面，它就變成一個 App¶

這是瀏覽器早就支援、卻很少人用過的功能。任何網站都可以加到手機的主畫面或電腦的應用程式清單，加完之後它有自己的圖示與視窗，開起來跟一般 app 沒什麼差別，而整個過程不經過任何 app 商店。

對離線閱讀來說，差別在入口。網路斷掉的時候，人不會想「先開瀏覽器，再找書籤，書籤在哪個資料夾」，想的是「那個圖示在哪」。花一分鐘裝好，斷網時就是點一下的事。

Android 的 Chrome、Edge、Firefox：開站之後點瀏覽器選單，選「安裝應用程式」、「安裝」或「加到主畫面」
電腦的 Chrome、Edge：網址列右側會出現一個安裝圖示，或從選單選「安裝 anoni.net Docs」
iPhone、iPad 的 Safari：點下方的「分享」鈕，往下捲，選「加入主畫面」

第一次裝的人容易卡在兩件事上。iPhone 與 iPad 上，App 跟 Safari 各存各的內容，在 Safari 裡存過的頁面不會跟著進 App，要在 App 裡再開啟一次，讓它重新存入一份。Android 上長按圖示，捷徑選單裡有「離線閱讀」，可以直接開到管理頁。

裝好之後不必另外管更新，網站發新版時 App 裡一樣會浮出上面那張提示卡片，移除的方式也跟移除一般 app 一樣。

代價要說在前面。裝成 App 會在裝置上留下一個圖示，跟上一節說的「網頁不留安裝痕跡」正好相反。過境可能被檢查的話就不要安裝，用瀏覽器開啟一樣可以閱讀離線內容，只是斷網時要自己找到書籤。Tor Browser 不提供這個功能，理由跟它不做離線儲存一樣。

以下是技術的部分¶

前面說的是讀者會看到的東西。接下來這幾節說明它怎麼運作，只想把東西存進裝置的話，讀到這裡就夠了。

想留下來的話，後面有三件我們自己出過的錯，一條 CDN 設定讓新發布的內容四小時無法進入讀者的手機、一顆清除按鈕清完之後每讀一頁又自己存回去一頁、一把在 iPhone 上可以建立、卻無法算出金鑰的鑰匙。那三段說的是症狀與後果，看不懂術語不影響閱讀。

離線閱讀由 Service Worker 逐頁存下來¶

Service Worker 是瀏覽器提供的一段背景程式，註冊之後由它接手該網站的每一個請求，決定要向網路請求還是從裝置上的快取回應。文件站用它做兩件事，把頁面存進裝置，以及在沒有網路時從裝置上取回。

程式在 docs/zh-TW/sw.js，目前 1388 行。裝置上的內容分成六堆存，而不是全部倒進同一堆，理由是它們該在不同的時候消失。

網站自動存的內容跟著網站版本走，每次部署都整批清掉重下，不然讀者手上的內容會越來越舊。讀者自己勾選的頁面不能比照辦理，刻意留下來的東西不該因為網站發了新版就不見。瀏覽過程中順手存下的則需要筆數上限，不然圖多的頁面逛幾輪就會把前面兩類擠掉。三種壽命不同，所以分成三處存放。

存放區	存什麼	什麼時候清掉
`PRECACHE`	app shell 與當下語系的核心章節	網站每次換版
`RUNTIME_PAGES`	瀏覽過程中順手存下的頁面，上限 120 頁	超過上限時汰換最舊的
`RUNTIME_ASSETS`	同一批頁面引用的圖與字型，上限 200 個	超過上限時汰換最舊的
`LIBRARY`	讀者自己勾選留下的頁面	只有讀者自己取消勾選或按清除
`LIBRARY_ASSETS`	那些頁面引用的圖與程式	跟著它所屬的頁面
`SETTINGS`	兩個開關的值	按下清除時重設為關閉

LIBRARY_ASSETS 跟 LIBRARY 分開，是為了讓畫面上的「你自己選存的 N 頁」數得準，幾十張圖不會被算成幾十頁。

runtime 那兩個快取只在「自動存下內容」開著的時候寫。原本是無條件寫的，結果是讀者按了「清除所有離線內容」之後，每讀一頁就又被存回裝置一頁。按下清除的人多半是因為裝置可能被檢查，既然表示了不留，就不該再留下。

兩個開關的值存在 Cache Storage 而不是瀏覽器的 localStorage。install 階段的 Service Worker 無法讀取 localStorage，而「讀者清空過離線內容」這件事必須在下一次部署的 install 也記得，否則清完隔天就被自動下載回來，等於沒有清除。

Tor Browser 以及 onion、IPFS 版不註冊 Service Worker，基於隱私考量刻意如此。需要離線備援時用一般瀏覽器在 anoni.net 準備，平時的匿名瀏覽再回到 Tor Browser。

裝置上的舊內容怎麼更新¶

頁面的新鮮度由 network-first 維持。導覽請求一律先向網路要一份，回來就用新的並存起來，逾時或失敗才回快取，再不行才回該語系的離線頁。線上瀏覽因此一直都是最新內容，會變舊的只有裝置上那份離線副本。

逾時設多久是整段最難的一題，而難的原因跟網速無關。瀏覽器提供的 navigator.onLine 只有在回 false 的時候可信，讀者實際卡住的狀態正好都是它回 true 的幾種，飛航模式底下 Wi-Fi 還開著、機上 Wi-Fi 沒有購買方案、公共熱點把流量攔在登入頁。裝置上明明有一份完整的副本，讀者卻要每開啟一頁都等滿逾時。

所以導覽的逾時壓到 1.2 秒，因為逾時之後還有裝置上的舊副本可以提供，讀者取得的是完整內容，只是晚一輪才更新。而且只要有一次導覽等到逾時，接下來一分鐘內有快取就直接給，網路請求照樣在背景發出去，成功了就把狀態清掉，讀者接回網路之後不必自己操作。

資產走的是另一組數字。導覽逾時之後還有東西可以提供，資產逾時之後只能回應失敗，畫面會少一塊，所以放寬到八秒。這個上限是 2026-09-04 才補上的，原本沒有任何上限，連線成功但不回應的網路會讓請求一直掛著，而 stylesheets/extra.css 是 render-blocking 的，它掛住的話整頁就一直是白的，實測四十五秒還沒有任何內容出現。

網站發布新版本時，畫面底部會浮出一條提示，寫著「離線存的內容有新版本。更新會重新載入這一頁。」按下「更新」才會套用。刻意要讀者按一下，是因為套用的動作會重新載入當前頁面，正在讀的位置會消失，那是唯一會讓人意外的地方，所以直接寫在卡片上。沒有按也可以，離線副本維持原樣，直到讀者自己決定。

安裝成 App 之後有一個額外的問題。瀏覽器的 soft update 靠 navigation 觸發，在分頁裡瀏覽經常會碰到，常駐在背景的 PWA 回到前景不產生新的 navigation，換版提示因此不會出現，讀者連一顆更新按鈕都沒有。處理方式是回到前景時主動查詢一次有沒有新版，並加上節流，避免每次切換 app 都送出一個請求。

讀者自己勾選留下的那批不隨著換版清掉，離線閱讀頁上另有一顆「更新已存的內容」，按下去才會逐頁重新抓回。

還有一層跟 HTTP 快取有關。Service Worker 送出去的每一個請求都帶著 cache: "no-cache"。這個名字容易誤會，它的意思是每次都跟伺服器確認一次，內容沒變時伺服器回 304，快取照樣留著，成本是一個往返，並不是跳過快取。沒帶這個選項的 fetch 則會先查裝置上的 HTTP 快取，覺得還沒過期就直接回應，網路請求根本不出門，network-first 於是看起來向網路確認過，實際上確認的是自己手上那一份，舊回應還會被寫回 runtime 快取，讓舊內容更久留在裝置上。

2026-08-28 就發生過一次。Cloudflare 上一條把 HTML 一律設成 max-age=14400 的 Cache Rule，讓新發布的內容有四小時無法進入 PWA。分頁裡的 Safari 讀者不會察覺，從網址列進站或下拉重新整理本來就繞過 HTTP 快取，安裝成 App 之後的冷啟動與站內點連結則不會，加上 iOS 的主畫面 app 有獨立的儲存分區，Safari 那邊取得新內容也無法傳到 App，於是只有 PWA 一直停在舊版。

同一天收成兩層。伺服器的 nginx 對 /docs/ 的頁面與兩份索引送 no-cache，Cloudflare 那條規則改成尊重來源設定讓它傳下來，Cloudflare 的邊緣照樣快取 24 小時，由部署時執行的 cf_purge.py 清掉。Service Worker 這邊照樣自己帶著 no-cache。兩層各自獨立，因為上游的設定會被人改，改的人未必知道 Service Worker 靠它運作，而症狀是讀者無法取得剛發布的內容，在瀏覽器上點來點去難以察覺。

站上的 passkey 沒有帳號也沒有伺服器¶

passkey 是存在裝置或密碼管理器裡的一把鑰匙，用指紋、臉或 PIN 開。它一般用來登入，站上的用法完全不同，沒有登入、沒有帳號、沒有伺服器，我們拿它當讀者資料的鑰匙，站上連讀者有沒有建過一把都不知道。準備清單勾好的進度、威脅模型的答案、常用的聯絡對象，都加密之後存在讀者自己的裝置上。

同一把 passkey 在站上有兩種用法，機制不同，能用的環境也不同。

用法一，資料金鑰放在 passkey 裡¶

建立 passkey 時站上產生一把隨機的資料金鑰，放進憑證的 user.id 欄位，之後每一次驗證，保管 passkey 的地方都會把它原樣交回來。讀者在任何有這把 passkey 的裝置上驗證一次，資料金鑰就回到網頁，網頁用它解開存在裝置裡的密文。

我的準備清單、威脅模型清單的存檔、本機檔案加密裡的收件人簿都放在同一個暫存區，共用一份密文。

用法二，PRF 現場算出金鑰¶

這個用法把 passkey 變成一台只在讀者按指紋時才回答的金鑰計算機，機制是 WebAuthn 的 PRF 擴充。passkey 內部多藏一把秘密，永遠不離開驗證器，網頁每次驗證附一段輸入，讀者同意之後，驗證器回傳固定 32 位元組的輸出，同一把 passkey 配同一段輸入永遠得到同一段輸出。

本機檔案加密拿這段輸出去包 age 的檔案金鑰。沒有 passkey 就無法算出金鑰，資料就是一堆密文。跟「驗證通過才顯示」完全不同，後者是寫在網頁裡的門禁，任何人都能繞過。

為什麼暫存區刻意選了安全性較低的那條路¶

暫存區用 user.id，沒有走 PRF。Apple 的實作不把 PRF 需要的資料交給 iCloud 鑰匙圈以外的保管方式，iPhone 配 Bitwarden 可以建立 passkey，卻無法算出金鑰。user.id 是核心欄位，規格要求所有保管方式都交回來，我們在 iPhone 配 Bitwarden 與電腦的 Chrome 上驗過。

代價寫在頁面上：資料金鑰跟著憑證存在密碼管理器裡，安全等於那個管理器的安全。誰能解鎖密碼管理器，誰就取得金鑰，密碼管理器的匯出檔、共享的 vault、服務端被入侵加上一組弱的主密碼，走的都是同一條路。強度跟裝置的螢幕鎖是同一個等級，對多數人夠用，對能接觸到裝置又可能要求解鎖的對手不夠。威脅模型清單遇到這一級的對手就不提供存檔。

在涵蓋面與安全性上限之間，我們選了涵蓋面。設計時的判準是「方案在 iPhone 配第三方密碼管理器上是否可行」，需要讀者記住一段密語的方案會被否決，讀者要做的只有驗證。

限制¶

passkey 綁在 anoni.net 這個 RP ID 上，瀏覽器只允許在同一個網域使用，鏡像站與 onion 位址無法使用
Tor Browser 整個關閉 WebAuthn，security.webauth.webauthn 在它的預設設定檔裡是 false
passkey 丟了、密碼管理員的帳號沒了，暫存區就無法解開，用它加密的檔案只剩備援金鑰可以解開
瀏覽器基於隱私不讓網頁查詢某個網域有沒有 passkey，所以站上連讀者有沒有建過都不知道，鑰匙頁每次打開都是空的

加密為什麼選 age¶

讀者三年後要解開一份備份的時候，手上可能只剩一台裝了命令列工具的電腦，網站還在不在都不一定。選一個公開格式而不是自訂格式，理由就這一條。

在公開格式裡選 age 而不是 PGP，理由是幾件具體的差異：

	age	OpenPGP
做的事	只加密檔案	加密、簽章、身分與信任網
演算法	固定一組：X25519、ChaCha20-Poly1305、scrypt、HMAC-SHA-256	多種可選，雙方協商
金鑰長什麼樣	一行 62 個字元	一個區塊，上千字元，含身分與期限
設定項	沒有	GnuPG 的設定檔有上百項
規格長度	一頁	上百頁
實作	Go、Rust、TypeScript 三份互通	GnuPG 為主，其餘實作各自覆蓋部分規格

每一列都指向同一件事，沒有選項就沒有設錯的機會，規格短就能在瀏覽器裡實作得小而能審，密語模式不需要任何金鑰管理。1999 年的可用性研究「Why Johnny Can't Encrypt」找了十二個人用 PGP 5.0 寄一封加密信，多數人在九十分鐘內無法完成，還有人把私鑰寄了出去，2018 年的 EFAIL 攻擊利用的則是舊格式的密文可以被改動、郵件軟體對驗證失敗只給警告照樣顯示。兩者的根源相同，選項太多、能設錯的地方太多。

站上的本機檔案加密輸出的就是標準 age 檔，任何裝了 age 命令列工具的電腦都能解開，不需要這個網站：

age -d -o backup.tar backup.tar.age

三種鑰匙模式對應不同處境。密語模式沒有金鑰需要管理，強度完全等於密語的強度。passkey 模式不需要記住任何東西，代價是檔案只能在這個網域解開。公鑰模式加密給別人，收件人一行一個，age1 開頭的 X25519 公鑰與 age1pq1 開頭的後量子混合公鑰都接受。

加密完成後，頁面會用同一組鑰匙把輸出解回來比對，一致才提供下載。加解密用的函式庫原封不動放在站上，一行都沒有改動，所以想驗證的人可以拿它跟上游的版本逐位元組比對。改過就失去這個可對照性，剩下的只有相信我們的說法。

PGP 留在它該在的地方，站上的敏感資料上傳流程用 PGP，因為那裡需要長期的身分、要跟郵件生態相容。分工是郵件與身分用 PGP，檔案與備份用 age。

目前的狀態，以及我們想聽什麼¶

小工具都還是基本的功能元件。每一個各自做好一件小事，彼此之間沒有串起來，也還沒有形成一套可以直接交給組織使用的流程。

整個文件站可以離線閱讀是實驗中的 prototype。核心的機制已經在正式站上運作，預先下載的範圍怎麼劃分、清除要細到什麼程度、安裝成 App 之後的入口該長什麼樣，都還在調整。

我們想把它做成一份完整的產品或服務，需要的是更多對這類功能的想像與回饋：

希望能離線帶著走的頁面：預先下載的範圍目前依核心章節劃分，實際需求可能不同
離線的情境長什麼樣：斷網前有多少時間準備、裝置上留下什麼會造成風險、恢復連線之後要先做什麼
工具在你的情境下缺了什麼：某個欄位沒有被辨識、某種檔案格式無法開啟、說明看不懂都算
passkey 用起來卡在哪裡：建立時選錯保管方式、換裝置之後打不開、看不懂鑰匙頁在說什麼，都歡迎回報

不方便具名的部分可寄到下方的匿名信箱。

聯絡與回報¶

即時討論：Matrix 公開 room（家伺服器 im.anoni.net，連結見社群工具頁）
匿名線索：whisper@anoni.net（GPG 公鑰）
原始碼與 issue：anoni-net/docs

一份英文密語詞表裡的 292 個亞洲外來語，是怎麼選出來的

anoni.net 社群 — Wed, 02 Sep 2026 00:00:00 +0000

一份英文密語詞表裡的 292 個亞洲外來語，是怎麼選出來的¶

我們是一群關心匿名網路與網路自由的志工，從台灣出發，維運文件站。社群做了一份 7776 字的英文密語詞表 asian-diceware，可以直接替換 EFF 的 Large Wordlist，差別在裡面固定收 292 個已經進入英文字典的亞洲外來語，tofu、oolong、boba、kimchi 都在其中。

站上的工具頁已經寫過怎麼用它，小工具區的密語產生器也可以直接按。以下補上另一半，選字的過程，以及過程中擋掉了什麼。

為什麼一份英文詞表需要亞洲味¶

密語（passphrase）的做法是擲骰子從一份固定的詞表抽出幾個英文字，用符號接起來當密碼。強度來自抽字的過程夠隨機，跟抽到哪些字無關。既然強度跟用字無關，換掉詞表的內容有什麼意義？

意義在抄得下來、唸得回去。密語真正被用到的場合是密碼管理器的主密碼、全碟加密的口令、要在電視或遊戲主機上一個字一個字敲進去的 Wi-Fi 密碼，全都需仰賴人腦記住、人手輸入。EFF 那份詞表挑字時避開難拼字、髒話與容易混淆的同音字，理由正在於此¹。

對在台灣、香港與亞洲各地生活的人來說，oolong 比 oolite 好認，ramen 比 ramekin 好記。抽到一個你天天在用的字，抄寫與回想的錯誤率就會下降。換掉詞表內容的理由僅止於此，密語強度一分一毫都沒有變。

詞表要能跟 EFF 那一份直接對換¶

第一條規則先定下來，詞表要剛好 7776 個字，一個不多一個不少。

7776 是 6 的 5 次方，代表擲 5 顆骰子讀成一個五位數，剛好對應到表上唯一一個字。每個字貢獻 log2(7776) ≈ 12.925 bits，六個字約 77.5 bits¹。字數維持在 7776，asian-diceware 就是 EFF Large Wordlist 的直接替代品，任何原本用 EFF 詞表的流程換過來都不必改動，強度也完全一致。

數字固定之後，選字就變成一個名額有限的問題。292 個亞洲外來語占掉 292 個名額，剩下 7484 個名額用最高頻、好拼寫的常見英文字填滿。名額有限是後面每一個取捨的來源。

292 個字的來源分布，跟做的人原本預期的不一樣¶

詞表從台灣出發，直覺會以為華語來源的字最多。實際查完字典之後的分布如下：

來源語言	字數	例字
日語	102	`sushi`、`ramen`、`tofu`、`matcha`、`karaoke`、`tsunami`、`emoji`、`umami`
南亞與梵語	91	`yoga`、`karma`、`guru`、`avatar`、`chai`、`masala`、`bazaar`、`cheetah`
馬來與東南亞	39	`bamboo`、`curry`、`mango`、`durian`、`satay`、`gecko`、`shampoo`、`jungle`
韓語	35	`kimchi`、`bibimbap`、`soju`、`hangul`、`taekwondo`、`mukbang`、`bingsu`
華語	16	`typhoon`、`oolong`、`pinyin`、`boba`、`lychee`、`mahjong`、`qigong`
粵語	8	`wok`、`wonton`、`hoisin`、`kumquat`、`loquat`、`cheongsam`、`longan`
閩南語	1	`ketchup`

日語 102 個，南亞與梵語 91 個，兩者加起來超過總數的六成。華語只有 16 個，閩南語只有 ketchup 一個。

分布記錄的是英語實際吸收了什麼，不記錄我們希望它吸收什麼。日本料理、瑜伽與印度香料進入英語世界的時間長、管道多，累積下來的詞就多。韓語那 35 個字裡有不少是近年才進 OED 的，來自 2021、2024 與 2026 幾批 K-culture 收詞。華語的 16 個字多半年代久遠，typhoon、ginseng、kowtow 都是幾百年前的貿易與外交留下來的。

台灣的味道就藏在那 16 個字裡：oolong（烏龍茶）、boba（珍珠奶茶，源自台灣）、typhoon（颱風）、pinyin（拼音）。加上唯一那個閩南語來源的 ketchup，番茄醬的英文可以一路追回閩南語，字源很多人不知道。

還有一批字大概沒人會猜到是亞洲外來語：tycoon、honcho、shampoo、bungalow、jungle、loot、thug、atoll、gecko、cheetah、gong、dinghy、mongoose。它們每天都有人在用，來歷早就融進英語裡了。

選字的兩個限制¶

只收已經進字典、寫成一個單字的詞¶

feng shui、kung fu、dim sum 三個詞在英語世界的知名度都不低，全部沒收。理由是中間有空格。

密語的組成方式是把抽到的字用 - 之類的符號接起來，抽到一個帶空格的詞，整組密語的斷詞就會產生歧義，抄寫、口述與輸入都會出錯。詞表的價值在於抄得下來、唸得回去，一個會讓人抄錯的詞不管多有代表性都不能收。

字典背書也是硬條件，292 個字全部在 OED、Merriam-Webster 或 Cambridge 查證過。硬條件擋掉的是「我覺得這個字英語圈應該懂」的判斷，那種判斷通常是錯的。

不自己音譯華語¶

另一個選項是自行音譯，把常見的華語詞轉寫成英文字母收進詞表，華語來源的比例馬上就能拉高。我們沒有走那條路。

台灣同時流通漢語拼音、威妥瑪與通用拼音幾套系統，香港另有粵語拼音（Jyutping）。同一個音在不同系統下拼法不同，不同的音在同一個系統下又可能拼成相近的樣子。密語詞表最不能出現的就是歧義，一個字有兩種合理拼法，抄下來的人就有一半機率無法開啟自己的磁碟。

音譯本身有價值，只是屬於另一個專案，需要先把拼音標準的選擇處理完，不能夾帶在一份以英語為基底的詞表裡。

為什麼停在 292，不湊到一個整數比例¶

292 個字占 7776 的比例約 3.8%。數字看起來像是隨手取的，實際上是把可用的字都撈完之後剩下的結果。

把 OED、Merriam-Webster 與 Cambridge 查過一輪，台灣、香港與華語圈讀者認得出來的亞洲外來語大約 330 個。其中 292 個收進詞表，另外約 40 個標成備援，可辨識的字幾乎就到頂了。v0.4.0 把 161 個擴充到 292 個，擴充時的原則是好認優先，查得到但沒人認得的字寧可先擱著，也不為了湊成 4% 這種漂亮數字而硬塞²。

想再往上拉，例如拉到 10%（約 778 個字），只有兩條路。第一條是拿冷僻詞充數，puttee、howdah、nilgai、maund 這類字多數人拼不出、唸不準也記不住，一收就破壞了詞表存在的理由。第二條是改用羅馬拼音的官話或注音音節，也就是上一節說過的另一個專案。

工具頁把比例比喻成啤酒的酒精濃度（ABV），一個刻意挑過的數字，不是稀釋出來的意外。比喻在最後一步失效：酒精濃度更高會有差別，亞洲外來語比例更高不會。無論抽到 tofu 還是 the，每個字都是一樣的 12.925 bits，強度只跟詞表恰好 7776 字、每次擲骰機率均勻有關。文化覆蓋跟好用性衝突的時候，好用性優先。

建置流程擋掉的東西¶

詞表由一條可重複執行的流程產出，六個階段依序是收集、正規化、品質過濾、修剪、組裝、驗證²。

高頻英文字的排序來自 wordfreq 的一份留在倉庫裡的快照，只當排序依據用。品質過濾那一關把專有名詞、縮寫與雜訊清掉，它們看起來是英文字，實際上會讓密語變得難輸入或難辨認。

真正麻煩的是修剪那一關，處理的是前綴衝突。密語詞表有一個好性質，任何一個字都不會是另一個字的開頭，於是把幾個字接在一起，不必分隔符號也能唯一還原出原本的組合。要維持該性質，兩個字互為前綴時就得砍掉一個。

問題在於被砍掉的可能正好是釘住的亞洲外來語。流程的規則寫得很明確：

釘住的字受保護，前綴衝突發生在釘住的字與一般字之間時，砍一般字
兩個一般字相撞時，砍頻率較低的那個
兩個釘住的字互相衝突時，建置直接失敗並印出衝突的那一對字，由人去改資料檔決定砍哪一個

第三條是刻意的。自動砍掉一個釘住的字，詞表會悄悄少一個亞洲外來語，沒有人會發現。建置失敗很吵，吵是必要的，少一個字的問題需要有人看到。

最後的驗證有八項驗收測試，另外用外部工具 wla 稽核一次，確認長度是 7776、可唯一解碼、每字熵值 12.925 bits、沒有重複字。驗證通過才會發版。

開源條件與怎麼拿¶

程式採 MIT，詞表資料採 CC-BY-4.0，原始碼與完整詞表都在 GitHub anoni-net/asian-diceware。頻率快照只當排序依據，收進詞表的字本身是常見英文詞彙。

CC-BY-4.0 的意思是你可以直接拿去印、去發、去改，保留出處標註即可。我們把 7776 字詞表排成一本 A5 擲骰查表小冊，含封面、使用教學、QR 與版權頁，PDF 可以直接下載，約 36 頁，用家裡或便利商店的印表機印 A4 對折成冊即可。

做小冊時碰到一個實際問題可以分享。PDF 裡的中文字型必須內嵌，否則換一台電腦開啟就會變成方框，而 macOS 內建的蘋方（PingFang）授權不允許為了再散布而內嵌。所以小冊改用可自由內嵌的開源字型 Noto Sans TC 與 JetBrains Mono，任何人拿去重印都不會遇上授權問題。要讓別人能自由再散布，字型也要一起處理。

社群參加工作坊、小聚與研討會等實體活動時，也會帶幾本印好的小冊到現場發送。在活動裡取得一本、或剛好遇到我們，非常歡迎過來聊聊，問密語、問匿名網路，或只是打聲招呼都可以。想知道我們最近會出現在哪，見活動參與。

為什麼社群要做一份詞表¶

密語詞表看起來離匿名網路有一段距離，關聯在一個還在規劃的專案上。

Tor Project 有一個叫 AnonTicket 的服務，讓人不必提供 email 就能匿名向 Tor 的 GitLab 回報問題，帳號用系統產生的一組隨機英文字代碼辨識身分³。讓記者接收爆料的 SecureDrop 平台也一樣，為每位匿名來源產生一組七個隨機字的登入代碼⁴。代碼要好唸、好抄、不容易混淆，來源正是一份挑過的詞表。

社群接下來想做一個類似 AnonTicket 的匿名服務平台，還在規劃階段。asian-diceware 就是為了當那種服務的代碼字源而準備的，順便先變成一份現在就能用的密語詞表。要在台灣做一個不必留下 email 的匿名回報管道，詞表是其中一塊材料。

實體活動才有的文宣小物 Global Gathering 會場見

anoni.net 社群 — Fri, 28 Aug 2026 00:00:00 +0000

實體活動才有的文宣小物 Global Gathering 會場見¶

9 月 4 日到 6 日，我們在葡萄牙 Estoril 的 Global Gathering 2026 設攤，現場會發一份紙本小報，四張 A4 疊起來對折、外面包一張封套，折好是 A5 大小。只印 150 份，發完為止，而且沒有數位版。

anoni.net 是台灣的志工社群，做匿名網路與網路自由的教材、量測工具與自架服務。

攤位時段：9 月 6 日（日）13:00 到 15:00
位置：6 號攤位
現場可以做的事：拿一份小報、試用八個離線可用的瀏覽器端小工具與三件 Tor 的 3D 互動作品、討論匿名支付
三天我們都在會場，攤位以外的時段遇到可以直接叫住我們

這份小報寫給誰：如果你在做跨境撥款、捐款者匿名，或是被金流管制擋住的專案，裡面有一張是為你準備的。

這篇是設計過程的紀錄，寫給對排版與印刷有興趣的人，包含我們改錯又修回來的地方。想知道參加的原因、攤位為什麼談匿名支付、議程上有哪些相關場次，以及另外五種找到我們的方式，請看匿名網路社群前往 Global Gathering 2026，完整的活動資訊在前一篇。

攤位只有兩個小時¶

攤位排在 9 月 6 日下午，長度兩個小時，由兩個人輪值。

走過去的人願意停下來的時間大約三十秒到兩分鐘，我們沒有辦法在那段時間裡介紹完一個社群，也沒有辦法用口頭把匿名支付的研究說清楚。所以要有東西可以帶走。

第一個決定是印紙本，不出數位版。

一份 PDF 放上網，讀者掃描 QR code、儲存到手機，之後大多不會再打開。紙本會被折進背包，在回程的飛機上再翻一次，攤在桌上壓住別的紙，或者轉手給另一個人。實體活動的兩小時裡，能被帶走的東西比能被掃描的東西更有機會留下來。

網頁可以隨時編輯，昨天寫錯的今天改掉，沒有人會發現。紙本一旦印出來就無法修改，錯字、判斷失誤與過期的數字全都留在上面。寫的時候我們因此放慢很多。

150 份是我們判斷三天發得完的量。

紙本上仍然印了三個 QR code，分別指向文件站、電子報與社群的 Matrix 房間。沒有數位版，範圍限於這份印刷品，內容的來源都在網站上，任何人都查得到。

先量一張紙裝得下多少字¶

開始排版之前我們沒有可靠的判斷依據，只好把成品做出來再回頭量測。

A4 內容區扣掉邊界之後是 186 × 275 mm，也就是 512 平方公分。每一頁的字數落在 574 到 808 之間，換算成密度是 每平方公分 1.1 到 1.6 個英文字。

密度與閱讀距離綁在一起，換一個開本就不適用。行長不受開本影響，可以直接搬過去。

用 pdftotext -layout 把成品的行結構抽出來測，單欄的行長落在 58 到 68 個字元，中位數 63。經典的可讀區間是每行 55 到 75 個字元，我們剛好落在中間偏下。對應的版面參數是單欄寬 89.5 mm、內文 8.3 pt、行高 1.40。

行高的影響比我們預期的大：同樣的字數與字級，行高 1.8 與 1.40 之間差了將近三成的垂直空間。我們一開始把行高放寬是為了好讀，結果每一區都留下大片空白，讀者需要花更多眼球移動才能讀完同樣的內容。我們沒有再以字級當變因做一次對照，所以只能說行高的影響被低估了，不能說它比字級重要。

所有密集的段落都採取「粗體標籤：說明文字」的結構，眼睛每兩三行就有一個著力處。四份印刷品裡最密的一頁有六個並列項目，全部採用同一種寫法，讀起來的負擔反而最小。我們只試過這一種做法，沒有以多留白或項目符號做對照，所以能說它有效，不能說它最有效。

一張紙只裝得下一個主張¶

一張 A4 裝得下大約 800 個英文字。不夠描述一個社群的全部，只夠說明一件事。說不出這張紙的主張是什麼，內容就還沒準備好。

社群介紹：我們是誰、運作哪些基礎設施、在哪些地方只有二手資訊。我們刻意在這張交代了掌握程度的差別，台灣是唯一的第一手，中國與港澳只是追蹤。國際場合最容易被質疑代表性，先自己交代清楚比被問到才承認好。

小工具與互動呈現：八個瀏覽器端的小工具，加上三件關於 Tor 的 3D 互動作品。開頭那句是「離線可用本身就是證明」，一個關掉網路還能運作的工具不會把你的檔案傳到裝置外部，讀者十秒內可以自行驗證。

匿名支付的階段觀察：三張裡唯一帶版號與日期的一張，標示為 v0.1。研究還沒有結論，所以紙上寫的是目前為止的觀察與還答不出來的問題，並且在背面另外安排了徵集案例的區塊。

三張分開，沒有合成一本小冊。有人問社群在做什麼，有人對桌上的工具有反應，有人談到金流，遞出去的應該是對得上當下對話的一張。

封面改了最多次¶

封面是四張紙裡改得最多次的一張。

第一版的標題是「三個國家佔了 Tor 網路的 62%」，配一張標準的世界地圖。數字本身沒有問題，美國、德國、荷蘭合計 62.3%，整個東亞與東南亞合計只有 2.7%。

版面排定之後我們並不滿意。整句話只交代了缺乏什麼，說完就沒有下一句，留給讀者的位置是受害者。我們在國際場合的第一句話，不該停在這裡。

修正只做了一個動作，將投影中心從大西洋移到台灣。

標準世界地圖把台灣擠在最右邊緣，還沒有寫下任何一個字，版面就先把它安排到邊陲。以東經 121 度重新置中之後，資料完全沒有變動，美德荷三塊深色被推到畫面左右兩側。中間剩下一片由句點與冒號組成的淡影，就是我們工作的區域。

然後台灣不見了¶

調整之後第一次產生的版面，台灣不在上面。

在那個尺度下台灣比一個字元格還小，網格化的時候無法落在任何一格的中心點。

我們沒有把網格切得更細。也沒有真的做一版更細的來比對，判斷的理由是切細之後其他地方會變得瑣碎，而且等於迴避了問題。現行的做法是等網格化完成之後，再依中心點座標另外蓋上一個實心方塊，右邊拉一條字元引線標註。

以台灣為中心重畫，油墨全在邊緣，正中央只剩一個手動補上去的方塊。那個空白就是我們要說的事。

為什麼用字元排¶

地圖的每一個字元代表一個網格，字元的濃淡就是該國的 Tor 中繼密度。資料取自社群 3D 地球儀使用的同一份 Onionoo 快照（Tor 官方公布中繼節點狀態的資料服務），只到國家層級的彙總，沒有指紋、暱稱、IP 位址與聯絡資訊。

我們選擇用字元排，沒有輸出一張圖。一頁字元影印不會糊，用終端機可以讀，貼在牆上遠看還認得出形狀，不需要瀏覽器也不需要連線。 小報裡的工具也是同一個性質，關掉網路一樣能用。

排版上遇到的問題都留在產生器的註解裡。

等寬字元不是正方形：字元格大約寬 0.6、高 1.0。第一版把經緯度切得一樣細，結果地圖縱向被拉長將近 2.7 倍，非洲與南美被拉得細長。列數需要依字元長寬比補償。

密度級距不能只看數值：第一版把 10 到 49 這一階給了較重的字元，俄羅斯只有 26 個中繼卻佔一大片陸地，色塊的視覺份量壓過了真正的重點。現行級距讓最高一階剛好只裝美德荷三國。

小島會消失：台灣寬約 1.5 度，在每欄 3 度的網格下無法落在任何一格的中心點。

影印店決定了最後的樣子¶

我們原本想過採用霓虹配黑底的風格，實際評估之後放棄。

滿版深色印不出來：影印店的雷射機印大面積深色會出現條紋，碳粉會蹭到手與旁邊的紙，紙張會捲曲。四張疊著折起來更明顯。

品牌規範裡本來就沒有漸層：社群主色是高飽和的亮藍，轉成印刷用的四色會偏暗偏紫，大面積色塊最明顯。

受眾：現場是數位人權的實務工作者與資助方，我們判斷過度風格化容易被讀成不嚴肅。前兩條是印刷條件、可以事先確認，這一條是對讀者的猜測，要等 9 月現場才知道判斷得準不準。

最後印出來的是終端機的樣子：白底、超大的等寬標題、極細的分隔線、大量留白，全篇只有一條反白帶狀區塊，沒有一處印到紙的邊緣。三個限制各排除掉一部分選項。 剩下的版本可以印出、碳粉不會蹭到手、在影印店重印也不會走樣，霓虹配黑底那一版三項都達不到。

內文選襯線字體、白紙黑字、標上版號與日期，整體讀起來像一份工作稿。調性是刻意的，對應到匿名支付那張紙上寫的「研究階段」。

封套的兩面都是封面，四張紙疊起來對折成 A5 橫式，哪一面朝外都成立。兩張封面刻意配成一對，一面寫我們建了什麼，另一面是從台灣看出去的樣子。三個 QR code 兩面都放，因為朝外的是哪一面不固定。副作用是折在裡面的一面攤開才看到，等於另一張封面是驚喜。

兩面的下半部都是封底，並且旋轉 180 度印刷。旋轉屬於拼版的一部分，印前先把版面按折疊後的順序排好，折起來繞到背面之後才是正的。

每一場實體活動印一次¶

紙本限定刊物是我們在實體活動的固定做法。每一場擺攤或工作坊都會為那一場印一份，內容依當下進行中的工作決定，場次結束就不再版。

內容會過期，而且是刻意的。匿名支付那張標示為 v0.1，等到下一場活動，研究已經往前，印出來的就不會是同一份。目前這一版只在會場的三天發。

現場見¶

不需要預約，也不用準備話題。150 份發完就沒有了，需要的話請早一點過來。攤位以外的時段在會場遇到也可以直接叫住我們，另外五種找到我們的方式列在前一篇。

匿名支付那張的背面有五道我們還答不出來的問題。挑一道回答，對我們的幫助比帶走一份更大。

文件站新增八個小工具，全部在讀者自己的瀏覽器裡執行

anoni.net 社群 — Tue, 25 Aug 2026 00:00:00 +0000

文件站新增八個小工具，全部在讀者自己的瀏覽器裡執行¶

我們是一群關心匿名網路與網路自由的志工，從台灣出發，維運文件站，把個人隱私與匿名的做法依日常、敏感工作與高風險三種情境整理成可以照著操作的指引。

站上的文章說明怎麼保護自己，小工具區放的是可以直接按的東西。八個工具都在讀者的瀏覽器裡完成運算，不送出任何資料，存進裝置之後沒有網路也能使用。

起點是照片的 metadata¶

Metadata 是什麼那篇提到，照片裡帶著拍攝時間、相機型號與 GPS 座標，而上傳照片前先去 EXIF 是任何人現在就能做的低成本防護。

線上的清除工具幾乎都需要先把檔案傳上去，而需要清除 metadata 的人，正是最不該把原始檔交出去的人。密碼產生器、QR code 讀取器與網址清理器都有同樣的矛盾，要用的東西本身就是不該外流的東西。

把運算放回讀者自己的瀏覽器可以解決矛盾，代價是功能受限於瀏覽器能做到的範圍。需要連到外部服務才能運作的功能不會放進來，網路測量請用 OONI Probe，那是專門為量測設計的工具，資料的處理方式也公開。

八個工具看起來各做各的，收進來的判準只有一條：處理的東西本身就不該外流。照片裡的座標、剛產生的主密碼、還沒確認過的 QR code、可能被標記過的文件、答完就顯示你在防誰的清單，沒有一樣有理由交給任何一台伺服器。威脅模型清單與隱形字元偵測離清除 metadata 這個起點比較遠，收進來的理由相同。

八個工具共同的四條規則¶

在你的裝置上運算：所有工具都在瀏覽器中完成計算，不送出任何資料
斷網可用：存進裝置之後沒有網路也能使用，網域被封鎖、連線被切斷或身處沒有訊號的地方都可以開啟
原始碼公開：程式放在 anoni-net/docs 倉庫，具備能力的人可以自行驗證
需要 JavaScript：運算在讀者的裝置上進行，瀏覽器關掉 JavaScript 時整頁不會有反應

想自己確認第一條，最直接的做法是打開瀏覽器開發者工具的網路分頁，用任何一個工具處理一次資料，看有沒有請求送出去。整個過程不到一分鐘，比讀完原始碼快得多。

用 Tor Browser 的話有一個衝突¶

Tor Browser 的安全等級調到 Safest 會關閉 JavaScript，八個工具都無法使用。衝突在於，安全等級那一頁建議在遇到來路不明的釣魚連結與不熟悉的網域時把等級調高，而收到可疑連結正是最需要用隱形字元偵測或 QR code 讀取器檢查一次的時候。

可疑的網站用高安全等級開啟，把要檢查的文字或圖片複製出來之後切回 Standard，檢查完再調回去。工具不連外，在 Standard 等級下開啟不會增加你在可疑網站上的暴露。

開始之前，先答三題¶

威脅模型清單把「要保護什麼、要防誰、願意付出多少」三題答成一份可複製的純文字摘要，並列出建議先讀的頁面。分級與威脅模型如何建立一文完全一樣，資產四類、對手六級、成本三級。

三題各自看都合理，湊在一起未必，清單會把湊不起來的組合標出來。對手選到執法或國家級而成本填最低、要防親密關係的人卻沒把裝置列進要保護的東西、只防隨意路人卻打算大改工作流程，都在標記的範圍裡。

答案只留在該分頁裡，不寫進 localStorage、不寫進 IndexedDB、不寫進 cookie，重新整理就回到空白。「我要防的是親密關係的人」寫在裝置上正好是最不該留的紀錄，而裝置很可能就在對方的接觸範圍內。要保存一份就按複製摘要，貼到自己選的地方。tools/test_threatmodel.mjs 有一項測試守著不落地這件事，避免日後有人為了體驗方便順手加上儲存。

剛加入一個團體、被交代注意資安卻不知道從哪開始的時候，最適合打開清單。換工作、換城市、開始參與新議題，或經歷一次資安事件之後，回頭再答一次。

要交給別人的東西¶

密語與密碼產生器¶

密語與密碼產生器從 asian-diceware 的 7776 字詞表抽密語，或從勾選的字元集抽隨機密碼。兩個模式的亂數都來自 crypto.getRandomValues，取樣時將無法整除的部分捨棄重抽，讓每個字被抽中的機率完全相同。抽六個字的熵約為 77.5 位元，畫面會直接顯示熵值。

懷疑手邊的電腦被人動過的話，切到實體骰子模式。詞表的順序本身就是編碼，第一個字是 11111，最後一個是 66666。擲五顆骰子按下畫面上的數字即可查出一個字，隨機性來自你自己的手，程式只剩查表的工作。按下載完整對照表會取得一份 7776 行的純文字檔，印出來之後不必再開啟工具。

申請密碼管理器要設主密碼、加密磁碟等長期不換的密碼，都適合在此產生。複製之後記得用一段無關的文字覆蓋剪貼簿，手機上的剪貼簿常常跨 App 共用。

QR code 產生器¶

QR code 產生器將很長又容易打錯的字串轉成 QR code，讓眼前的人用相機讀取。活動報名連結、講義的下載網址、臨時的聯絡方式都適用，56 個字元的 onion 網址與一行含 IP 與指紋的 Tor bridge 也在其中，中間不經過任何伺服器，也不留下訊息紀錄。

QR code 裡面是明文，任何拍到圖的人都能讀出內容，包括牆上的攝影機與你身後的人。真正需要保密的內容應該用端對端加密的通訊工具傳送。要印在紙上時將容錯度調到 Q 或 H，紙會摺也會髒。

現場要把一個連結交給眼前的人，而網路不方便使用的時候最適合。帶工作坊把一行 bridge 交給參加者是典型的例子，唸出來兩邊都不確定剛才是大寫 O 還是數字 0，改用 QR code 讓對方掃描，一次就對。

收到來路不明的東西時¶

QR code 讀取器¶

QR code 讀取器在瀏覽器中解出圖片裡的內容，圖片不離開裝置。解出來是網址時會將主機名獨立標出，並且刻意不提供開啟按鈕，確認主機之後再自行貼進瀏覽器。

Wi-Fi 設定、兩步驟驗證綁定、預先寫好的信與簡訊、地理座標、電子名片都能辨識，欄位會拆開來標記，密碼預設遮蔽。掃到 nopass 的 Wi-Fi、含 secret 的 otpauth:、javascript: 開頭的內容都會另外提醒，那幾種按下去的後果與掃到一個普通網址差很多。

停車繳費機上貼著一張看起來沒有異狀的 QR code，或剛認識的人遞來印著 QR code 的名片，都適合先確認內容再決定要不要照做。

隱形字元偵測¶

隱形字元偵測找出文字裡的零寬字元、方向控制、標籤字元與混在拉丁字母裡的同形字，標出位置並說明每一類是什麼。

機構發文件給二十個人、每一份在不同位置插入不同組合的零寬字元，內容看起來完全一樣，外流之後比對即可知道是哪一份。記者取得文件向機構查證時出示原件或複製貼上其中一段，等於把消息來源交給正在找他的人。完整的場景見記者保護消息來源。

不可見字元的另一個用途是把整段指令藏進看起來正常的文件裡。人讀不到，模型讀得到，把一段來路不明的文字貼給 AI 助理之前掃描一次，成本十秒。

偵測結果能證明「有」，不能證明「沒有」，零寬字元是最粗糙的一種標記方式，同義詞替換、段落空白行數、標點微調、PDF 裡的字元間距都不會被偵測到，彩色雷射印表機還會在每張紙上留下編碼序號與時間的黃點陣列。處理真正敏感的文件時，正確的做法是重新打字或轉述內容，不要傳遞原始檔案。

社群的立場是教偵測、不教植入，同一組零寬字元，機構用來保護內部文件是合理需求，用來找出吹哨者就是壓迫工具，所以工具不提供產生帶標記副本的功能，示範文字也固定，無法換成自己的文字。

送出去之前先清一次¶

檔案 metadata 清除器¶

檔案 metadata 清除器移除 EXIF、XMP、IPTC、製作軟體與註解欄位，檔案不離開裝置，清完的是新的一份，原始檔不會被更動。處理範圍是 JPEG、PNG、WebP、GIF、MP4、MOV 與 PDF，遇到認不出來的檔案，畫面上會直接標示，不會安靜地交回一份沒有處理過的東西。

照片與影片的壓縮資料從檔案裡的固定位置一路照抄到檔尾，一個位元都沒有變動，清完的檔案解出來與原檔完全相同。重新編碼的工具做不到無損，每一次重新壓縮都會損失畫質，而且會在輸出裡留下自己的處理痕跡，用 mat2 清過的檔案可以辨識出是 mat2 清的。

EXIF 裡還有一張沒有被裁切過的縮圖。照片裁掉一半再傳出去，縮圖可能仍是原本的完整畫面。畫面上會逐項列出移除與保留的內容，含各自佔幾個位元組，以及檔案格式裡對應的段落代號。

iPhone 預設拍出來的 HEIC 還無法處理，可以在「設定 → 相機 → 格式」選「最相容」，之後拍的就是 JPEG。TIFF、RAW、MKV、WebM、AVI 與 Office 文件目前也不在範圍內。工具不做臉部模糊，畫面裡的門牌、路標、制服與窗外景色都在影像本身，分享之前自行檢視一次。

網址清理器¶

網址清理器挑出網址裡的追蹤參數並移除，每一個都說明是誰在追蹤，同時拆掉 Google 與 Facebook 的轉址包裝。

移除的邏輯是白名單，只處理清單裡能辨識的參數，其餘一律保留。反過來做的話，YouTube 的影片 ID 與分頁參數會一起被刪除，讀者會取得一個無法開啟或指向錯誤內容的網址，而且不會聯想到是清理工具改壞的，只會覺得對方給錯了連結。

從 Facebook 點開文章再複製出來的網址帶著 fbclid，貼進群組之後，每個點進去的人都會帶著同一個 ID 回到 Meta，同一個 ID 將整串點擊記錄串了起來。電子報的 utm_source 轉發出去等於告訴收件人你訂了哪份電子報，mc_eid 更直接，屬於 Mailchimp 的收件人識別碼，對得回電子郵件地址。

短網址刻意不展開，因為展開的動作會把想清理的網址送到第三方伺服器上，正好是工具要避免的事。

想知道自己的瀏覽器透露什麼¶

你的瀏覽器透露了什麼列出任何網站在打開頁面的那一刻就能取得的資訊，沒有問過使用者，也不需要同意。每一項下面標出 Tor Browser 會顯示什麼，例如時區直接寫「Tor Browser 會顯示：UTC」，換一個瀏覽器打開同一頁就可以對照。

最上面的八位短碼是將穩定的值揉在一起算出來的，換裝置或換瀏覽器再開一次，只要比對短碼就知道有沒有變。十五項值加起來足以認出一個人，短碼把整組值濃縮成一個可以直接比對的識別碼。原理見瀏覽器指紋是什麼。

列出的十五項裡，在自己裝置上真正能夠關閉的只有三項，位置權限、語言偏好與 Do Not Track 訊號。其餘沒有開關可以關，因為它們本來就是網頁平台提供給網站的能力。單一動作能處理最多項目的是改用有內建防護的瀏覽器。

工具刻意沒有匯出按鈕，匯出的檔案本身就是一份完整的指紋，留在裝置上比不留更糟。也沒有獨特性百分比，計算獨特性需要一個母體資料庫，社群不打算為此開始收集訪客資料。想看那種統計可以用 EFF 的 Cover Your Tracks。

影片與 PDF 各有一個限制¶

編碼器會把自己的版本寫進壓縮資料本身，與畫面內容混在一起，不屬於描述欄位，要移除只能重新編碼，而重新編碼會損失畫質，也只是把舊編碼器的痕跡換成新的。工具不做重新編碼，改成把掃到的字串列出來，避免使用者誤以為已經清乾淨。

照片與影片可以把描述那一段直接剪掉，PDF 不行。PDF 的每個物件在交叉索引表裡記著自己的位置，剪掉一段之後後面全部位移，整張表要重算，而 1.5 版之後常見的做法還會把好幾個物件壓進同一段壓縮資料，從外面連內容都看不到。所以工具是把整份檔案重寫，無損的保證在 PDF 上不成立。實測頁面內容不會重新排版，渲染出來與原檔逐像素相同，但表單、數位簽章或特殊互動元件重寫之後不一定完全保留，重要的檔案先留一份原始檔。

XMP 另有一個陷阱，把文件目錄裡指向 XMP 的引用刪掉、重新存檔之後，內容仍然完整留在檔案裡，只是沒有人指向它，用文字搜尋工具打開還是找得到作者與地點，所以工具是把物件本身移除，tools/test_stripmeta.mjs 有一項測試專門守著。

整份文件站可以存進裝置¶

用一般瀏覽器開過文件站，第一次只會存下離線閱讀頁與它需要的樣式，約 0.5 MB。在首頁選過閱讀語言，或在同一個語言裡翻到第二頁，該語言的核心章節（概念、工具、進階、在地）才會在背景保存到裝置的快取裡，不需要另外安裝任何東西。多等一步是為了不讓只看一頁就走的人白花 10 MB 的行動網路流量。切換語言時才會下載該語言的章節，所以裝置上只會有實際讀過的語言。

記者、行動者、LGBTQ、家暴等場景頁不在預先下載的範圍內，只有自行點開過才會保存。場景頁留在裝置上本身可能就是敏感訊號，所以是否留存交給讀者決定。要離線帶著走的話，在離線閱讀頁的清單裡自行勾選。

自動保存的章節預設只存文字，離線開啟會缺圖。頁面上有一個選項可以連同核心章節的內文圖一起保存，大約多 7 MB。預設關著是因為多數人在行動網路上，而缺圖仍然讀得懂大部分內容。自行勾選的頁面不受該選項影響，一律連內文圖一起保存。

文件站也可以安裝成離線 App，Android、桌面瀏覽器與 iOS 的逐步操作寫在離線閱讀頁。Tor Browser 以及 onion、IPFS 版基於隱私考量不註冊背景的 Service Worker，需要離線備援時用一般瀏覽器在 anoni.net 安裝，平時的匿名瀏覽再回到 Tor Browser。

用了誰的程式¶

這一區大部分的程式是社群自己寫的。有四樣東西來自別人，原封不動放進來，不做任何修改：

元件	用在	授權
qrcode-generator 1.4.4	QR code 產生器	MIT
jsQR 1.4.0	QR code 讀取器	Apache-2.0
pdf-lib 1.17.1	metadata 清除器的 PDF 部分	MIT
asian-diceware 的 7776 字詞表	密語與密碼產生器	詞表 CC-BY-4.0，程式 MIT

不做修改是刻意的，改過就失去「這是上游那一份」的可審性，讀者要驗的時候只能相信我們的說法。檔案都在 utils/vendor/ 底下，可以自己跟上游的版本比對。共通的理由是元件寫錯不會讓程式停下來，只會產生看起來正常但實際上錯的結果，那比壞掉更難發現。

想一起做的話¶

工具是純前端，沒有建置流程，程式在 anoni-net/docs 的 docs/zh-TW/js/ 底下，一個工具一支 JS。改完要在本機看效果，執行 cd docs && uv sync && mkdocs serve 即可。

八個工具各有一支測試，執行方式是 node tools/test_<名稱>.mjs，不需要安裝任何套件，每一支都在 CI 裡執行。測試守的是畫面看起來正常、結果卻是錯的那幾種情況：取樣有沒有偏差、產生的 QR code 掃回來內容對不對、指紋示範頁有沒有偷偷送出資料、網址清理有沒有誤刪必要參數、威脅模型的答案有沒有被寫進儲存。

目前缺的東西列在各工具頁的不支援清單裡，HEIC、TIFF、RAW、MKV、WebM、AVI 與 Office 文件都還沒有人做。著手之前先開一個 issue 或到 Matrix room 說一聲，避免兩個人做同一件事。流程見 CONTRIBUTING 與如何參與與認領主題。

接下來¶

社群想往的方向是讓文件站成為一份存在讀者自己裝置上的隱私與匿名指引。網域被封鎖、連線被切斷、身處沒有網路的環境，正是最需要開啟文件的時候，能否開啟取決於之前有沒有先保存下來。

幾件現在就可以協助的事：

希望能離線帶著走的頁面：預先下載的範圍目前依核心章節劃分，實際需求可能不同
工具在你的情境下缺了什麼：某個欄位沒有被辨識、某種檔案格式無法開啟、說明看不懂都算
影片或 PDF 的實際案例：手上有無法清除 metadata 的檔案，或清完之後無法開啟的檔案，都歡迎回報

回報管道是 Matrix 公開 room（家伺服器 im.anoni.net，連結見社群工具頁），或 anoni-net/docs 的 issue。不方便具名的部分可寄到 whisper@anoni.net（GPG 公鑰）。

匿名網路社群前往 Global Gathering 2026

anoni.net 社群 — Thu, 20 Aug 2026 00:00:00 +0000

匿名網路社群前往 Global Gathering 2026¶

Team CommUNITY 主辦的 Global Gathering 2026 於 9 月 4 日到 6 日在葡萄牙 Estoril 舉行，我們申請到一個攤位，時段已經排定。

日期時間：9 月 6 日 13:00 到 15:00 WEST（UTC+1，活動期間的葡萄牙當地時間，台灣時間減 7 小時）
位置：6 號攤位，大小 3 x 3 公尺
攤位名稱：anoni.net Hub: Sinophone Asia-Pacific Networked Freedom

活動資訊見 Global Gathering 2026。

Global Gathering 是什麼¶

Global Gathering 是 Team CommUNITY 主辦的年度聚會，參加者來自世界各地，工作範圍涵蓋數位人權、網路自由，以及協助公民社會抵禦數位攻擊。

整場活動沒有主舞台的專題演講，三天的議程由討論圈（Circles）、依地區或主題聚集的 Meetups，以及開放走動的攤位（Booths）組成。村落（Villages）再把這些活動依主題分類，例如規避審查技術、數位安全、區域觀點。

我們參與的原因¶

我們第一次參加 Global Gathering，主要希望認識更多人，包含開發匿名網路與規避審查工具的技術工作者，以及同在亞洲區域的夥伴。

我們是一群關心匿名網路與網路自由的志工，目前從台灣出發，長期投入的工作涵蓋保護記者的消息來源、讓行動者在組織過程中不留下痕跡、讓人在不暴露身分的前提下支持敏感議題。三者共同的基礎都是一個可用的匿名網路。我們維運 Matrix 家伺服器 im.anoni.net 與這個文件站，觀測與討論的紀錄都留在可以查驗的地方。

社群從 2025 年 8 月舉辦的匿名網路工作坊起算，第一批夥伴在那場活動認識。2026 年的工作分成三個方向，個人隱私指引依日常、敏感工作與高風險三種情境整理可操作的做法，校園 Tor relay 與 EFF 和 Tor Project 合作推動，國立台灣師範大學已有實際運作的案例，第三個方向是這次要帶到攤位的匿名支付。

同樣的題目在亞太地區其他地方也有人處理，彼此還不知道對方存在。華語使用者分散在台灣、香港、中國、日本與東南亞各地，遇到的狀況彼此關聯，能夠互相對照經驗的機會很少。

另一個目的是參與區域之間的協作，網路自由的題目很少能靠單一社群完成，能夠觀測與維護的範圍有限，多數需要跨地區協作才能完整處理。先建立聯繫，後續才有共同投入的可能。

8 月 13 日北部行動網路降速的那 30 分鐘，我們用 OONI 公開資料整理成一份資料導覽，當天全台 238 筆連線速度測試來自 47 支裝置，其中一支的下載中位數由 132,096 kbit/s 降到 1,223 kbit/s，文章裡的每個查詢都免驗證免金鑰，讀者可自行重新執行一次。紀錄會一併帶往現場，若有人正在處理斷網或降速，可以提供對照。

攤位上要談匿名支付¶

議程在 8 月下旬公布，三天的場次涵蓋斷網應變、規避審查工具、平台問責、AI 治理與記者安全。把 Circles、Villages 與 Booths 逐項看過之後，沒有任何一場以金流隱私為題。捐款者匿名、跨境撥款、制裁與外匯管制對公民社會的影響，這幾件事沒有出現在任何一個場次的標題或說明裡。有幾場以募款策略與補助申請為題，重點在把錢找進來。款項怎麼在不暴露收款人的前提下送達，議程上沒有著墨。

制裁名單、銀行拒絕往來、捐款紀錄被調閱，是許多組織每天在處理的事，在議程上卻找不到對應的討論。

匿名支付會是攤位上的主要話題，我們還在研究階段，正在收集實際的使用情境，包含誰在什麼處境下需要匿名的金流、現行做法卡在哪一段、法規與合規要求造成哪些限制。

特別想找這幾種人聊：

有跨境撥款經驗的營運者：特別是收款方在高風險或受制裁地區。
處理過捐款者匿名的組織：知道現行工具在哪裡不夠用。
被金流管制擋住的專案：因為銀行拒絕往來或外匯限制而無法收受支持。
在研究或倡議層面關注這個題目的人：包含法規面。

攤位時段歡迎直接走過來，不用預約也不用準備話題，匿名支付以外的題目一樣可以聊。攤位的用意是當一個區域的會面點，讓在場的人彼此找得到。

另一組來自台灣的團隊也在現場¶

Cofacts 也到了 Estoril，攤位是 Booth 10，9 月 6 日 13:00 到 15:00 WEST，與我們同一個時段。他們這次展示 Cofacts.ai，一套建立在多年協作查核社群與聊天機器人之上的多代理（multi-agent）AI 框架。

兩邊關心的事情會在同一個地方交會。公共討論需要可以查證的訊息，也需要一個承載訊息卻不會讓傳遞者曝光的網路。兩個攤位開放同一個下午，歡迎兩邊都來。

議程上與我們相關的討論¶

匿名與規避審查的部分：

技術工作者聚會（Technologist Meetup，9 月 4 日 13:30 到 14:30）是各地投入數位人權與公共利益技術的人互相認識的場合，排在規避審查技術村，我們想找有維護測量工具或自架服務經驗的人。
跨境敘事的裝置檢查與 metadata（Cross-Borders Storytelling: Device Searches, Metadata, and Collective Preparation）比較各地在過境時遭遇裝置檢查與 metadata 審視的經驗，並討論數位、法律、實體與心理層面的準備。華語記者往返不同司法管轄區的頻率高，別人的準備方式我們用得上。
Signal 能否抵抗釣魚（Can Signal Become Phishing-Resistant?）處理針對記者與行動者的釣魚，攻擊者濫用 Signal 帳號救援與裝置連結的正常流程，不需要軟體漏洞。帳號救援的風險要怎麼寫進隱私指引，我們想在這場找答案。
VPN 透明度的問責框架（Lights in the Tunnel: Co-Creating an Accountability Framework for VPN Transparency）著手草擬評估 VPN 透明度與問責的方法論，並選定要評估的業者。社群常被問哪一家 VPN 可信，我們想知道這套方法怎麼變成使用者看得懂的建議。
年齡驗證與數位身分系統（Age Verification and Digital Identity Systems）分成兩場，盤點各國的推行狀況與背後的行動者，並討論公民社會可以推動的減害路徑。

觀測與區域協作的部分：

審查事件的快速應變（Strengthening Rapid Response Efforts to Censorship Events）討論各地在審查事件發生時如何協作應變，並介紹 OONI 用於快速應變的工具與方法。我們長期使用 OONI 公開資料，8 月那份降速觀測即為同一套方法的實作。
亞洲聚會（Asia Meetup，9 月 4 日 12:00 到 13:00）是亞洲區域工作者的連結場合，我們想在這場認識同區域正在處理相近題目的人。
斷網應變計畫服務台（Internet Shutdown Contingency Planning Help Desk）以 BRACE 框架協助組織依自身的威脅模型擬定斷網時的應變計畫。台灣每年有演習情境可以對照，框架能接上哪些部分是我們要釐清的。
數位證據的保存（We See, We Archive, We Remember）以香港、中國、伊朗、巴勒斯坦的檔案工作為基礎，討論公共利益資訊在遭到抹除時如何保存。

會前往交流的攤位¶

The Onion Odyssey Cryptographic Universe 由 Tor Project 與 Guardian Project（Orbot、Onion Browser）共同設置，位於規避審查技術村的 22 號攤位，三天都開放，我們想了解華語使用者在 Orbot 與 Onion Browser 上遇到的門檻。
Lockdown Systems 帶著 OnionShare，透過 Tor 網路匿名分享檔案、架設網站與聊天，另有備份與刪除社群媒體紀錄的 Cyd。消息來源第一次使用時容易卡在哪裡，隱私指引正需要這類細節。
Air Messenger 以 MLS 協定為基礎，結合端對端加密、低 metadata 與聯邦式架構，我們自己維運 Matrix 家伺服器，想知道聯邦式架構能把 metadata 壓到什麼程度。
Amnezia VPN 展示 VPN 封鎖與 DPI 過濾的研究，以及追蹤斷網的 Amnezia Pulse，我們想用 8 月那份降速觀測與他們的斷網判定方法對照。
LEAP 的 MANTA 測量規避通道在受審查環境中的健康程度，我們想了解同一套量測方法是否適用於台灣的連線環境。他們的攤位（Booth 21）只在 9 月 4 日 15:30 到 17:30 開放，同一天 15:00 到 16:00 在規避審查技術村另有一場 MANTA 的討論。
po1ytech 的 polymorphic 是自動鏡像系統，讓遭到封鎖的獨立媒體維持可達，我們想問維持這套系統需要多少人力，志工社群的規模有限，可持續性是選工具時的前提。

完整議程見 Global Gathering 2026，場次數量遠多於此處列出的部分。

將到現場的夥伴¶

我們的攤位排在最後一天，前兩天沒有固定據點，以下幾種方式都可以找到我們。

活動專用的 Matrix room 最可靠，位址是 #gg2026:im.anoni.net，在裡面留言即可約定時間與地點，不需要交換電話號碼，活動期間我們會盡快回覆。任何 Matrix 帳號都能加入，沒有帳號的人申請一個 matrix.org 帳號，幾分鐘就好。房間裡的時間若沒有特別註明，一律指 WEST。im.anoni.net 的帳號由人工開通，需要一到兩天，現場找人來不及等，不需要為了進這個房間去申請。
9 月 4 日有兩場我們會參加的場次，亞洲聚會（12:00 到 13:00 WEST）與技術工作者聚會（13:30 到 14:30 WEST），直接在現場會合即可。
每天 12:00 到 13:00 WEST 的 Networking Hour 我們多半會出現，行程仍有變動，出發前可先在該 room 確認。9 月 4 日的這個小時就是上面那場亞洲聚會，兩者是同一個時段。
三天大多數時間我們都在會場，名牌上會寫 anoni.net 與暱稱，看到請直接打招呼。
9 月 6 日 13:00 到 15:00 WEST 的攤位時段最容易找到人，到攤位時報上暱稱即可。

無法到場的參與方式¶

多數人不會前往葡萄牙，仍然有兩件事可以一起做。

歡迎把你遇到的協作缺口寫下來寄給我們，我們會帶到現場，與其他地區夥伴的紀錄對照。台灣的觀察在國際場合出現的次數不多，具體寫出一個情境，比一段抽象的簡介更有用。

我們也想聽匿名支付的實際經驗，若你或你認識的組織處理過跨境的小額支持、捐款收據與身分揭露之間的取捨、收款人因為金流遭到辨識而承擔風險的情況，這些經驗是現場最需要的素材。不方便具名的部分，可寄到下方的匿名信箱。活動的三天內我們會在幾小時內查看，其餘時間是一到兩天回覆。

活動之外，三個方向都需要更多人參與，個人隱私指引需要有人整理情境與校對，校園 Tor relay 需要有人在自己的學校裡詢問可行性，匿名支付需要更多實際案例。若你比對過 8 月那份降速觀測與原始的 OONI 資料，有想補充或指正的地方也歡迎提出。想認領哪一項，在 Matrix room 提出即可。

歡迎協助傳遞¶

攤位只有一個時段，是否遇到對的人，很大一部分取決於資訊傳得多遠。若你認識可能會到 Estoril 的人，或身邊有記者、開源社群的夥伴在處理相關的題目，歡迎把這篇轉給他們，轉傳不需要事先告知我們。轉出去之後若有人回應，歡迎在 Matrix room 分享，我們可以在出發前先接上。

活動結束之後¶

攤位收集到的內容會整理成一份紀錄，在後續的電子報與這個文件站發布。我們會了解案例發生的情境，涉及的對象與所在區域不會出現在對外的內容裡。協作缺口的清單與匿名支付的案例，兩者都會去識別化之後才呈現。

聯絡方式¶

活動期間聯繫：Matrix room #gg2026:im.anoni.net，供 Global Gathering 三天使用
即時討論：Matrix 公開 room（家伺服器 im.anoni.net）
匿名線索：whisper@anoni.net（GPG 公鑰），活動期間幾小時內查看

Brave 用兩種相反的手法抹平 GPU 指紋

anoni.net 社群 — Wed, 19 Aug 2026 00:00:00 +0000

Brave 用兩種相反的手法抹平 GPU 指紋¶

打開一個網頁，網頁上的 JavaScript 就能取得你的顯示卡型號、驅動資訊，以及硬體支援哪些功能。答案在同一台電腦上幾乎不會變，追蹤公司把它們跟其他裝置特徵組合起來，就是一組不需要 cookie、不需要你同意、跨網站跟著你走的識別碼。

顯示卡是瀏覽器指紋的其中一項來源，字型清單、螢幕尺寸、時區、音訊運算結果同樣算在裡面。整套機制怎麼運作、為什麼清 cookie 沒有作用、各家瀏覽器的預設狀態差在哪，見瀏覽器指紋是什麼，為什麼很難擺脫。本文只處理顯示卡這一塊。

Brave 從 1.93 版起處理這組訊號，桌面版與 Android 版都預設開啟，分批推送¹。做法有三項，WebGL 的廠商與繪圖器字串換成所有 Brave 使用者一致的通用字串、WebGPU 的硬體描述欄位清空、WebGL 支援的擴充清單注入雜訊。

前兩項讓所有使用者看起來一樣，第三項讓同一個使用者在每個網站看起來都不一樣。兩種方向相反的手法出現在同一次更新裡，各自負責不同的 API。分工的界線落在哪裡，也是 Brave 與 Tor Browser 在指紋抗性上分歧的起點。

顯示卡為什麼是一組好用的指紋¶

WebGL 與 WebGPU 讓網站使用硬體加速繪圖，地圖、遊戲、資料視覺化都靠它們。為了讓網站能針對硬體調整繪圖方式，兩組 API 也把底層的硬體細節開放給 JavaScript 查詢。

網站能取得的資訊有三類¹：

廠商與繪圖器字串：透過 WEBGL_debug_renderer_info 擴充提供的 UNMASKED_VENDOR_WEBGL 與 UNMASKED_RENDERER_WEBGL 兩個參數⁴，網站會取得類似 ANGLE (Apple, ANGLE Metal Renderer: Apple M5 Max) 的字串，精確到晶片型號。除錯用的擴充最早是 Chrome 為了 Google Maps 開放，後來變成所有網站都能呼叫。
支援的擴充清單：同一個 WebGL context 會回報它支援的完整擴充清單，內容隨 GPU 與驅動而異，追蹤者把整份清單 hash 成一組精簡的識別碼。
WebGPU 的硬體描述：較新的 WebGPU API 會回傳 adapter 的 vendor、architecture 與 device 欄位，例如 {vendor: 'apple', architecture: 'metal-3'}。

顯示卡不會天天更換，所以這些值長期穩定，比 cookie 更難清除。使用者換帳號、開無痕視窗、清空瀏覽紀錄，API 回報的硬體特徵仍是同一組。

Brave 執行了一次小規模的網路爬取，分析每次呼叫前的呼叫堆疊（stack trace），觀察排行前段的網站怎麼使用這些 API，結論是多數網站呼叫它們的唯一用途就是瀏覽器指紋識別¹。爬取規模與比例沒有寫在公告裡。

一致化與隨機化，各自處理哪一種資料¶

訊號	Brave 的處理	手法性質
WebGL 廠商與繪圖器字串	換成單一通用字串，所有 Brave 使用者取得相同的值	一致化
WebGPU 的 adapter 描述	清空 `vendor`、`architecture`、`device`	一致化
WebGL 擴充清單	注入雜訊，每個 session、每個網站（eTLD+1）、每個儲存區看到的值都不同	隨機化

第三項沿用 Brave 既有的 farbling 機制，2020 年的更新裡寫下的定義是「對半識別性的瀏覽器功能輸出做輕微隨機化，讓網站難以偵測，又不破壞良性、以使用者為本的網站」²。

farbling 的種子怎麼運作¶

farbling 的行為由種子的產生方式決定，瀏覽器啟動時產生一組隨機的 session token，與造訪的每個第一方頂層框架網域經 HMAC256 混合，得出每個網域一組、壽命與 session 相同的 token²。同一個網站在同一個 session 內重複量測會取得完全相同的值，換一個網站取得不同的值，下一個 session 再全部換過。第三方 frame 與 script 沿用頂層 eTLD+1 的種子²，嵌入第三方內容不會成為繞道。

指紋器會把大量半識別特徵 hash 成單一識別碼，只要其中一項被隨機化，整組 hash 就被汙染。技術源頭是 PriVaricator（Nikiforakis 等人，WWW 2015）與 FPRandom（Laperdrix 等人，ESSoS 2017）兩項研究²。

為什麼不全部一致化¶

擴充清單為什麼走隨機化，公告裡沒有寫。從 API 的用途推測，改動兩種資料對網站功能的衝擊差距很大。

廠商與繪圖器字串主要用於效能調校與硬體黑名單。網站取得的字串不在既有清單裡，最壞的結果是走一般繪圖路徑。把值收斂成一個常數，該欄位對指紋的貢獻直接歸零，代價有限。

擴充清單用於功能協商。網站會依照清單裡有沒有某個擴充，決定要不要啟用某條繪圖路徑，或改走哪一種後備方案。給一份與硬體實況不符的統一清單，網站可能選到硬體無法支援的路徑，也可能放棄本來可用的加速。可行的做法只剩在保留可用性的前提下加入雜訊，讓 hash 出來的值不穩定。

兩種手法的防護目標也不同，一致化降低的是熵（entropy），讓某一項特徵失去區辨力，理想狀態是全世界的 Brave 使用者在該欄位完全相同。注入雜訊破壞的是可連結性（linkability），值仍然帶有資訊，但每站每次都不一樣，追蹤者無法把兩個網站上的你接成同一個人。

Tor Browser 把一致化做到底¶

Pierre Laperdrix 2019 年替 Tor Project 寫的指紋介紹文章，開宗明義寫著「所有 Tor 使用者應該有完全相同的指紋」。當時的具體做法包含在所有平台回報同一組作業系統資訊、統一時區與螢幕解析度，以及 letterboxing 在內容周圍加上灰邊，把可視區域對齊到固定尺寸，避免最大化視窗洩漏螢幕大小³。

Laperdrix 也點出隨機化的風險，引用 Eckersley 提出的「可指紋化的隱私增強技術悖論」（Paradox of Fingerprintable Privacy Enhancing Technologies）。舉的例子是某個擴充套件改掉一批數值，卻漏改 navigator.platform，於是造出一組現實中不存在的特徵組合，使用者反而更容易被辨認出來³。隨機化要做對，覆蓋範圍必須夠完整，Brave 持續擴充 farbling 的端點清單也是同一個原因。

Firefox 系的處理方式又是另一種。privacy.resistFingerprinting 開啟時，WEBGL_debug_renderer_info 這個擴充直接停用，網站呼叫不到⁴。該開關預設關閉，需要使用者自行到 about:config 開啟，各家瀏覽器預設做到哪裡的完整對照見瀏覽器指紋是什麼，為什麼很難擺脫。停用與回傳通用值各有代價，停用之後網站取不到值，需要自行處理空值的情況，回傳通用值則讓網站收到的資料與真實硬體無異，照常運作。Brave 選後者，一貫把功能損壞的風險壓到最低。公告裡另一項主張是防護要預設開啟，不藏在特殊模式或旗標後面¹。

界線在 Brave 的文件裡也寫得清楚。2020 年說明 farbling 的更新裡有一句建議，需要對抗定向攻擊的使用者應該改用 Tor Browser²。隨機化擋得住被廣泛部署的商業追蹤，不提供匿名集（anonymity set）。

台灣讀者可以怎麼用¶

日常瀏覽的層面，預設開啟是這次更新最實際的價值。多數人不會為了隱私去改 about:config、切換特殊模式或安裝擴充套件，公告裡也寫了擴充套件本身帶有安全與隱私問題¹。防護在安裝完就生效，門檻接近零。

需要匿名的情境仍然要用 Tor Browser。Brave 的隨機化只處理跨站串接，IP 位址仍然直接暴露給網站，網路路徑上的觀察者也看得到你連了哪裡。記者、行動者、處理敏感題材的工作者，威脅模型不同，工具選擇也跟著不同，可以回頭看威脅模型如何建立。

Tor 的可達性因地而異。中國大陸重度封鎖，需要橋接或其他接入方式，台灣、香港、澳門、新加坡、馬來西亞一般都可以直連，限制轉移到你發表了什麼與 SIM 實名登記留下的紀錄，香港另有 2026 年 3 月起在國安調查中要求交出裝置密碼的義務，連轉機旅客都適用。逐地的可達性與法規細節見出差與研討會的數位準備。Brave 的指紋防護屬於瀏覽器內建功能，不涉及接入方式，裝完就生效。

用 Tor Browser 的人要記得一致化路線靠整體一致性維持。安裝擴充套件、最大化視窗、改動字型設定，都會讓你從人群裡凸出來，細節見 Tor Browser 進階設定。同一個動作在 Brave 上影響有限，在 Tor Browser 上會直接破壞防護的前提。

想確認自己的瀏覽器洩漏了什麼，EFF 的 Cover Your Tracks 會列出瀏覽器回報的 WebGL 廠商與繪圖器字串，以及各項特徵的識別力。Brave 的更新完整推送到你的裝置之後，兩個欄位會塌成通用值¹。

還沒做完的部分¶

WebGPU 支援的擴充清單目前還沒納入隨機化，公告裡寫了之後會補上¹。圖形 API 仍是指紋研究的活躍領域，新的洩漏管道會持續出現。

網站功能受損的情況還在觀察期。Brave 保留了逐站調整防護的能力，遇到確實無法正常運作的網站，使用者可以單站關閉圖形防護、關閉指紋防護，或整個關掉 Shields¹。保留這些開關代表取捨仍在，一致化與注入雜訊都無法保證所有網站維持原本的行為。

指紋識別不會因為一次瀏覽器更新而結束。顯示卡這一項被處理掉之後，字型清單、canvas 繪圖結果、音訊運算特徵仍在原地。能安全收斂成常數的訊號就收斂，牽涉功能協商的訊號就注入雜訊，這條分工線也適用於檢視其他標榜指紋抗性的工具。

在田間學的兩場數位安全線上課，8/26 這場還能報名

anoni.net 社群 — Wed, 19 Aug 2026 00:00:00 +0000

在田間學的兩場數位安全線上課，8/26 這場還能報名¶

活動主視覺由《田間》製作，來源：在田間學活動頁面

《田間》在「在田間學」開了「數位安全與隱私保護系列」，兩場免費線上課程。8/12 的第一場由我們社群的 Toomore 分享，8/26 的第二場由黃豆泥（Mashbean）接續，現在還可以報名。

《田間》與「在田間學」¶

《田間》是獨立研究計畫 China Media Project 的華文刊物，關注全球華文媒體的發展與挑戰，也鼓勵媒體圈之間的交流。China Media Project 2004 年成立於香港大學新聞及傳媒研究中心，目前設於美國，在台北設有研究據點。《田間》的關於我們頁面上寫著「我們堅信新聞自由，致力於推動華文圈的民主和開放社會」。核心團隊三個人，主編簡恒宇、記者蘇曉凡、調查協調專員呂伊萱。團隊之外另有一組編輯顧問群，成員包含獨立記者喬龍、香港記者協會主席鄭嘉如、香港中文大學新聞與傳播學院副教授方可成、數位素養實驗室（FactLink）創辦人陳慧敏、《北漂臺灣》作者杜晉軒，以及 READr 總編輯簡信昌。

「在田間學」是他們為華文新聞工作者與內容創作者開設的線上學習平台，課程與活動都免費。這個系列的設定寫在活動頁上：「在資安風險無所不在的今天，個人數位足跡對新聞工作者格外重要，本系列課程將從個人裝置盤點出發，到探討平台中介者如何成為保護資訊流通與支持安全協作的屏障。」

兩場的分工很清楚。第一場處理記者自己手上的裝置與帳號，第二場處理記者所依賴的平台。

第一場，個人隱私與你手上的消息來源（已結束）¶

時間：2026/08/12（三）19:30 - 21:00（+0800）
講者：Toomore（anoni.net 共同維護者）

內容從個人隱私盤點開始，包含手機定位權限的檢視、隱私防護現況的評估，以及記者工作中的安全應變。

《田間》記者蘇曉凡把當天的內容整理成一篇筆記，2026/08/18 發佈：

【在田間學】數位資安與隱私保護系列課程

（作者：蘇曉凡，《田間》，2026/08/18）

筆記分成個人隱私檢測、通訊錄與行事曆、帳號與密碼管理、WiFi 與移動裝置、與消息來源、推薦工具六個段落，把當天的操作步驟寫得比現場更好讀。想回顧或補課的夥伴，直接讀那一篇最快。當中有一句話特別適合當成起點：「盡量不要讓你的 APP 觸碰通訊錄。」

當天提到的主題，文件站都有對應的頁面可以延伸閱讀。

筆記段落	延伸閱讀
個人隱私檢測	一般人平常該做到什麼、社群平台怎麼收集你的資料
通訊錄、行事曆	Metadata 是什麼，為什麼重要
帳號與密碼管理	密碼管理器入門、Asian Diceware
WiFi 與移動裝置	出差與研討會的數位準備、瀏覽器指紋是什麼，為什麼很難擺脫
與消息來源	記者保護消息來源、匿名通訊工具比較

密碼挑三到六個英文單字隨意排列的做法，我們也做了一份帶亞洲味的字典，見 Asian Diceware。

第二場，平台中介者如何成為保護獨立記者的屏障（8/26）¶

時間：2026/08/26（三）19:30 - 21:00（+0800），歐洲中部時間 13:30 - 15:00，美東時間 07:30 - 09:00
講者：黃豆泥 / Mashbean（哈佛甘迺迪學院 Allen Lab Fellow、Matters 總經理）
形式：線上（Webex），免費，以中文進行
主題：匿名性、隱私保護、通訊安全與資源傳遞，並介紹可以立即採用的實務工具

報名在活動頁面按報名按鈕，需要先註冊「在田間學」的帳號。課後《田間》會提供參與者一份數位小冊。

活動頁面與報名

為什麼推薦這一場¶

第一場的重點放在記者自己能控制的部分，裝置、帳號、瀏覽器指紋，以及跟消息來源的聯繫管道。做完之後，剩下的風險有一大半落在平台身上。訊息存在誰的伺服器上、平台被要求交出資料時會怎麼處理、內容被下架或帳號被停用時作品還在不在，都是個人設定管不到的範圍。第二場把題目設定在平台中介者能為記者做什麼，補上我們沒有涵蓋的另一半。

其他資源¶

從 OONI 公開資料看 8/13 北部行動網路降速的 30 分鐘

anoni.net 社群 — Sat, 15 Aug 2026 00:00:00 +0000

從 OONI 公開資料看 8/13 北部行動網路降速的 30 分鐘¶

台灣長期沒有經歷大規模的網路降速或斷網。對日常生活來說是好事，對想理解網路異常的人來說，代表手上缺少對照的樣本。OONI 是國際上長期在做網路封鎖與連線品質觀測的開源專案，任何人都能安裝它的 App 參與量測，結果全部公開。台灣在裡面的紀錄，一直呈現一個正常運作的網路。

8 月 13 日之前的 30 天，台灣三家行動業者在 OONI 上留下 564 筆成功的連線速度測試（測項名稱 ndt），下載中位數 12,425 kbit/s，低於 2,000 kbit/s 的只有 4 筆，其中 2 筆還是量測失敗。kbit/s 是每秒傳輸的千位元數，數字越大越快，1,000 kbit/s 約等於 1 Mbps。

8 月 13 日 14:30 到 15:00，北部七縣市的行動網路降速 30 分鐘。兩天前社群發出號召，請大家在降速時段執行 OONI Probe 的效能測試。當天全台留下 238 筆連線速度測試與 235 筆影音串流測試（測項名稱 dash），其中在行動網路上完成的有 170 筆與 168 筆，來自 47 支裝置。8 月 10 日中部場的同一個時段，全台灣的行動網路效能量測是 0 筆。

號召的起點來自社群夥伴 mashbean（黃豆泥）。演習前他提議趁著難得的時間點找大家一起用 OONI 記錄，兩邊於是分頭準備，一邊整理號召與操作說明，一邊在當天實地觀測。他把自己的紀錄寫成另一篇文章，追到了演習公告結束之後網路仍然受限的情形，正好補上本文資料看不見的時段。兩篇一起讀，涵蓋的時間才完整。

其中一支中華電信行動的手機，在降速時段量到 788 到 1,709 kbit/s。台灣的公開資料裡沒有出現過同一量級的數字。需要先說明的是，數字來自單一裝置留下的 6 筆紀錄，足以作為一個完整的個案，不足以推論全國或任何一家業者的普遍狀況。

本文記錄的是網路狀態。業者是否確實執行指令、官方公布的數字精不精確，都不在討論範圍。台灣過去沒有降速樣態的資料，把 30 分鐘的觀測留下來是主要目的。以下的查詢都免驗證免金鑰，讀者可以自行重新執行一次。

整理資料的過程裡，最實用的收穫與降速本身無關，而是判讀方法。降速與封鎖在 OONI 資料上是兩種完全不同的樣態。封鎖會讓異常率飆升、留下確認封鎖的紀錄，降速則完全不動判定欄位，變化只出現在吞吐量與延遲的數值上。當天全台的網路連線測試異常率是 1.0%，與平常的 0.6% 落在同一個區間，確認封鎖整天維持在 0，下降的只有速度。拿封鎖判定的異常率去描述降速，會得到一個接近平常的數字，然後誤以為什麼都沒發生。

先看當天資料的整體樣態¶

把當天全台的連線速度測試按 15 分鐘分組，社群動員會直接呈現在資料上。

8 月 13 日各 15 分鐘區間的連線速度測試筆數，橘色為降速時段

{"description":"OONI ndt measurements per 15 minutes in Taiwan on 2026-08-13","data":{"values":[{"t":"13:00","n":3,"g":"一般時段"},{"t":"13:15","n":4,"g":"一般時段"},{"t":"13:30","n":11,"g":"一般時段"},{"t":"13:45","n":4,"g":"一般時段"},{"t":"14:00","n":9,"g":"一般時段"},{"t":"14:15","n":27,"g":"一般時段"},{"t":"14:30","n":13,"g":"降速時段"},{"t":"14:45","n":50,"g":"降速時段"},{"t":"15:00","n":31,"g":"一般時段"},{"t":"15:15","n":15,"g":"一般時段"},{"t":"15:30","n":2,"g":"一般時段"},{"t":"15:45","n":2,"g":"一般時段"}]},"mark":{"type":"bar","tooltip":true,"cornerRadiusEnd":4},"encoding":{"x":{"field":"t","type":"ordinal","title":"台灣時間（每 15 分鐘）","axis":{"labelAngle":-45}},"y":{"field":"n","type":"quantitative","title":"連線速度測試筆數"},"color":{"field":"g","type":"nominal","title":null,"scale":{"domain":["一般時段","降速時段"],"range":["#0089bf","#e65100"]},"legend":{"orient":"top"}}}}

號召文請大家設 14:35 的鬧鐘，行有餘力再加 14:15 與 15:10。三個尖峰都出現了，14:45 到 15:00 的 50 筆是全天最高點。前 30 天全台平均一天約 34 筆連線速度測試，多數來自少數幾台裝置的自動排程，當天單一個 15 分鐘區間就超過平常一整天。

各 15 分鐘區間的完整筆數

台灣時間	筆數
`13:00` 到 `13:15`	3
`13:15` 到 `13:30`	4
`13:30` 到 `13:45`	11
`13:45` 到 `14:00`	4
`14:00` 到 `14:15`	9
`14:15` 到 `14:30`	27
`14:30` 到 `14:45`	13
`14:45` 到 `15:00`	50
`15:00` 到 `15:15`	31
`15:15` 到 `15:30`	15
`15:30` 到 `15:45`	2
`15:45` 到 `16:00`	2

各業者的參與情況如下。AS 開頭的編號是自治網路的全球識別碼，電信商、企業、學校都有各自的號碼，OONI 只記錄到業者層級，不記錄使用者位置。裝置數以 OONI 產生的匿名裝置識別碼（probe_id）去重計算。

業者	8/13 筆數	前 30 天筆數	當天裝置數
`AS17421` 中華電信行動	`68`	`20`	22
`AS9674` 遠傳	`51`	`12`	15
`AS24158` 台灣大哥大	`55`	`538`	9

三個數值欄都是連線速度測試的數量，前兩欄的單位是量測筆數，最後一欄是不重複的裝置數。一支手機測三次算 3 筆、1 支裝置。

中華電信行動與遠傳原本是台灣 OONI 資料裡覆蓋最少的兩家。一個下午的量測超過了兩家過去 30 天的累積。台灣大哥大的前 30 天筆數本來就高，來自少數裝置的長期自動執行，當天新增的 9 支裝置是過去沒有的分布。

資料上分不出誰是看到號召才測的。App 裡的效能測試是一張內建卡片（編號 00107），全球使用者點下去執行的都是同一張，當天光是台灣以外就有上千筆帶著同一個編號。號召的效果只能從前後量的對比推估，看不到個別參與者的來源。

放大到一支手機的 30 分鐘¶

裝置識別碼可以把同一支手機的多筆量測串起來。當天有一支中華電信行動的 Android 手機在降速前後都執行了測試，兩個效能測項各留下 6 筆。

同一支手機的下載與上傳吞吐量，灰帶為降速時段。縱軸為對數座標，資料跨兩個多數量級。13:33 到 14:36 之間沒有量測，線段在此斷開

{"description":"Download vs upload throughput of a single mobile device during the 2026-08-13 throttling drill","layer":[{"data":{"values":[{"s":"2026-08-13T14:30:00","e":"2026-08-13T15:00:00"}]},"mark":{"type":"rect","opacity":0.12,"color":"#546e7a"},"encoding":{"x":{"field":"s","type":"temporal"},"x2":{"field":"e"}}},{"data":{"values":[{"t":"2026-08-13T13:32:00","d":"下載","seg":"降速前","v":89510},{"t":"2026-08-13T13:33:00","d":"下載","seg":"降速前","v":174682},{"t":"2026-08-13T14:36:00","d":"下載","seg":"降速中","v":788},{"t":"2026-08-13T14:39:00","d":"下載","seg":"降速中","v":881},{"t":"2026-08-13T14:51:00","d":"下載","seg":"降速中","v":1565},{"t":"2026-08-13T14:52:00","d":"下載","seg":"降速中","v":1709},{"t":"2026-08-13T13:32:00","d":"上傳","seg":"降速前","v":21510},{"t":"2026-08-13T13:33:00","d":"上傳","seg":"降速前","v":16348},{"t":"2026-08-13T14:36:00","d":"上傳","seg":"降速中","v":26300},{"t":"2026-08-13T14:39:00","d":"上傳","seg":"降速中","v":31789},{"t":"2026-08-13T14:51:00","d":"上傳","seg":"降速中","v":22370},{"t":"2026-08-13T14:52:00","d":"上傳","seg":"降速中","v":32695}]},"mark":{"type":"line","strokeWidth":2,"point":{"size":70,"filled":true},"tooltip":true},"encoding":{"x":{"field":"t","type":"temporal","title":"台灣時間","axis":{"format":"%H:%M"},"scale":{"padding":18}},"y":{"field":"v","type":"quantitative","scale":{"type":"log","domain":[500,250000],"nice":false},"title":"吞吐量 kbit/s（對數座標）"},"color":{"field":"d","type":"nominal","title":null,"scale":{"domain":["下載","上傳"],"range":["#0089bf","#e65100"]},"legend":{"orient":"top"}},"detail":{"field":"seg","type":"nominal"}}}]}

下載的兩段落差兩個數量級，上傳的兩段幾乎在同一個高度上。

前兩筆在降速開始前約一小時，後四筆在降速時段內。下載中位數由 132,096 kbit/s 降到 1,223 kbit/s，兩個測項各自算出的比值是 1/108 與 1/88。放回台灣資料的脈絡看，落差更明顯：中華電信行動在前 30 天的 18 筆量測裡，最低值是 42,197 kbit/s，降速中的 788 kbit/s 是該業者在公開資料上前所未見的量級。

同一批量測還記錄了往返延遲與重傳率，六筆的完整數值如下。

台灣時間	下載	上傳	串流位元率	最小 RTT	平均 RTT	重傳率
`13:32`	`89,510`	`21,510`	`138,513`	`18.39`	`66.78`	`0.000%`
`13:33`	`174,682`	`16,348`	`119,179`	`17.85`	`82.05`	`0.001%`
`14:36`	`788`	`26,300`	`1,308`	`16.85`	`168.40`	`0.522%`
`14:39`	`881`	`31,789`	`1,608`	`19.97`	`137.24`	`0.202%`
`14:51`	`1,565`	`22,370`	`1,624`	`18.72`	`130.05`	`0.000%`
`14:52`	`1,709`	`32,695`	`821`	`18.28`	`114.79`	`0.000%`

前三個數值欄的單位是 kbit/s，數字越大越快，其中 1,308 kbit/s 大致相當於標準畫質的串流。兩個 RTT 欄的單位是毫秒（ms），數字越小代表封包來回一趟越快，最小 RTT 取整段測試中最快的一次，接近線路本身的實際距離，平均 RTT 則把途中排隊的時間也算進去。重傳率是需要重送的封包所佔比例。

解讀吞吐量時要記得一件事，連線速度測試的對端是 M-Lab 的伺服器，數值裡同時包含最後一哩與到 M-Lab 節點的國際線路，單筆結果無法把兩段分離。延遲欄位正好回應該項疑慮：最小 RTT 全程維持在 17 到 20 ms，與封包路徑未改變的情形一致，也降低了「速度變化來自國際線路」的可能。平均 RTT 從 67 到 82 ms 升到 115 到 168 ms，代表封包在某處出現佇列延遲（queuing delay）。重傳率四筆裡有兩筆從降速前的近乎 0 升到 0.522% 與 0.202%，相對變化不小，絕對值仍低於 0.6%，較符合延遲送出而非大量丟棄的樣態。

三個欄位合起來，構成流量整形（shaping）在資料上的特徵。若手段是丟棄封包，重傳率會上升得更明顯。若成因是訊號劣化或換了基地台，最小 RTT 通常會跟著變動。以上判讀同樣建立在單一裝置上。

行政院對演練做法的說明是核心網路限流，將行動網路下載速率調降至 256KB²。原始說法沒有標明單位，若解讀為每秒 256 KB，換算後是 2,048 kbit/s。若解讀為 256 kbit/s，量級則完全不同。本文不做數值精確度的比對，列出官方說法是讓讀者知道公布的量級落在哪裡。

沒有降速訊號的量測撐起了對照¶

47 支裝置裡，46 支在降速時段量到的是正常速度。降速時段三家行動業者的下載中位數是 42.2 Mbps，降速前是 53.2 Mbps，恢復後是 58.5 Mbps，三個時段落在同一個量級。

正因為有整批正常數值墊底，單一裝置的 788 kbit/s 才能被認定是特殊的。若當天所有人都測到低速，合理的解釋會變成全台網路普遍變慢，或當天的一般波動。若只有一支手機在測，低速也可能來自該裝置自身的狀況，例如訊號不良或背景程式佔用頻寬。同時段有 32 支裝置執行同一組測試，其中 31 支正常，單一裝置的異常才站得住。

號召文請不在降速範圍的人也測一次，用意即在於此。範圍外的量測不是白測的，它們決定了範圍內的數字能不能被解讀。人在台南、在高雄，或當天根本不在台灣，只要在同一個時間點按下執行，資料都落在同一個公開資料庫裡，都是對照的一部分。

當天全球有數千筆同樣的效能測試在執行，台灣的差別只在於有明確的事件與時間邊界可以對應。缺了對照組，剩下的就只是一個孤立的低速數字，說明不了任何事。

體感怎麼對應到欄位¶

社群沒有做體感問卷，以下從資料回推當時使用手機會遇到的狀況。

影片轉圈圈¶

影音串流測試會記錄開始播放前的等待時間。降速前的兩筆都是 0 秒，降速中的三筆分別是 0.12 秒、0.12 秒與 5.29 秒。最後一筆等了超過五秒緩衝才開始播放，正是點開影片後盯著圈圈轉的等待時間。

傳訊息、傳照片出去反而順暢¶

降速中的四筆上傳分別是 26,300、31,789、22,370 與 32,695 kbit/s，與降速前的 21,510、16,348 kbit/s 相比沒有下降。上傳與下載的倍率達到 33、36、14、19 倍。限流是單向的，只作用在下載方向。單向限流也解釋了號召文提醒過的一件事：量測結果的上傳在降速期間仍然順暢，資料能即時送出，不需要等網路恢復後補傳。

點下去要等一下才有反應¶

平均 RTT 翻倍，每一次點擊到畫面更新之間的空檔會被拉長。

網頁還是開得出來，只是慢¶

降速時段全台有 1,893 筆網路連線測試（Web Connectivity），異常率 1.0%，降速前與恢復後都是 0.6%。確認封鎖的筆數在所有時段皆為 0。網站連得到，Tor 與 Psiphon 也連得上，降速時段的 33 筆 Tor 測試與 33 筆 Psiphon 測試異常數都是 0。

降速的 30 分鐘在資料上呈現為速度下降，連線本身沒有中斷。

降速與斷網在資料上是兩種樣態¶

OONI 的多數測項在做封鎖判定，例如網路連線測試、Telegram、Signal。真正的封鎖或斷網發生時，異常率會飆升、出現確認封鎖的紀錄，嚴重時量測直接失敗，連報告都送不出來，資料庫裡留下的是一段空白。降速時連線全部成功，報告照常送出，判定欄位一動也不動。

	封鎖或斷網	降速
連線是否成功	大量失敗	全部成功
異常率	明顯上升	不動
確認封鎖	可能出現	維持 `0`
吞吐量	未必反映	明顯下降
該看哪一組測項	有封鎖判定的測項	效能測項的數值

判準因此很清楚。想觀測降速，要看效能測項的數值。想觀測封鎖，要看有判定的測項。兩者用錯了，得到的數字都會指向錯誤的結論。

號召文事前只請大家執行效能測試，原因也在於此。限速期間執行有封鎖判定的測項，手機端大量逾時而輔助伺服器一切正常，比對出來會被標成封鎖的簽名，等於在台灣的公開資料裡注入一批看起來像審查的紀錄。當天的結果顯示假訊號沒有出現。

兩種樣態都可以自行查看。台灣 8 月 13 日的逐小時分布裡，確認封鎖整天維持在 0，降速的一小時同樣為 0。OONI 團隊查證過的封鎖事件收在 Findings，每則都連著對應的量測資料，可以看到確認封鎖的筆數在事件期間如何上升。兩邊查的是同一個資料庫、同一組欄位，差別只在數值。

結論怎麼從公開資料得出¶

第一步，把時間區間內的量測撈出來¶

measurements 端點免驗證，接受精確到秒的時間區間。

https://api.ooni.org/api/v1/measurements?probe_cc=TW&test_name=ndt &since=2026-08-13T06:00:00Z&until=2026-08-13T08:00:00Z&limit=200

所有時間一律為 UTC，台灣時間需減 8 小時，降速時段對應 06:30 到 07:00。要取台灣時間的一整天，起訖要往前推 8 小時，寫成 2026-08-12T16:00:00Z 到 2026-08-13T16:00:00Z。回傳的每一筆都帶網路編號（probe_asn）與量測編號（measurement_uid）。筆數超過 limit 時回傳裡會有 next_url，要逐頁取完才不會漏資料，當天的連線速度測試就有 238 筆，一次 limit=200 取不完。

第二步，取原始 JSON 拿數值¶

列表本身不含吞吐量，要再開每一筆回傳的 measurement_url。連線速度測試的數值在 test_keys.summary，包含下載（download）、上傳（upload）、最小往返延遲（min_rtt）、平均往返延遲（avg_rtt）與重傳率（retransmit_rate）。影音串流測試的數值在 test_keys.simple，包含位元率中位數（median_bitrate）與播放等待時間（min_playout_delay）。

第三步，剔除非行動網路的量測¶

原始 JSON 的網路類型欄位（annotations.network_type）會標記行動網路（mobile）、Wi-Fi（wifi）、有線（wired_ethernet）或 VPN（vpn）。當天 238 筆連線速度測試裡，只有 170 筆標記為行動網路。少了篩選，家用光纖與 VPN 的量測會混進來，而兩者本來就不在降速範圍內。

第四步，用裝置識別碼串起同一支手機¶

識別碼在原始 JSON 的頂層，欄位名是 probe_id，與吞吐量所在的 test_keys 是平行的兩個位置。值是 OONI 為每台裝置產生的匿名雜湊，同一支手機的多筆量測會帶同一個值，把值相同的量測收在一起就是該裝置當天的完整紀錄。當天 238 筆連線速度測試裡有 18 筆沒有帶識別碼，無法歸戶到任何一支裝置，本文的裝置數也不計入。

單筆量測難以獨立判讀，因為手機型號、位置、訊號強度全都不同。同一支手機的自身前後對照直接得多。本文的關鍵表格即由此得出。

第五步，排除誤判¶

兩個當天實際遇到的例子。

一支台灣大哥大的裝置在 14:54 量到 3,124 kbit/s，看起來像降速。但它在當天 20:11 又量到 3,126 kbit/s，影音串流位元率整天落在 2,072 到 2,909 kbit/s 之間。數字全天穩定，來自該門號本身的速率上限，與演練無關。只看降速時段的資料，很容易把它算進證據裡。

降速時段另有 5 筆量測完全失敗，錯誤分別是連線逾時、DNS 查詢失敗與連線被拒。失敗的成因無法從單筆結果判定，可能來自降速，也可能來自一般的連線問題，因此不列入。

第六步，建立對照組¶

8 月 10 日、11 日、12 日的同一個時段，行動網路的效能量測沒有任何一筆低於 2,000 kbit/s，8 月 12 日的 7 筆裡最低是 8,399 kbit/s。低於 2,000 kbit/s 的量測只出現在 8 月 13 日的降速時段，當天其他時段都沒有。有了對照組，才能把觀察到的低速與一般波動分開。

超出本批資料範圍的問題¶

位置¶

OONI 記錄國家與 ASN，不記錄縣市，也不記錄基地台位置。從資料看得出一筆量測來自 AS17421，看不出手機當時在台北還是台南。47 支裝置裡只有 1 支留下明確的降速訊號，最可能的解釋是其他人不在降速的七個縣市內，但公開資料無法驗證。

不記錄位置是 OONI 的設計選擇，理由是保護參與者。在審查嚴重的國家，量測者的位置資訊會直接轉為人身風險。該取捨是對的，代價是地理範圍明確的事件難以精確對位。想補上位置維度，需要社群自己另外收集，例如一份自願填寫的縣市登記表單，且只收到縣市層級、不與裝置識別碼對應，避免補回 OONI 刻意拿掉的追蹤能力。

跨業者的資料涵蓋度¶

留下完整前後對照的裝置集中在中華電信行動一家。台灣大哥大與遠傳在降速時段的低值都是量測失敗，沒有可判讀的數值。落差來自參與者分布與資料落點，不代表各業者的網路狀況有差異。要看到不同業者在同一時段的樣態，需要每一家都有裝置完成降速前、降速中、恢復後的量測。

恢復所需的時間¶

留下完整降速紀錄的手機，最後一筆量測在 14:52，之後沒有再執行，本文的前後對照到此為止。恢復後的 30 分鐘有 38 筆量測，全部來自沒有降速訊號的裝置，同一支裝置跨越降速中與恢復後的比較無從談起。

公開資料裡留著恢復期的線索，是本文的篩選條件把它擋掉的。台灣大哥大的一支裝置在 15:08 量到 55 kbit/s，兩分鐘後的串流測試回傳 0，兩筆都落在演習公告的結束時間之後。本文的統計沒有納入，因為兩筆的網路類型欄位都是空的，而為了排除固網與 VPN，本文只計入明確標記為行動網路的量測。篩選擋掉雜訊的同時，也擋掉了訊號。

補上該時段的是 mashbean 的實地觀測。他記錄到 15:08 的下載仍然只有 55 kbit/s，串流測試從逾時轉為完成，一直到 17:47 才恢復到可用的水準，並據此主張恢復時間應該納入韌性演習的成效指標，功能恢復與回到基準要分開判讀。裝置在誰手上、當時走的是不是行動網路、人在哪個縣市，OONI 不記錄的維度，只有量測者本人說得出來。

把兩份觀測的時間點排在一起，當天下午的輪廓才完整。

當天下午的事件時間軸，灰帶為公告的降速時段，縱軸依資料來源分列

{"description":"Timeline of drill events and observations on 2026-08-13 afternoon","layer":[{"data":{"values":[{"s":"2026-08-13T14:30:00","e":"2026-08-13T15:00:00"}]},"mark":{"type":"rect","opacity":0.12,"color":"#546e7a"},"encoding":{"x":{"field":"s","type":"temporal"},"x2":{"field":"e"}}},{"data":{"values":[{"t":"2026-08-13T14:30:00","src":"行政院公告","e":"降速開始"},{"t":"2026-08-13T15:00:00","src":"行政院公告","e":"降速結束"},{"t":"2026-08-13T14:36:00","src":"本文資料","e":"788 kbit/s，全天最低"},{"t":"2026-08-13T14:39:00","src":"本文資料","e":"881 kbit/s"},{"t":"2026-08-13T14:52:00","src":"本文資料","e":"1,709 kbit/s，該裝置最後一筆"},{"t":"2026-08-13T15:08:00","src":"本文資料","e":"另一支裝置 55 kbit/s"},{"t":"2026-08-13T15:10:00","src":"本文資料","e":"串流測試回傳 0"},{"t":"2026-08-13T17:47:00","src":"mashbean 觀測","e":"恢復到可用水準"}]},"mark":{"type":"point","size":110,"filled":true,"color":"#0089bf","tooltip":true},"encoding":{"x":{"field":"t","type":"temporal","title":"台灣時間","axis":{"format":"%H:%M"},"scale":{"padding":26}},"y":{"field":"src","type":"nominal","title":null,"sort":["行政院公告","本文資料","mashbean 觀測"]},"tooltip":[{"field":"t","type":"temporal","format":"%H:%M","title":"時間"},{"field":"e","type":"nominal","title":"事件"}]}}]}

圖上最長的一段是空白。公告寫的結束時間是 15:00，最後一筆低速紀錄落在 15:08，實際恢復到堪用是 17:47。三個時間點各自代表不同的意思，中間隔了將近三小時。

時間軸的完整事件列表

台灣時間	發生的事	依據
`14:30`	公告的降速開始時間	行政院公告
`14:36`	單一裝置量到 `788` kbit/s，全天最低	本文
`14:39`	同一裝置 `881` kbit/s，上傳仍有 `31,789`	本文
`14:52`	同一裝置最後一筆，`1,709` kbit/s	本文
`15:00`	公告的降速結束時間	行政院公告
`15:08`	另一支裝置仍量到 `55` kbit/s	本文與 mashbean
`15:10`	同一支裝置的串流測試回傳 `0`	本文與 mashbean
`17:47`	恢復到可用水準	mashbean 的實地觀測

單一裝置的代表性¶

本文對限流方向與層級的描述，建立在一支手機的 6 筆量測上。數字內部互相一致，兩個獨立測項也指向同一個結論，作為單一案例的紀錄是完整的。要談到分布、平均降幅或信賴區間，需要的樣本量遠不止於此。

另外，47 支裝置都是看到號召後自願參與的社群成員，並非隨機抽樣。要用來做跨業者或跨區域的推論，需要先處理選樣偏誤。

一起來研究 OONI 的公開資料¶

本次觀察沒有用到特別的工具，全部來自公開 API 與一點資料整理。OONI 的資料有四個入口，用途各不相同。

OONI Explorer：網頁介面，適合查單筆量測、看某個國家或 ASN 的趨勢，無須寫程式。
Aggregation API：https://api.ooni.org/api/v1/aggregation，免驗證免金鑰，可依國家、測項、ASN 切分做統計。起訖只接受日期，適合看天級以上的趨勢。
Measurements API：https://api.ooni.org/api/v1/measurements，接受精確到秒的時間區間，回傳逐筆紀錄。本文的主要資料出自此端點。
AWS S3 公開資料集：ooni-data-eu-fra，逐筆原始 JSON，適合需要檢視量測細節或做大規模分析的研究。取用方式與 CSV 輸出格式寫在 ASN 觀測資料擷取與分析，社群維護的擷取程式也在該頁。

不寫程式也能參與。裝一次 OONI Probe 並執行，每一筆量測都會進入公開資料庫，成為台灣網路狀態的長期紀錄。前 30 天全台平均一天只有 34 筆連線速度測試，多一支手機的日常量測，基準就厚一分。下一次遇到非預期的網路變慢時，能不能分辨是自己的問題還是網路的問題，取決於平常累積了多少。

台灣還有不少題目尚待投入。行動網路的長期基準目前仍然很薄，三家業者的覆蓋差了一到兩個數量級，細節見 ASN 自治網路觀測資料分析。要判斷某個問題該用哪個測項，OONI 測項速查表整理了每個測項量測什麼、規格狀態，以及台灣是否有資料。

判讀資料時最常見的誤解，是把異常（anomaly）當成封鎖。異常只代表測試未照預期完成，成因包含審查、網路不穩、ISP 暫時故障，以及測試程式本身的問題。以 Tor 測試為例，加拿大、瑞士、紐西蘭等沒有審查的國家，異常率同樣落在 16% 到 22% 之間。把異常率直接當成封鎖率會產生假指控。

演習依分區實施，北部場是今年的最後一場，相同條件要等到明年。本次留下的資料是台灣目前唯一一筆有明確情境對應的降速紀錄，之後遇到非預期的網路劣化時，總算有可以比對的樣本。

想一起整理資料、規劃下一次的觀測，或是對 OONI 公開資料有任何問題，歡迎到社群的 Matrix Public Space 討論。

資料與前提¶

查詢日為 2026-08-14，量測資料仍會持續補傳，之後重查可能得到略高的筆數。所有日期以台灣時間為準，換算成 API 接受的 UTC 時再往前推 8 小時。以下的 test_name 等參數為 API 實際接受的值，照列以便重現查詢。

當天逐筆量測用 measurements 端點，probe_cc=TW、since=2026-08-12T16:00:00Z、until=2026-08-13T16:00:00Z，對應台灣時間 8 月 13 日整天。test_name 分別為 ndt、dash、web_connectivity、tor、psiphon。降速時段等時段統計另以 UTC 06:00 到 07:30 的區間查詢。

吞吐量、往返延遲與裝置識別取自每筆量測的原始 JSON，經由 measurements 回傳的 measurement_url 取得，欄位位置見上方的觀察流程。本文的行動網路量測僅計入網路類型為 mobile 者，排除 Wi-Fi 與 VPN。裝置以 probe_id 去重，部分量測沒有帶值，未帶值者不計入裝置數。當天三家的筆數為該 ASN 的全部量測，與前 30 天基準採同一種計算方式，扣掉 2 筆 VPN 與 3 筆未標記網路類型後，行動網路上完成的分別是 67、50 與 52 筆。行動網路的 170 筆裡另有 1 筆來自 AS9416，不屬於三家全國性業者，未列入業者表格。

前 30 天的行動網路基準（564 筆、中位 12,425 kbit/s、低於 2,000 kbit/s 的 4 筆、中華電信行動最低 42,197 kbit/s）用 measurements 端點，probe_cc=TW、test_name=ndt、since=2026-07-13T16:00:00Z、until=2026-08-12T16:00:00Z，對應台灣時間 7 月 14 日到 8 月 12 日，probe_asn 分別為 AS24158、AS17421、AS9674，同樣逐筆取原始 JSON 後剔除非行動網路的量測。

對照日用同樣的 measurements 參數，日期換成 2026-08-10、2026-08-11 與 2026-08-12，時間區間為 UTC 05:30 到 07:30。

本文不公開任何個別裝置的識別碼。該欄位雖然出現在 OONI 的公開資料中，寫出具體值等於為單一參與者的量測歷史建立索引，與量測本身的目的無關。

演習細節以行政院公告與各電信業者公告為準¹。

資料來源：OONI measurements 與 aggregation API（查詢條件見上方，量測資料授權 CC BY-NC-SA 4.0）、ASN 名稱取自 RIPEstat。

2026城鎮韌性（防空）演習：行動網路降速演練 - 行政院 ↩
行政院補充降速做法 - 中央社 ↩

介紹 Signal 自動金鑰驗證

anoni.net 社群 — Thu, 13 Aug 2026 00:00:00 +0000

介紹 Signal 自動金鑰驗證¶

翻譯備註：Signal 在 2026 年 8 月 11 日推出「自動金鑰驗證」（automatic key verification），底層技術是金鑰透明度（key transparency）。既有的安全碼（safety number）要當面或透過另一條可信管道核對，自動金鑰驗證改由 App 自己去比對，省掉約時間見面的步驟。技術在通訊軟體上還算新，Signal 這篇是少數把設計動機與運作方式一次說完的公開文件，因此先完整翻譯，文末再附上編輯註解，說明它擋得住什麼、擋不住什麼。

以下內容原文翻譯來自以下文章，主詞角色為 Signal：

Introducing Automatic Key Verification, Katherine Yen 2026-08-11

文末有編輯註解：譯文結束後接著編輯註解，內容是 anoni.net 社群的補充，包含三條給非技術讀者的結論、十三則說明、一節發布後的後續補充，最後是常見問題與延伸閱讀。想先看社群觀點的讀者可以直接跳到那一節。

Signal 現在提供一項名為「自動金鑰驗證」的功能，用來補強既有的安全碼機制。Signal 的通訊一律採端對端加密，自動金鑰驗證多提供一條簡便的途徑，讓你確認端對端加密工作階段的兩端之間沒有非預期的第三方介入。

運作方式是由你、你的 Signal 聯絡人，以及第三方稽核者各自執行一組驗證，合起來提供與手動核對安全碼相同的保證。與安全碼相比，各項驗證都是獨立完成的，不需要當面見面，也不需要第二條通訊管道。

整套驗證機制確保電話號碼或使用者名稱與其公開加密金鑰之間的對應關係，在 Signal 生態系的所有參與者眼中都一致而且透明。可以防範的情境是金鑰在擁有者不知情的狀況下被抽換，例如惡意方入侵 Signal，把另一把金鑰掛到你聯絡人的電話號碼上。

要實際操作，請進入某位 Signal 聯絡人的個人資料頁，點「檢視安全碼」，再點「自動金鑰驗證」標題底下的「自動驗證」按鈕。功能可用而且驗證成功時，按鈕會顯示綠色勾號與「已完成加密驗證」。隨著時間累積，你這一次的驗證，加上聯絡人與第三方稽核者持續執行的驗證，共同確保該位聯絡人的金鑰在整個 Signal 生態系中保持一致。

功能背後的概念稱為「金鑰透明度」（key transparency），後文都會使用這個詞，說明我們為什麼要建一套金鑰透明度系統，並概述運作方式。

公開金鑰與私密金鑰入門¶

非對稱式密碼學讓你能傳訊息給朋友，而且只有朋友讀得到。它牽涉到一對數學上相互關聯的金鑰，稱為公開金鑰與私密金鑰，可以用在許多場合，收發訊息是其中之一。

想像你有一個上鎖的信箱，上面開了投遞口。公開金鑰像信箱的地址，可以給任何想寄信給你的人。私密金鑰像信箱的鑰匙，只有你持有，用它才讀得到寄來的訊息。任何人都可以把信投進你的信箱（用你的公開金鑰加密），只有你能打開來讀（用你的私密金鑰解密）。信箱地址必須公開，沒有人知道要寄到哪裡，你就收不到信。

你註冊 Signal 時，Signal App 會在註冊流程中替你產生一組公開金鑰與私密金鑰¹。私密金鑰留在你的裝置上，只有你能存取，Signal 不行，其他人也不行。公開金鑰會送到 Signal，Signal 扮演所有使用者公開金鑰的中央目錄。你要傳訊息給另一位 Signal 使用者時，會向 Signal 索取對方的公開金鑰，再用 Signal 回傳的金鑰與你的私密金鑰把訊息加密。

中間人 Mallory 攻擊¶

傳訊息要先取得收件人的公開金鑰，取得公開金鑰就需依賴中央目錄。理論上，惡意的目錄營運者可以發動所謂的「中間人 Mallory」攻擊，不過要辦到，需要外部人士繞過主要雲端供應商的安全防護，或由握有權限的內部人士刻意鎖定特定帳號。手法極為進階，發生機率也很低，我們仍然想防住。以下沿用信箱的比喻，說明攻擊在假設情況下如何進行。

假設 Bob 想寄一張喝咖啡的邀請給朋友 Alice，於是他到中央目錄查她的信箱地址。目錄若被對手（Mallory）攻陷，可能把 Bob 導向 Mallory 的信箱。Bob 把信寄到他以為是 Alice 的信箱，信實際上進了 Mallory 的信箱。Mallory 接著用自己的信箱鑰匙取出 Bob 的信，讀過內容，需要的話改寫幾句，換一個信封，再轉寄到 Alice 的信箱。

Mallory 改寫的內容可以是咖啡店的地點或碰面時間，讓 Alice 前往錯誤的地點，或在錯誤的時間出現。Alice 看不出訊息被攔截或竄改過，在她眼中，訊息就是 Bob 直接寄來的。同一時間，Bob 會白等一場。就算 Mallory 選擇不動 Bob 的內容，光是讀得到，就已經構成通訊隱私的嚴重破口。

約咖啡出錯的代價相對低，同樣的攻擊放到其他情境，造成的傷害會大得多。

攻擊能成立，是因為 Bob 從來沒有真的驗證過 Alice 的地址。他只是相信目錄上列的信箱就是她的，而信任目錄是個合理的假設。

Bob 若想格外謹慎，可以當面向 Alice 問地址，或透過另一條可信的通訊管道問²。若 Alice 與 Bob 純粹是筆友，這條路走不通。

那麼，在無法見面、也沒有第二條管道的情況下，Bob 要如何驗證 Alice 的地址？

本文接下來會說明我們如何設計出一套系統，讓 Bob 不必直接聯絡 Alice，也能自動驗證中央目錄裡的資料。

用比喻設計一套金鑰透明度系統¶

要幫 Bob 確認目錄裡 Alice 的地址正確，一種做法是把目錄的每一次變更都記錄下來。有人改動目錄裡 Alice 的地址，就會留在按時間排序的日誌裡，因而可以被察覺。以下把信箱的比喻延伸下去，說得具體一點。

假設市立郵局裡有一位職員，把每個人的地址變更都記在一本公開帳本上。任何人換了新地址或更新既有地址，職員就在不斷變厚的帳本最後面加一頁，把地址變更記在那裡。職員用的是永久性的麥克筆，寫下去之後，沒有人能翻回那一頁撕掉或改內容。任何人都可以到郵局翻帳本查地址，包括查自己的。

使用帳本¶

對任何一筆地址，郵局的客戶有兩種方式跟帳本互動：

像 Bob 這樣的客戶，可以查別人（例如 Alice）的地址。
像 Alice 這樣的客戶，可以查自己的地址，確認帳本記得正確。

Bob 要找到 Alice 目前的地址，需從帳本的最後一頁開始，一頁一頁往前翻，翻到出現 Alice 的那一頁為止。他從尾端倒著翻，是因為他要的是 Alice 最新的地址，而地址可能隨時間變動過。帳本頁數越加越多，Bob 的工作量就越大，尤其在 Alice 有一陣子沒更新地址、中間又夾著大量別人的地址變更需要一頁頁過濾的時候。

帳本讓 Alice 能驗證自己的地址記得對不對，代價是她需把上次來訪之後新增的每一頁都看過，確認沒有一頁把她的地址寫錯。跟 Bob 一樣，頁數越多，工作量越重。

若 Alice 與 Bob 住在人口流動頻繁的城市，大家常換地址，一頁一頁翻的工作量會大到不切實際。兩人需要一種更有效率的方式來使用帳本。

引入索引本¶

現實中的書常附一份按字母排序的索引，讓讀者快速找到要的內容。同樣的想法可以套到帳本上，做法是替帳本至今收錄過地址的所有人名，另外做一本按字母排序的索引本。

帳本每加一頁反映新地址或地址變更，索引本也要跟著更新，所以職員每往帳本加一頁，就發行一版新的索引本，內容涵蓋截至那一頁為止已被帳本收錄地址的所有人。長久下來，就形成一座對外開放的索引本館藏。

先假設對帳本的任一頁，Alice 與 Bob 看到的一定是同一本索引本。下一節會談到系統裡的另一個元件，讓兩人能驗證這項假設。

有了上述結構，Bob 可以改用「二分搜尋」的策略在帳本裡查 Alice 的地址，輕鬆許多，用具體例子最好說明。

假設一段時間內有 100 筆新增或更新的地址，帳本因此有 100 頁，職員也發行了 100 個不同版本的索引本。為了簡化，假設 Alice 的地址只在帳本裡出現過一次，就是她剛搬來的時候。

Bob 先翻到帳本的中間，接著查對應那一頁的索引本。索引本按字母排序，找人名很快。若 Alice 的名字在那本索引本裡，代表兩種可能，它或許就是第一本收錄 Alice 的索引本，也或許第一次出現在更早的版本，也就是帳本更前面的某一頁。

兩種可能都讓 Bob 可以忽略帳本的後半段，改在前半段重複同樣的步驟，直到找出 Alice 地址變更所在的那一頁為止。更精確地說，Bob 的搜尋會在找到相鄰的兩本索引本時結束，前一本沒有 Alice 的地址，後一本有。

搜尋流程有幾個好處，第一個是有效率。帳本若有十億頁，最壞的情況原本要倒著翻完十億頁，現在 Bob 最多只需要檢視 30 頁就能找到 Alice 的地址，工作量比先前輕鬆太多。

Alice 仍然想確認職員沒有新增任何把她地址寫錯的頁面，不過她不必檢查每一頁帳本與每一本索引本。她只需要檢查 Bob 為了找她地址而查過的那幾頁，如此就能確保 Bob 查到的 Alice 地址經過 Alice 本人驗證。

由此帶出搜尋流程的第二個好處：Alice 與 Bob 面對頁數相同的帳本時，流程是確定性的。職員若在 Bob 與 Alice 兩次搜尋之間又加了頁，情況會複雜一些，主要的概念不變。帳本有十億頁時，Alice 可以照著 Bob 的搜尋流程走一遍，查 Bob 查過的同一批頁面，確認裡面沒有任何一頁把她的地址寫錯。

藉由對搜尋流程取得共識，Alice 與 Bob 建立起一套使用帳本的方式，讓各自的目標在實務上可行。帳本持續變厚，Bob 仍然有有效率的方法找到 Alice 的地址，Alice 也有有效率的方法確保 Bob 找到的地址正確。

為了說明清楚，上面的比喻做了簡化。實務上 Alice 可以多次更新地址，要支援這種搜尋，索引本裡要存的資料也不只有人名。我們已經把同樣的想法實作到 Signal 的訊息服務上，做成開源的金鑰透明度伺服器。

職員本身呢¶

到目前為止，搜尋流程的描述都假設 Alice 與 Bob 親自翻帳本、查索引本。實務上並不可行，帳本與索引本的體積遠超過兩人能直接處理的範圍。實際做法是 Alice 與 Bob 請職員代為搜尋，再回報結果。

但郵局可能已經被 Mallory 這類對手攻陷，由她假扮職員，最終目的是讓 Bob 誤以為 Alice 的地址實際上是 Mallory 家。所以 Alice 與 Bob 無法單純信任職員，必須有辦法自己獨立驗證搜尋流程。

做法是請職員把搜尋過程中查過的那些帳本頁面與索引本資料全部交回來，兩人自己再核對一次。

核對要有意義，前提是職員交回來的資料可信，於是浮現一個明顯的問題：假扮職員的 Mallory 若對記錄內容說謊怎麼辦？舉例來說，Mallory 可以私下另外維護一本帳本，裡面把 Alice 的地址記錯，或者對帳本的同一頁發行兩個不同版本的索引本。Mallory 可以把其中一套資料給 Alice，另一套給 Bob，讓兩人各自驗證手上的資料，卻察覺不到 Mallory 的把戲。

Alice 與 Bob 需要一位獨立的見證者，讓職員不敢造假。

第三方稽核者¶

要阻止 Mallory 給 Alice 與 Bob 不同的資料，兩人需仰賴第三方稽核者。稽核者的角色像公證人，在職員一頁一頁往帳本加、一版一版發行對應索引本的時候，就站在旁邊盯著看。

稽核者會檢查每一版索引本是否與前一版包含完全相同的資料，只差在多出的那一筆，以及職員沒有移除或偷偷改動帳本裡先前的任何一頁⁴。條件都成立時，稽核者就替該頁帳本與該版索引本簽名³，表示記錄新增正確。

稽核者對每一頁與每一本索引本只會簽名一次，所以職員若想把第 50 版索引本的不同版本分別展示給 Alice 與 Bob，只有其中一個版本拿得出有效的稽核者簽名。透過檢查與驗證稽核者簽名，Alice 與 Bob 可以確信職員只維護一本帳本與一套對應的索引本，兩人看到的是同一批記錄。

在 Signal 的金鑰透明度實作中，由 Cloudflare 與 Trail of Bits 擔任受信任的第三方稽核者。

監測¶

第三方稽核者確保職員給 Alice 與 Bob 的是同一批資料，卻無法驗證記錄內容本身正確。舉例來說，Mallory 可以試著往帳本加一頁，列上一筆假造的 Alice 地址變更。從稽核者的角度看，只要 Mallory 正確地新增帳本頁面、也發行了新版索引本，就算一次合法的變更。可是 Bob 到帳本查 Alice 地址的時候，會找到那筆假記錄，並且相信它是 Alice 的真實地址。

監測的作用就在補上這一塊，回想客戶跟帳本互動有兩種方式，查別人的地址，以及查自己的地址。監測要求 Alice 與 Bob 定期做這兩件事，各自能偵測到一種不同的竄改。

Alice 監測自己在帳本裡的資料，做法是定期查閱並驗證自己最新的地址記錄。若查到預期外的地址，她應該透過另一條可信管道通知 Bob，說他收到的地址不可信。

Bob 也必須定期查 Alice 最新的地址，確認與先前收到的一致。之所以重要，是因為 Mallory 塞進一筆假的地址變更之後，可能再補一筆把 Alice 的正確地址還原，藉此掩蓋痕跡。

從 Bob 的角度，查到 Alice 換了地址跟一次合法的搬家看起來一模一樣，而合法搬家是常見得多的解釋。即使如此，他仍然應該透過第二條管道向 Alice 確認她真的搬家了。若沒有，先前那個地址就應當成不可信。

Alice 按固定節奏做自我檢查，Bob 依自己的步調查帳本，兩人都無法保證在 Mallory 介入的當下就抓到。但兩種監測加上第三方稽核，構成一套完整的偵測機制：稽核保證 Alice 與 Bob 看到的是同一份資料，監測保證兩人都定期檢查資料的正確性。合起來，Mallory 的竄改終究會被發現。

回到 Signal 本身¶

那麼，以上種種跟 Signal 的金鑰透明度如何對應？

在 Signal 裡，你可以選擇讓別人用電話號碼找到你，也可以建立使用者名稱，讓別人用名稱找到你。決定開放電話號碼或使用者名稱之後，別人就能在 Signal 輸入你的號碼或名稱，發起訊息邀請。Signal 保有一份中央目錄，最終把這些公開識別碼對應到使用者的公開金鑰，就像信箱比喻裡的「姓名」與「地址」。

Signal 使用者註冊、變更電話號碼或使用者名稱、重新建立帳號時，Signal 會把變更記在一棵日誌樹（也就是「帳本」）裡，並用前綴樹（也就是「索引本」）協助在日誌樹中搜尋。Cloudflare 與 Trail of Bits 各自擔任兩種樹的獨立稽核者，兩種樹合起來構成金鑰透明度日誌。

日誌裡所有的使用者資料都經過密碼學處理而無法辨識，公開識別碼會先通過可驗證隨機函數，識別碼對應到的值則由帶金鑰的雜湊函數保護，因此稽核者從來看不到任何明文的使用者資料。

你的 Signal App 會自動、定期檢查日誌裡屬於你自己的公開識別碼，要驗證聯絡人的識別碼則必須從「檢視安全碼」畫面發起。所有向日誌查詢識別碼的請求都不帶身分驗證，因此不會跟特定使用者帳號綁在一起。

本文不深入實作細節，有興趣的讀者可以到我們的開源儲存庫查看。實作依據的是 IETF 金鑰透明度協定的早期草案，並針對 Signal 的使用情境做了調整。

金鑰透明度目前的實際樣貌¶

金鑰透明度顯示，Signal 生態系裡所有裝置對「識別碼與其公開加密金鑰的對應關係」抱持同一份視角。它不驗證掌控某個電話號碼或使用者名稱的人究竟是誰。具體來說，Alice 與 Bob 可以透過金鑰透明度檢查，確保各自持有某個帳號正確的公開金鑰，若 Mallory 已經完全接管 Alice 的帳號，要察覺仍需仰賴額外的驗證，例如在安全碼變動後主動追問。

目前你的 Signal App 會自動驗證日誌裡屬於你自己的電話號碼與使用者名稱資料。要替別人做同樣的驗證，你必須有對方的電話號碼。也就是說，你若是透過使用者名稱在 Signal 上與某人建立聯繫，彼此沒有交換電話號碼，也無從得知對方的號碼，就無法驗證對方。

符合以下任一條件，你手上大概就有 Signal 聯絡人的電話號碼：

你當初是用「以電話號碼尋找」的選項，在 Signal 上開啟與對方的對話。
你的手機通訊錄裡存有對方的聯絡資訊（而且對方在 Signal 選擇開放以電話號碼被找到）。
對方選擇了讓所有人都能看到自己電話號碼的設定（預設是沒有人看得到）。

請記得，只有在對方存在你的手機通訊錄裡，或對方把電話號碼的能見度設成所有人時，Signal 才會在 App 內顯示對方的電話號碼。

另一種情況是你手上的電話號碼過期了，因為 Signal 上的聯絡人換了號碼。換號碼對聯絡人的公開加密金鑰與底層的加密訊息工作階段沒有任何安全影響，卻會讓你無法對該位聯絡人使用自動金鑰驗證，原因是你手機裡留著對方的舊號碼，與帳本中最新的電話號碼記錄對不上。情況類似監測那一節提到的，Bob 查到的 Alice 地址與先前收到的不同。極可能是一次合法的變更，你的裝置卻分辨不出它與伺服器干擾的差別，所以你應該透過另一條可信管道向聯絡人確認。

基於隱私優先的預設，上述情況我們一律讓自動金鑰驗證無法使用，並建議使用者改用既有的安全碼機制，透過掃描 QR code 或比對一長串驗證號碼，手動確認自己與特定聯絡人持有同一組加密金鑰。使用者若傾向不依賴任何第三方，包含 Signal 與稽核者在內，可以依序打開設定的「隱私權」、「進階」、「自動金鑰驗證」關閉功能，繼續使用手動的安全碼驗證。

結語¶

金鑰透明度提供一種容易上手的方式，讓使用者確認訊息安全中重要的一環，補足既有的安全碼機制。

這項工作集合了 Signal 內部與外部的大量協作，我們特別感謝 Cloudflare 與 Trail of Bits 擔任獨立稽核者。感謝他們，也感謝生態系裡許多讓工作得以成真的人。

編輯註解¶

以下為 anoni.net 社群補充，非 Signal 原文內容

原文的比喻寫得完整，技術脈絡與取捨留在文外。以下先給三條結論，接著十三則補充，再一節發布後的後續補充，最後是常見問題與延伸閱讀。

只想知道結論的話¶

以下三條不需要理解背後的機制，轉述給沒有技術背景的人也不會失真：

綠色勾號代表號碼對應到的金鑰在整個 Signal 生態系裡一致，代表不了對方是本人。
收到「安全碼已變更」的通知就停下來，換一條管道確認過再繼續談敏感的事。
每隔一段時間打開設定裡的「已連結裝置」，看清單上有沒有你不認得的項目。

日常使用看完上面三條，再看接下來四則就夠。需要保護消息來源、在組織裡管對外帳號、經常跨境或裝置可能離開視線、加害者可能就在身邊的讀者，往後幾則是為你們寫的。最後三則談金鑰透明度怎麼設計出來，不影響操作。發布之後另外補了一節，談稽核鏈的形狀、勾號會被讀成什麼、匿名查詢的雙向性，以及可驗證性到哪裡為止。

綠色勾號保證什麼，不保證什麼¶

原文在「金鑰透明度目前的實際樣貌」一節已經劃出界線，換個說法再說明一次會更清楚。自動金鑰驗證只確認一件事，同一個識別碼在整個生態系裡對應到同一把金鑰。握著那個電話號碼或使用者名稱的人究竟是誰，功能本身管不到。

常見的幾個問題逐項對照。

你想確認的事	自動金鑰驗證	該看哪裡
伺服器有沒有偷換某個號碼對應的金鑰	可以	綠色勾號
對方是不是本人	不行	安全碼變動通知，另一條管道追問
有沒有陌生裝置掛在你的帳號上	不行	設定裡的「已連結裝置」
群組成員的金鑰有沒有被換過	不行	對每個人各做一次一對一驗證
手機本身有沒有被動過手腳	不行	屬於裝置安全，不在功能範圍
門號的控制權在誰手上	不行	註冊鎖 PIN，必要時撥 `113`

帳號被接管的情境下，界線會變得很尖銳。攻擊者若攔截到簡訊驗證碼、完成 SIM 卡調包，或取得對方已解鎖的手機，可以用同一個電話號碼重新註冊 Signal。重新註冊會產生新的身分金鑰，而新金鑰由伺服器循正常流程寫進日誌，算一次合法變更，稽核者不會有意見，日誌前後也一致。此時你對那位聯絡人執行自動驗證，畫面仍會顯示綠色勾號與「已完成加密驗證」，只是驗證通過的對象已經換人。

對方的身分金鑰改變時，Signal 會在對話中以安全碼變動通知標示出來，真正的警訊留在那一條。自動金鑰驗證不取代安全碼變動通知，兩件事回答不同的問題。

只作用在一對一，群組沒有自動驗證的入口¶

原文的操作說明是進入某位聯絡人的個人資料頁，Signal 設定裡的說明寫得更直接：「啟用時，Signal 會嘗試自動驗證 1 對 1 聊天的加密。」群組聊天沒有對應的入口。

限制來自金鑰透明度的設計，日誌記錄一個識別碼對應到哪一把金鑰，而群組不是一個識別碼，它是一群各自持有金鑰的人。要確認一個二十人群組裡每個人的金鑰都沒被換過，等於對二十個人各做一次一對一驗證，每一次都需要你握有對方的電話號碼。

把 Signal 群組當成協作骨幹的社群，務實的做法是分層。核心決策的少數幾人值得逐一驗證，人數多、流動快的執行層改用社會性的確認，由信任的人親自介紹、當面拉進群組。站上的社運行動者的數位準備有更完整的分層設計。

查證來源（2026-08）：values-zh-rTW/strings.xml - Signal-Android，字串 preferences_automatic_key_verification_body。

連結裝置是它看不到的地方¶

Signal 的連結裝置（linked device），也就是桌面版與 iPad 版，與手機共用同一把身分金鑰。攻擊者若誘使你掃過一次惡意的連結 QR code，他的裝置會掛進你的帳號、同步收到後續訊息，而你的身分金鑰完全沒有改變。安全碼不變，日誌裡不會多出任何一頁，金鑰透明度從頭到尾看不到，綠色勾號會一直亮著。

2025 年 2 月 Google Threat Intelligence Group 記錄了實際的攻擊。針對烏克蘭軍方人員、政治人物與記者的攻擊者，把裝置連結用的 QR code 偽裝成 Signal 群組邀請頁面，或烏克蘭軍方使用的應用程式頁面，誘導目標把攻擊者的裝置連上自己的 Signal 帳號。報告的說法是，攻擊成功之後訊息會即時同步給受害者與攻擊者雙方，形成持續竊聽的管道，過程中不需要完整攻陷裝置。

對應的操作是定期打開設定裡的「已連結裝置」，確認清單上每一項你都認得。金鑰透明度不會替你看已連結裝置。至於要不要解除不認得的連結、什麼時候解除，在加害者可能就在身邊的情況下需要先想過後果，後面「對方就在你身邊時」那一則會談到。

查證來源（2026-08）：Provisioning.proto - Signal-Android，ProvisionMessage 帶有 aciIdentityKeyPrivate，連結新裝置時主裝置會交出帳號的身分私鑰。
查證來源（2026-08）：Signals of Trouble: Multiple Russia-Aligned Threat Actors Actively Targeting Signal Messenger - Google Threat Intelligence Group，2025-02-20。

在台灣與周邊的脈絡¶

台灣的手機門號採實名制，號碼與身分證件綁在一起，補辦 SIM 卡並同時取得簡訊驗證碼的攻擊路徑比想像中短。帳號被完整接管時自動金鑰驗證會照常顯示綠色勾號，所以更該優先打開 Signal 的註冊鎖，設一組只有你知道的 PIN 碼，讓別人光有門號無法重新註冊你的帳號。註冊鎖的優先順序排在逐一驗證聯絡人之前。整體的防護順序見站上的一般人平常該做到什麼，自動金鑰驗證算是錦上添花的一層，密碼管理器與兩步驟驗證仍然排在更前面。

在 Signal 被封鎖的地區，第一個問題是功能能不能用。金鑰透明度的查詢跟其他 Signal 功能一樣需要連得上 Signal 的伺服器，連線被擋住或不穩定的時候查詢完成不了，驗證就不會成功。Signal 沒有說明「連不上」與「驗證失敗」在畫面上如何區分，可行的判斷方式是先看整個 App 收發訊息正不正常，正常的話問題比較可能出在驗證本身。查詢不帶身分驗證，日誌看不出是誰在查，走代理或審查規避工具時，通道的營運者仍然看得到你在跟 Signal 通訊，各種通道把可見度換到誰手上，見站上的VPN 的風險與選擇。

原文提到你手上留著聯絡人的舊號碼時，自動金鑰驗證會直接無法使用，反過來，你換了號碼之後，聯絡人的通訊錄裡留著你的舊號碼，他們同樣驗證不了你，影響往兩個方向都成立。跨境移動、常換預付卡或 eSIM 的人，兩個方向都會頻繁遇到，算是常態。退路仍然是安全碼，當面掃 QR code 最快，只能透過語音核對那串數字時，前提是你認得對方的聲音。維持多組門號與多個帳號的人，每個帳號的自我檢查各自獨立，站上的怎麼維持多個網路身分談到相關的取捨。

竄改終究會被發現，但不會當場被擋下¶

原文的監測一節寫得含蓄，金鑰透明度能偵測竄改，沒有即時阻擋的能力。Mallory 在帳本裡塞一筆假記錄的當下，Bob 的查詢仍然會取得假金鑰，訊息仍然會被讀走。真正的保障來自 Alice 下一次自我檢查時會發現對不上，而稽核者的簽名讓 Mallory 無法對 Alice 與 Bob 各說一套。攻擊窗口因此落在「從竄改到下一次監測之間」，代價則是必然留下可稽核的證據。對長期監控來說，會留下證據往往就足以嚇阻。

你打開自動驗證之前送出的內容，期間若發生過金鑰置換，那些內容已經走在錯的通道上，功能不會回頭修補，保護的方向只有往後。發現異常之後只能評估損害範圍，判斷哪些內容可能已經外流，以及對方是否還是本人在操作。

你的 App 自己檢查，驗證聯絡人要手動¶

原文提到你的 Signal App 會自動、定期檢查日誌裡屬於你自己的電話號碼與使用者名稱，驗證聯絡人的識別碼則必須從「檢視安全碼」畫面手動發起。兩件事的節奏差很多。

原文寫「隨著時間累積，你這一次的驗證，加上聯絡人與第三方稽核者持續執行的驗證，共同確保該位聯絡人的金鑰在整個 Signal 生態系中保持一致」，容易被讀成關係要夠久才有保障。拆開來看，稽核者稽核整份日誌，跟你們認識多久無關。你與對方各自的自我檢查綁在自己的帳號上，也跟關係新舊無關。只有「你對某位聯絡人的驗證」是一次性動作，而它按下去當場就生效。

臨時組成的團隊因此不必擔心用不上，第一次見面交換到電話號碼就能驗，比安全碼更適合陌生人快速建立聯繫，因為不需要另約時間。限制在別的地方，那一次驗證只反映按下按鈕那一刻的狀態，不會自動延伸。任務型的使用者若只在組隊當天驗過，等於把確認鎖在風險最低的階段，真正高風險的那幾天沒有覆蓋到。做法是至少驗兩次，組隊時一次，高風險窗口開始前再一次。

日常的使用者可以把節奏改成事件驅動，收到安全碼變動通知、對方換手機或換號碼、對話內容出現反常的時候，回去看一眼。

要驗證別人，需先有對方的電話號碼¶

對匿名網路社群的讀者而言，電話號碼的要求是最需要留意的取捨。Signal 過去幾年一直在降低電話號碼的角色，使用者名稱、預設不公開號碼都朝同一個方向走。自動金鑰驗證目前的設計卻要求你握有對方的電話號碼才能驗證對方，於是最在意隱私、只用使用者名稱交換聯繫方式的那群人，恰好是暫時用不到新功能的一群。

站上的記者保護消息來源與匿名通訊工具比較都建議用使用者名稱交換聯繫方式，讓消息來源不必先交出電話號碼。照站上的建議建立起來的關係，記者手上通常沒有對方的號碼，自動金鑰驗證從一開始就用不上。取捨很明確，來源的身分保護排在前面，驗證的便利性往後排。

功能也製造了一個誘因，讓人為了讓那顆勾號出現，反過來去跟聯絡人要電話號碼，屬於要特別避免的誤用。對方選擇只給使用者名稱，通常正是不想留下號碼，為了驗證去追問，等於把功能的便利性凌駕在對方自己的選擇之上。驗不了就接受驗不了，高風險的個案改走當面或另一條管道核對安全碼。倡議組織面對捐款人與服務對象時尤其要守住，脈絡見站上的倡議組織的匿名捐款管道。

原文的敘事是 Bob 去驗證 Alice，實際的信任鏈常常反過來。公開身分的人，例如記者、組織的對外窗口，被鎖定的機率比多數聯絡人高，而看著綠色勾號決定要不要信任的，是來找你的那一方。你自己的帳號沒有守好，所有信任那顆勾號的人會一起被誤導。註冊鎖與已連結裝置的檢查，優先順序排在逐一驗證每個聯絡人之前。

Signal 遇到限制時直接讓功能不可用，選擇是對的，寧可讓按鈕消失，也不要給出一個看起來成功、實際上沒有意義的綠色勾號。純使用者名稱的聯絡人目前仍請沿用安全碼，掃 QR code 那條路一直都在。只是當面核對本身也有代價，被看到跟某個人有聯繫，對還沒出櫃的伴侶或需要保護的消息來源就是一次額外的曝光。當面核對留給真正需要的時刻，例如收到安全碼變動通知之後，不必變成常態。

帳號背後換了人，金鑰不會變¶

金鑰透明度綁定識別碼與金鑰的對應，不綁定識別碼背後是哪一個人。前面談帳號接管時，落差表現成攻擊，在組織裡則是日常運作的一部分。

對外窗口、客服、專案聯絡人等角色帳號，操作的人會換。交接若做得規矩，沿用同一台裝置，或用註冊鎖的 PIN 重新註冊，金鑰完全不會變動，安全碼也不會變。一年前驗證過那個帳號的人，不會收到任何技術訊號告訴他們操作的人換了。金鑰透明度本來就沒有要回答帳號背後是誰在操作的問題。

角色帳號還有兩件事跟個人帳號不同。第一，「已連結裝置清單上每一項你都認得」那條建議假定只有一個人在管帳號，多人輪值時要改成比對一份內部名冊，靠記憶不可行。第二，組織門號的簡訊驗證碼可能不只一個人收得到，辦公室轉接線、IT 管理的 eSIM、帳單持有人都可能在鏈上，註冊鎖的 PIN 要當成組織的共用機敏憑證管理，存放與輪替的做法見站上的密碼管理器入門。

交接時要做的是換掉 PIN、盤點並清理已連結裝置、記錄目前誰握有管理權。若交接的情況不歡而散，處理順序比照後面「對方就在你身邊時」那一則。

裝置離開你的視線之後¶

出入境查驗、臨檢、裝置被扣留一段時間再歸還，三種情況有一個共同點，對手有過實體接觸的機會。金鑰透明度查伺服器上的紀錄，與你的裝置有沒有被動過是兩件獨立的事，所以自動驗證仍然會顯示綠色勾號。

拿回裝置之後要主動檢查已連結裝置清單，以及重要聯絡人的安全碼有沒有變動。清單乾淨只說明沒有新的裝置掛進你的帳號，不足以推論裝置本身沒被動過手腳，那屬於裝置安全的範圍。

被要求當場解鎖交出，風險又高一層，對手取得你配合之下的完整存取。保守的做法是把裝置視為已暴露，重新評估帳號的 PIN 碼與重要聯絡人的驗證狀態。事前準備與事後處理的清單，站上的出差與研討會的數位準備（東亞與東南亞）與社運行動者的數位準備寫得比較完整。任務型的通訊還要處理收尾，任務用的門號註銷之前提醒還留著號碼的人清掉，借用的裝置歸還之前先手動解除連結，別假設對方會自己發現，選務場景的整體準備見選舉觀察員的自保。

對方就在你身邊時¶

前面幾則假定的攻擊者都在遠端，需要攔截簡訊驗證碼，或誘你掃一張惡意的 QR code。加害者若是同住的人、知道你的解鎖方式，或本來就是門號的登記人與帳單付款人，連前置動作都不必，因為對方看到的是你本人已經解開的畫面，前面所有機制都繞不過去。

門號那一層要分開看，註冊鎖擋得住「用你的號碼重新註冊 Signal」，擋不住對方對門號本身的行政控制權。對方若是合法的門號持有人，走電信商的正常管道就能處理你的號碼，過程中不需要偽造任何身分。設 PIN 碼的時候也要留意，只有在對方不在場、不知情的狀況下設定才有意義，並且不要與手機解鎖碼相同。未成年而使用家庭方案的人還要多想一層，門號、帳單與裝置管理往往在同一個人手上，設好 PIN 擋得住重新註冊，擋不住對方看到你裝了什麼 App，裝置層的痕跡管理見站上的 LGBTQ+ 與性少數的匿名社交。

檢查連結裝置的建議，在同住的情境下要先想過後果。前面說看到不認得的項目就解除連結，那條建議假定對手是陌生人，解除之後不會再出現。加害者是同住者的時候前提不成立，被解除的那台裝置會立刻失去存取權，對方下次打開就會發現，而「你發現了」本身可能升高風險。比較安全的順序是先確認人身安全與手邊可用的支持資源，需要時先保留畫面記錄，再決定要不要解除、什麼時候解除。

原文反覆建議的「透過另一條可信管道確認」也有同樣的前提問題，長期被監控的人不一定有一條對方接觸不到的管道。台灣可以撥 113 保護專線做匿名諮詢，由社工協助判斷風險等級。更完整的準備見站上的家暴受害者的數位準備與緊急求救。

稽核者本身也是一種信任¶

功能引進了兩個新的外部角色，Cloudflare 與 Trail of Bits。兩家都無法讀到明文資料，公開識別碼經過可驗證隨機函數處理，對應值由帶金鑰的雜湊函數保護。稽核者能確認日誌前後一致、沒有被回頭改寫，看不到日誌裡究竟是誰。

多一位獨立稽核者通常讓信任假設變弱，從「必須相信 Signal 沒有作惡」放寬成「至少要有一位稽核者是誠實的」，方向要說清楚。用戶端實際要求三份簽章，Signal 自己營運一份，Cloudflare 與 Trail of Bits 各一份，缺任何一份都會跳警告、讓自動金鑰驗證失敗。每份簽章有七天效期，全惡意的伺服器因此最多維持一週的分岔視圖。原文只寫了 Cloudflare 與 Trail of Bits 兩家，第三份自簽要看 Trail of Bits 自己的說明才知道，後面「後續補充」那一節接著談。

完全不接受第三方假設的使用者，Signal 留了關閉開關，設定路徑在隱私權、進階、自動金鑰驗證。關閉之後回到手動的安全碼驗證。

為什麼識別碼要先過一層可驗證隨機函數¶

原文提到公開識別碼會先通過可驗證隨機函數（Verifiable Random Function），一句話帶過，背後的取捨可以再說明。

日誌必須公開才有辦法被稽核，公開的日誌若直接列出電話號碼，任何人都可以整份取回，做成一份「哪些號碼註冊過 Signal」的名單。換成一般的雜湊函數也擋不住，電話號碼的可能組合數量太少，逐一算過一遍就能還原。

可驗證隨機函數讓伺服器用一把只有自己知道的金鑰，把識別碼映射到日誌裡一個看起來隨機的位置，同時附上一份任何人都能檢查的證明，說明映射確實照規則產生。外人少了那把金鑰就無法自行還原名單，稽核者仍然驗證得了日誌的一致性。

「不帶身分驗證」的意思也要看清楚。原文說所有向日誌查詢識別碼的請求都不帶身分驗證，因此不會跟特定使用者帳號綁在一起。不帶身分驗證只保證查詢不會被綁到你的帳號，不保證伺服器不知道你查了誰。可驗證隨機函數的金鑰在伺服器手上，你要查某個識別碼，就得把它送過去讓伺服器算出對應的位置與證明，被查的識別碼本身伺服器看得到，稽核者讀不到明文則是另一層設計。

金鑰透明度不是 Signal 首創¶

概念上金鑰透明度延伸自憑證透明度（Certificate Transparency），把 HTTPS 憑證的公開日誌與稽核機制搬到即時通訊的公開金鑰上。學術脈絡可以再往前拉，2015 年的 CONIKS 提出讓使用者自行監測目錄的設計，2019 年的 SEEMless 補上隱私與效率，Meta 在 2021 年把相關想法做成開源的 Auditable Key Directory（AKD）程式庫。

通訊軟體的第一個大規模部署來自 WhatsApp，2023 年 4 月上線，底層用的就是 AKD，當時的定位是讓任何人都能自行驗證。Cloudflare 接手擔任第三方稽核者，是一年五個月之後的 2024 年 9 月，兩件事常被壓成同一件。Apple 的 iMessage Contact Key Verification 在 2023 年底推出，走另一條路線，由使用者裝置自己驗證一致性證明。

IETF 的 KeyTrans 架構草案把部署方式分成三種模式，聯絡人監測（contact monitoring）、第三方管理（third-party management）與第三方稽核（third-party auditing），差別在於由誰負責察覺日誌分岔。草案本身只定義模式，沒有點名哪一家系統落在哪一格，常見的對照表出自工作組簡報與各家自己的說明。Signal 這次以第三方稽核為主，同時要求用戶端對自己的識別碼做監測，互補的理由在原文的「監測」一節說得很清楚。

查證來源（2026-08）：CONIKS: Bringing Key Transparency to End Users - USENIX Security 2015。
查證來源（2026-08）：SEEMless: Secure End-to-End Encrypted Messaging with less trust - Chase、Deshpande、Ghosh、Malvai，ACM CCS 2019。
查證來源（2026-08）：Deploying key transparency at WhatsApp - Meta Engineering，2023-04-13。AKD 程式庫見 facebook/akd，儲存庫 2021 年 6 月建立。
查證來源（2026-08）：Cloudflare helps verify the security of end-to-end encrypted messages by auditing key transparency for WhatsApp - Cloudflare，2024-09-24。
查證來源（2026-08）：Advancing iMessage security: iMessage Contact Key Verification - Apple Security Research，2023-10-27。

後續補充（2026-08-13）¶

文章發布當天，Trail of Bits 也貼出自己那一側的說明，裡面有 Signal 原文沒寫的稽核細節。以下四則按幾位不同專業背景的讀者的提問整理，查證日期都在 2026-08。

稽核的獨立性建立在跨組織，不在跨法律管轄¶

用戶端要求的三份簽章，分別由 Signal、Cloudflare 與 Trail of Bits 營運，三家都是美國實體。跨組織的分散做到了，跨法律管轄沒有。一份強制令同時觸及三個簽章者，在美國境內是可以想像的路徑，對身處與美國沒有對等司法互助機制地區的使用者，保證的實際強度目前沒有先例可查。

Trail of Bits 照規格從頭寫了一套稽核器，沒有沿用 Signal 的參考實作，理由是獨立實作才抓得到共病的錯誤，程式碼開源在 trailofbits/signal-auditor。他們也寫明不向 Signal 或任何一方收費，兩項選擇讓第三方稽核不只是掛名。

現行設計把察覺日誌分岔的責任交給少數幾個稽核者，學界對此有意見。2026 年的 MINGLE 提出讓用戶端在通訊時順便交換彼此看到的日誌狀態，論文摘要直接點名現行部署把偵測委託給少數第三方稽核者，形成可被施壓、被攻陷或無法持續稽核的中心化瓶頸。Signal 目前沒有用戶端之間的交叉比對。

綠色勾號會被讀成什麼，空白又會被讀成什麼¶

安全指示器的既有研究顯示，正面圖示長期被讀得比技術定義寬。工程團隊寫的是「識別碼與金鑰在日誌裡一致」，使用者看到的是「這個人安全」。

2007 年一項針對網路銀行的研究把使用者原本設定的個人化安全圖片拿掉，用自己帳號操作的二十五人裡有二十三人仍然輸入了密碼。預期中的正面提示消失，多數人不會提高警覺，多半根本沒注意到。

自動金鑰驗證因為對方只有使用者名稱或號碼過期而不可用時，比較可能發生的是使用者直接略過。空白不會自己變成警訊。

自動化研究反覆觀察到，手邊有低成本管道可以依賴時，需要主動投入的人工檢查會系統性減少。驗證變便宜之後，願意約時間當面掃 QR code 的人只會愈來愈少，而當面核對正好涵蓋自動驗證覆蓋不到的那一塊，帳號被完整接管的情境。

匿名查詢的保護是雙向的¶

查詢日誌的請求不帶身分驗證，設計目的是讓伺服器無法把查詢綁回你的帳號。同一個設計讓查詢你的人也享有一樣的匿名。只要對方原本就知道你的電話號碼，就能反覆查詢你的識別碼在日誌裡的紀錄，觀察你何時換機、換號或重新註冊。過程不必碰你的裝置，你也不會收到任何通知，原文沒有描述任何會告知被查詢者的機制。

前面「對方就在你身邊時」那一則要再加一層：離開一段有控制關係的關係之後，對方手上通常還留著你的號碼。換號碼本身會在日誌裡留下一筆可被觀察的變更，時間點對盯著看的人是有意義的訊號。

可驗證性到你的手機就斷了¶

稽核者簽的是伺服器上那份日誌的結構，簽章不涵蓋你手機裡的 App 有沒有誠實執行驗證、畫面上那顆勾號有沒有如實反映結果。那是另一條信任鏈。要核對手上的 App 與公開原始碼一致，Android 版有可重現建置的流程與自動化檢查，社群也有人持續重現 Play Store 的版本。iOS 版沒有對應的建置說明，限制來自 App Store 的簽署流程。

Cloudflare 在 2024 年為 WhatsApp 的稽核做了一套任何人都能執行的複驗工具，目前收錄的仍是 WhatsApp 那組，沒有 Signal 的對應項目。想自己複驗 Signal 稽核結果的研究者，現階段需要從頭做起。

查證來源（2026-08）：How Trail of Bits helps verify the integrity of your Signal chats - Trail of Bits，2026-08-11。三份簽章、七天效期、稽核器開源與不收費均出自此文。
查證來源（2026-08）：Signal and Ready to MINGLE: In-Band Gossip for Key Transparency Split-View Detection in E2EE Messengers - IACR ePrint 2026/1010。
查證來源（2026-08）：The Emperor's New Security Indicators - Schechter、Dhamija、Ozment、Fischer，IEEE Symposium on Security and Privacy 2007，論文摘要記為 25 人中 23 人。
查證來源（2026-08）：trailofbits/signal-auditor 與 cloudflare/plexi，後者的說明文件目前只列 WhatsApp 的 namespace。
查證來源（2026-08）：Signal-Android 的 reproducible-builds 說明，Signal-iOS 儲存庫無對應目錄。

後續補充（2026-09-09）¶

文章發布之後將近一個月，德國出現同一條路徑的公開紀錄，行為者跟前面舉的例子不同。以下三則的查證日期都在 2026-09。

連結裝置已經是刑事偵查的常態工具¶

前面「連結裝置是它看不到的地方」舉的是國家級情報行為者的例子，容易讀成只有高價值目標才需要在意。2026 年 9 月 2 日 netzpolitik.org 公開的德國海關刑事局內部處分把行為者的範圍拉寬了。文件裡寫著該局自 2023 年底試辦訊息軟體監控（Messengerüberwachung），2025 年 8 月 1 日轉入正式編制，成為偵辦組織犯罪的常態工具，做法同樣是替目標帳號連上一台自己的裝置，不需要植入木馬。

更早的兩個案例有裁定書可查。2020 年 1 月德國聯邦刑事警察局趁一對父母以證人身分自願交出手機的機會，暗中啟用了 WhatsApp Web。2022 年 3 月警方接上一名嫌疑人的 Telegram 帳號，在對方數小時後切斷之前備份了約四個月的既往對話。

法院劃出的界線落在連結裝置做不到的地方¶

德國聯邦最高法院在 2026 年 1 月 20 日認定，暗中接上帳號屬於源頭電信監察（Quellen-Telekommunikationsüberwachung），可取得的內容以法院裁定時點之後產生的為限。回溯既往訊息超出授權，該案因此撤銷部分原判。

界線的技術意義在於業者的用戶端做不到。連結新裝置時既有的訊息封存會一併送過去，沒有只交出某個時間點之後那一段的選項，Signal 這一側的數字是最近 45 天。法律准許取得的範圍比功能一次交出的範圍窄，收斂差距的責任落在執行的人身上，軟體不提供對應的開關。

Signal 沒有對這則報導表態¶

查證時 Signal 官方部落格最新一篇仍是 8 月 11 日的自動金鑰驗證，Meredith Whittaker 的公開帳號沒有相關發言，德語圈的跟進報導也沒有引用任何通訊軟體業者的回應。原始報導只向德國海關刑事局與聯邦刑事警察局求證，兩邊都拒答，並未向業者提問。

讀者要做的事沒有改變，仍然是定期打開設定裡的「已連結裝置」核對清單。改變的是判斷相關性的門檻。過去可以說服自己不會是情報單位盯上的人，現在要問的是自己會不會出現在一般刑事偵查的關係人名單上，那是一個寬得多的範圍。

查證來源（2026-09）：Messenger-Überwachung: Immer mehr Polizei überwacht Messenger wie WhatsApp - netzpolitik.org，2026-09-02，內含德國海關刑事局 2026-02-20 內部處分全文。
查證來源（2026-09）：BGH, Beschluss vom 20. Januar 2026 – 3 StR 495/25，備份範圍為 2021-11-26 至 2022-03-30，原審為 Aurich 地方法院。
查證來源（2026-09）：BGH, Beschluss vom 9. Juli 2020 – 2 BGs 468/20，記載 2020-01-12 訊問經過，交出手機的兩人法律身分是證人。
查證來源（2026-09）：Gemeinsamer Sicherheitshinweis 01/2026: Phishing über Messengerdienste - 德國聯邦憲法保衛局與聯邦資訊安全局，2026-02-06，45 天的數字出自此文。
查證來源（2026-09）：Signal 官方部落格，查證時最新一篇為 2026-08-11。

常見問題¶

自動金鑰驗證要我自己去打開嗎

不用。原文的寫法是不想依賴任何第三方的人「可以在設定中關閉」，也就是預設就是開啟的。開關在隱私權、進階、自動金鑰驗證，是全域設定，不能逐一聯絡人控制。你自己識別碼的檢查由 App 在背景執行，不需要你操作。要驗證某位聯絡人則要自己進去按，位置在對方個人資料頁的「檢視安全碼」畫面。原文沒有提到最低版本需求，看不到按鈕時先更新 App 再看一次。

打開自動金鑰驗證之後，還需要核對安全碼嗎

看對象。日常聯絡人可以只靠自動驗證。面對高風險的對象，例如消息來源、律師、跨組織的敏感協作，當面掃 QR code 仍然是最強的一層，因為它不依賴 Signal 的伺服器，也不依賴任何稽核者。兩種做法可以並存，自動驗證負責日常的持續比對，手動核對負責一次性的高強度確認。

顯示綠色勾號，代表對方一定是本人嗎

不代表。綠色勾號說明你手上的識別碼對應到的金鑰，跟整個 Signal 生態系看到的一致。對方的帳號若已經被完整接管，攻擊者用同一個號碼重新註冊產生的新金鑰，同樣會通過驗證。判斷對方是不是本人，仍要靠安全碼變動通知、對話內容的異常，以及另一條可信管道的追問。

群組聊天裡的成員，可以用自動金鑰驗證嗎

不行。Signal 設定裡的說明寫著「自動驗證 1 對 1 聊天的加密」，群組沒有對應的入口。要確認群組成員的金鑰，只能對每個人各自執行一次一對一驗證，而且同樣需要你握有對方的電話號碼。人數多的群組不容易逐一做完，實務上建議只在核心的少數幾人身上落實。

自動驗證的按鈕沒有出現，是我操作錯誤嗎

多半不是操作問題。最常見的原因是你手上沒有對方的電話號碼，例如你們是透過使用者名稱建立聯繫的。另一種是你存的號碼過期了，對方已經換號。Signal 在兩種情況下一律讓功能不可用，改請你使用安全碼。

我驗證了某位聯絡人，對方會知道嗎

原文說所有向日誌查詢識別碼的請求都不帶身分驗證，不會跟特定使用者帳號綁在一起。保證的範圍到這裡為止，查詢不會被綁到你的帳號，連線來源與時序仍然握在伺服器手上，推不出伺服器完全無從關聯。原文也沒有描述任何會通知對方的機制，同樣沒有正面交代，處境對此特別敏感的人，保守假設比較安全。

我換了新號碼，為什麼舊聯絡人驗證不了我

因為對方的通訊錄裡留著你的舊號碼，與日誌中最新的號碼記錄對不上。限制是雙向的，你驗證不了持舊號碼的人，持你舊號碼的人也驗證不了你。做法是透過另一條可信管道告知新號碼，等對方更新通訊錄，或直接約時間掃 QR code 核對安全碼。

我們是臨時成軍的團隊，來得及用上嗎

來得及。原文那句「隨著時間累積」容易被讀成關係要夠久才有保障，但稽核者稽核整份日誌，你與對方的自我檢查各自綁在自己的帳號上，都跟你們認識多久無關。第一次見面交換到電話號碼就能驗，比安全碼更適合陌生人快速建立聯繫，因為不必另約時間。單次驗證只是當下的快照，高風險窗口開始前記得再驗一次。

時間有限，我該先驗證誰

用影響範圍排序。問自己「對方的帳號若被接管，錯誤資訊會擴散多遠、敏感內容會外流多少」。指揮與協調窗口優先於一般成員，會轉發現場回報的節點優先於只接收的人，跨組織的單一聯繫窗口優先於同組織內已有其他確認管道的人。排在所有人之前的仍然是你自己的帳號，理由見「要驗證別人，需先有對方的電話號碼」那一則。

手機被查扣過再拿回來，看得出發生了什麼事嗎

看不出來。只要沒有人用你的號碼重新註冊，身分金鑰沒換，畫面就會照常顯示綠色勾號。拿回裝置之後要主動檢查已連結裝置清單與重要聯絡人的安全碼變動。清單乾淨也只代表沒有新裝置掛進帳號，不代表裝置本身沒被動過手腳。

門號是對方申請的、帳單也是對方在繳，我還受保護嗎

功能保護不到那一層。自動金鑰驗證確認金鑰有沒有被換掉，管不到門號的行政控制權在誰手上。對方若是合法的門號持有人，走電信商的正常管道就能處理你的號碼。門號的歸屬要另外處理，必要時先聯繫 113 保護專線評估風險，站上的家暴受害者的數位準備有進一步的準備方向。

驗證聯絡人的時候，Signal 自己會不會知道我在查誰

原文說查詢不帶身分驗證，不會跟特定使用者帳號綁在一起，只保證查詢不會被綁到你的帳號。伺服器持有可驗證隨機函數的金鑰，你要查某個識別碼就得把它送過去，被查的識別碼本身伺服器看得到，稽核者讀不到明文則是另一層設計。

關掉自動金鑰驗證會有什麼影響

你會回到原本的手動安全碼流程，訊息加密本身不受影響。關閉的理由通常是不想把任何信任放在 Signal 以外的第三方稽核者身上。設定路徑在隱私權、進階、自動金鑰驗證。

Signal 的伺服器被入侵，我會收到通知嗎

不會有一則寫著「伺服器被入侵」的通知。你會看到安全碼變動的提示，或是自動驗證失敗。金鑰透明度的設計目標是讓竄改留下無法抹除的證據，做不到即時警報。發現的時間點落在你或對方下一次檢查的時候。

跟 WhatsApp、iMessage 的同類功能差在哪

三家處理同一個問題，選擇的信任結構不同。WhatsApp 走第三方稽核，由 Cloudflare 在外部盯著日誌。Apple 的 iMessage Contact Key Verification 讓使用者的裝置之間自行驗證一致性。Signal 兼採兩種做法，外部稽核加上用戶端對自己識別碼的定期監測。使用門檻上，Signal 只有在你握有對方電話號碼時才驗證得了對方，純使用者名稱的聯絡人暫時用不到，WhatsApp 的帳號本身就是電話號碼，不會遇到同樣的狀況。

我該多久檢查一次

沒有標準答案，可以用事件驅動取代固定週期。收到安全碼變動通知、對方換手機或換號碼、你自己重新安裝 Signal，以及任何一次感覺不對勁的對話，都是回去看一眼的時機。你自己的識別碼由 App 定期檢查，不需要你介入。

一段預告過的降速：8/13 用 OONI 記錄北部行動網路的 30 分鐘

anoni.net 社群 — Tue, 11 Aug 2026 00:00:00 +0000

一段預告過的降速：8/13 用 OONI 記錄北部行動網路的 30 分鐘¶

8 月 13 日週四 14:30 到 15:00，基隆、台北、新北、桃園、新竹市、新竹縣、宜蘭的行動網路會降速 30 分鐘。降速屬於「城鎮韌性演習」的一部分，由三大電信業者同時執行。官方公告寫明語音通話、簡訊與細胞廣播照常，影音串流、視訊通話、行動支付、雲端同步等高流量服務受影響¹。NCC 對演練時段的建議是預先為離線情境做準備²。

降速的幅度，官方對外說明過兩次。國防部長顧立雄 7 月 20 日在立法院說明是「降速到 4G、5G 的百分之一」，行政院則在 8 月 10 日中部場結束後補充做法：由電信業者透過核心網路限流，將行動網路下載速率調降至 256KB。兩個說法的量級一致，量測時可以此為預期落點。

日期、時段、七個縣市、三家業者，降速的每個邊界都在演練前公開。網路降速的研究少見如此明確的前提，多數案例由使用者先察覺變慢，研究者事後回推，時間邊界始終模糊。預告式的斷網在其他國家並非首見，例如考試期間的全國性斷網⁶。就公開可查的記錄而言，預告式的降速較為少見，並且能切分到各家業者的粒度。

8 月 10 日中部場的同一個時段，全台灣的 OONI 觀測裡沒有任何一筆來自行動網路的效能量測。北部場是今年演習的最後一場，8 月 13 日過後不會再有相同的條件。

若你身在這七個縣市，那半小時手機本來就會變慢。與其等它過去，不如順手留下一筆紀錄。

為什麼要演練行動網路降速，給不在台灣的讀者

行政院對演練的說明是「模擬極端情境，驗證政府在有限通訊環境下之應變能力」，設想的狀況包含天災、大規模網路攻擊與複合式災害，目標是提升整體通訊與社會防衛韌性¹。公告本身沒有提到戰時或軍事演習，框架放在民防與備援。行動網路降速是參考日本、韓國、北歐等國經驗後「首度加入」的項目¹，範圍限於台灣首度，不是國際首例。

對台灣來說，通訊中斷不是假設性的問題。台灣是島嶼，對外連線依賴海底電纜，數位發展部設有「海纜障礙狀況」的公開頁面，逐條列出故障位置、替代路由與預計修復時間⁷。以 2026 年 7 月 28 日的更新為例，當時有四條海纜處於故障狀態，最近的一筆發生在 7 月 14 日，預計修復日期落在 8 月 14 日，也就是演習的同一週。想看這些纜線的實際走向，可以開 Tor 中繼地球儀，上面標了 228 條海纜線段與台灣周邊的障礙狀態。

真實事故的規模比演練大得多。演練只降速 30 分鐘、限定十四個縣市、語音與簡訊照常。海纜中斷則可能持續數週，影響整個區域的對外連線。演練的用意在驗證備援機制與宣導準備，不是重現事故。

8 月 13 日要做的三件事¶

全部時間為台灣時間（UTC+8）。演練時段是 14:30 到 15:00。

開始之前，8 月 13 日前先完成¶

安裝 OONI Probe，App Store、Google Play 與 F-Droid 都可下載，開源免費。OONI 開發此工具的目的，是把網路封鎖與連線品質變成可驗證的公開資料，完整介紹見什麼是 OONI。首次啟動有一段設定流程，當天才安裝會來不及。裝好後先執行一次，確認能正常完成。

接著設一個 14:35 的鬧鐘，降速中的量測最重要。行有餘力再加上 14:15 與 15:10。下午開會時很容易忘記，設鬧鐘比記憶可靠。真的錯過也沒關係，補做 15:10 那一次就好，只有一筆一樣送得出去。

步驟一、關閉 Wi-Fi 與 VPN，改用行動數據¶

透過固網連線的 Wi-Fi 在演練中不受影響，量測若在固網的 Wi-Fi 上完成，結果等於零。手機常會自動回連辦公室或住家的 Wi-Fi，執行前請先確認已切到行動數據。手機分享出來的熱點雖然底層走行動網路，OONI 仍會把網路類型記成 Wi-Fi，一樣不要用。

VPN 與 Tailscale 都要先關閉。一般 VPN 會把流量繞出去，量測結果只反映 VPN 業者的線路，紀錄下來的 ASN 也會變成對方的。Tailscale 就算沒有啟用 exit node，在 iOS 與 Android 上仍是透過系統的 VPN 機制運作，OONI Probe 會把網路類型記成 vpn 而不是 mobile，量測資料就標不出是行動網路量到的。App 偵測到 VPN 時會跳出提醒，看到提醒請先關掉再執行。量測結束後記得把 Tailscale 開回來，靠它連公司內網的人特別容易忘記。

量測完成後可在結果頁看到網路名稱與 ASN（自治網路的全域編號，電信商、企業、學校都有各自的號碼），確認量測確實在行動網路上完成，名稱為自己的電信商。

先確認你的行動數據額度

效能組裡的連線速度測試（ndt）會量吞吐量，執行時盡量用滿當下可用的頻寬。App 在執行前就會標出預估值，畫面上寫的是 5 到 200 MB、約 1 分 30 秒，實際落點隨連線速度而定。降速中的量測因為頻寬被壓低，用量最小。14:15 與 15:10 都在正常速度下執行，都會落在估計值的高端。

非吃到飽的人建議做降速中的量測，再從 14:15 或 15:10 挑一次當對照，兩次就有比較的基礎。

步驟二、執行「效能」測試¶

開啟 App 後點「測試」，選「效能」，勾選要執行的測項，再按下執行。效能組包含 ndt（連線速度）與 dash（模擬影音串流，估算可達成的播放位元速率）兩個測項，正是量測降速所需，Android 與 iOS 都提供。

步驟三、至少在 14:35 到 14:55 之間做一次¶

最重要的是降速當下的量測。演練 14:30 開始、15:00 結束，前後各留五分鐘避開啟動與恢復的過渡，所以 14:35 到 14:55 之間開始都可以。ndt 約需 1 分 30 秒，最晚 14:55 開始還來得及在結束前完成。

只做一次也有價值，能跟其他參與者、跟隔日同時段互相參照。時間允許再加上前後兩次，同一支手機自己的前後對照最為明確。

台灣時間（UTC+8）	UTC	用途	優先序
`14:35` 到 `14:55`	`06:35` 到 `06:55`	降速中	一定要
`14:15`	`06:15`	降速前的對照點	有空就做
`15:10`	`07:10`	恢復後	有空就做

每次都要用同一支手機、同一個門號，並且都在行動網路上完成。位置能固定會讓資料更好比對，中途需要移動也不影響參與，只要確認沒有切回 Wi-Fi 即可。

行有餘力的話，8 月 12 日週三 14:35 也測一次。多一筆，隔日同時段的對照會強很多，成本一樣是按一下。

14:30 之後才看到本文的人

只要還在 14:55 之前就直接做一次，時間過了就補做 15:10。手上只有一筆也送得出去。

降速中上傳失敗屬於正常

量測結果需要上傳，而演練期間頻寬已被壓低，上傳可能延遲或失敗。不需要重複執行，OONI Probe 會把結果排入佇列，等網路恢復後自動補傳。

想多做一點的人，降速期間可另外執行含 Tor 與 Psiphon 的測試（英文介面為 Circumvention），能看出降速對規避工具的影響。規避工具那組會做封鎖判定，降速造成的連線失敗會被記成 anomaly，成因是頻寬而非審查，社群整理結果時會一併說明。

按下執行之前，該知道的隱私影響¶

一句話的版本：效能測試會把你當下的對外 IP 留在 M-Lab 的公開資料集，而行動網路的 IP 浮動、沒有帳號綁定，實務上難以對應到個人。不想留下紀錄的人，改執行網頁連線測試（web_connectivity，英文介面為 Websites）即可，它不經過 M-Lab。以下是完整說明。

先分清楚兩個資料庫。OONI 自己發布的量測結果全部公開，內容包含所處的 ASN 與時間戳記，不包含個人 IP 位址。效能組的 ndt 另外會把資料送到 M-Lab，那是另一個機構、另一份資料集，規則不同。

M-Lab 的隱私政策載明測試資料會對外公開，公開內容包含你的 IP 位址與日期時間，並且以長期研究為由無限期保留，公開資料集裡不做匿名化。政策提供的刪除途徑援引 GDPR 與 LGPD，主要對象是歐盟與巴西的資料主體。M-Lab 聲明政策原則上適用於所有地區的使用者，但條文沒有處理台灣這類第三地的請求資格，實務上能不能受理並不明確。App 的效能頁面本身也附了免責聲明，說明測試透過第三方伺服器進行，無法保證 IP 位址不被他人收集。

所以執行 ndt 等於把當下的對外 IP 位址寫進一份公開且長期保存的資料集。M-Lab 不認證使用者、不保存個人的測試歷史，行動網路的 IP 又多為浮動，第三方研究者或一般查詢者很難單獨從一個 IP 對應回特定個人。上面說的是 M-Lab 與 OONI 這一側的識別能力。你的電信業者本來就能從連線紀錄對應到門號與 IP，那份紀錄與量不量測無關，也不會因為參與而增加。是否留下紀錄，請自行斟酌。

中部場那 30 分鐘，行動網路一筆效能量測都沒有¶

8 月 10 日 14:30 到 15:00，同樣的降速在中部七縣市執行過一次（UTC 時間 06:30 到 07:00）。演練結束後，我們查詢 OONI 的公開資料庫，看台灣在該時段留下了什麼。

測項	該時段全台筆數	來源網路
`ndt`（連線速度）	1	`AS131584` 台灣智慧光網，固網
`dash`（串流位元速率）	1	同一個固網 ASN
`web_connectivity`（網站可達性）	803	幾乎全在固網，HiNet 佔 593 筆

中華電信行動的 AS17421 是 0 筆，遠傳的 AS9674 是 0 筆。

唯一的速度量測執行在固定光纖上，量測的網路並未降速。那 30 分鐘全台灣共有 902 筆 OONI 觀測，其中沒有任何一筆是行動網路上的效能量測。演習依南部、中部、外離島、東部、北部的順序分區實施，北部場是最後一場³，同樣條件的降速要再等到明年。

台灣的 OONI 觀測，四成來自 HiNet¶

中部場的結果反映了台灣 OONI 資料長期的分布。2026 年 7 月 12 日到 8 月 11 日之間，全台灣有 645,039 筆 web_connectivity 量測，分佈在 25 個 ASN：

網路	近 30 天筆數	佔比
`AS3462` HiNet	253,546	39.3%
`AS131584` 台灣智慧光網	191,257	29.7%
三家行動業者合計	23,010	3.6%
└ `AS24158` 台灣大哥大	20,099
└ `AS17421` 中華電信行動	2,342
└ `AS9674` 遠傳	569

剩下的也以固網為主，StarVerse 與 DaDa Broadband 各有數萬筆，另有輔仁大學、TANet 與台大幾個校園網路。

真正需要的效能測項，總量少得多。同一段期間全台灣只有 1,008 筆 ndt。行動端看起來佔了一半以上，548 筆，但其中 528 筆來自台灣大哥大一家，中華電信行動只有 16 筆、遠傳 4 筆。缺口集中在中華電信行動與遠傳。

要說明台灣的網路環境，目前可引用的資料主要反映家用固定寬頻的狀況。依 NCC 統計，2026 年第 1 季全台行動門號約 2,833 萬戶，多數人一天裡大半時間透過行動網路上網。

三家都是全國性業者，OONI 上的量測分布卻差了一到兩個數量級。效能測項裡台灣大哥大有 528 筆，中華電信行動只有 16 筆，差距顯然不是用戶規模造成的。

公開的 aggregation API 只提供量測筆數，不提供裝置數，所以上表無法排除少數幾台裝置反覆量測的可能。台灣大哥大同時經營行動與固網，中華電信也是，因此單看一筆 AS24158 的量測，判斷不出它來自手機還是家用數據機。

為什麼三家要一起測¶

上面那項辨識問題，正好說明為什麼要挑演練時段。演練已公告時段與縣市範圍，在該時段內、在公告範圍中，AS24158、AS17421、AS9674 出現的行動端量測有明確的情境可對應，ASN 至此才足以定位到業者。平常散在各處的量測缺少對應的情境。

同一時段只消除了「時間」一個變因。地點、基地台負載、手機型號、訊號強度都仍然存在。三十支手機散在七個縣市，得到的仍是一批條件互異的觀測點，結論只能停在粗粒度的判斷，例如三家是否都出現可觀察的吞吐下降、下降的量級是否接近。任何精確的業者排名都超出這批資料能支撐的範圍。

即使如此，三家同時面對同一道指令、同一個 30 分鐘，仍然是難得的對照時機。單獨一家測得再密，也只能得到那一家的曲線。

降速的 30 分鐘可以觀察到什麼¶

行政院說明的做法是核心網路限流加上固定的下載速率上限，屬於無差別的頻寬管制，ndt 應可量到。不過公告另外列的受影響服務類型（影音串流、視訊通話、行動支付、雲端同步）讀起來像依應用層分類，三家業者對受影響範圍的描述也各自不同。台灣大哥大把 LINE、WhatsApp、M+ 等通訊軟體列進會出現連線延遲與不穩定的範圍⁴，中華電信寫的是「影音、視訊連線、行動上網及部分物聯網應用」⁵，行政院的版本則是文字傳輸正常¹。限流若落在頻寬層，ndt 會直接反映。若偏向應用層分類，ndt 對 M-Lab 的流量特徵未必被歸進受限類別，可能量到接近平常的速度。量測結果本身就能分辨屬於哪一種，也是降速期間最值得觀察的一項。

頻寬被壓低時 Tor 與 Psiphon 能否建立連線，是社群長期關注的題目，週四下午正好是現成的測試場。降速結束後速度回復所需的時間，則由 15:10 那一筆回答。

有了平時與降速中的對照，台灣的行動網路也才會有一份基準。少了基準，未來發生非預期的網路劣化時，任何異常都只能停在「大家覺得變慢」。價值隨參與量放大。幾十支手機足以回答「三家是否都出現明顯下降」，要談到分布與信賴區間則需要數百支。

ndt 與 dash 只能涵蓋高流量那一側，公告稱正常運作的語音、簡訊與細胞廣播不在兩個測項的能力範圍內。能觀察到的只有界線的其中一邊，仍然值得做。社群自己有能力描述網路當下的狀態，本身就是韌性的一部分。

解讀時須留意 ndt 的量測對端是 M-Lab 的伺服器，數字裡同時包含最後一哩與到 M-Lab 節點的國際線路，兩者無法從單筆結果中分離。官方公布的 256KB 可作為預期落點，先掌握量級所在，判讀時較有依據。

參與密度本身也是變因。ndt 會用滿可用頻寬，同一個基地台底下若有多支手機在同一分鐘執行，彼此會搶已經被壓低的頻寬，量到的低速就有一部分來自參與者之間的競爭。以每家電信十支、散在七個縣市的規模來說不太會相互重疊，整理結果時仍要把同時段的參與數一併記錄。

一起來¶

安裝 OONI Probe 並執行一次。設一個 14:35 的鬧鐘。把本文轉給住在北部七縣市或在當地工作的朋友。特別歡迎中華電信與遠傳的用戶，兩家過去 30 天的效能量測分別只有 16 筆與 4 筆。以遠傳來說，10 支手機在週四下午各做三次，一個下午就會超過它整個月的累積量。

不在北部七縣市的人也可以在同樣的時間點測一次。降速範圍外的量測構成對照組，能協助分辨哪些變化來自演練、哪些屬於當天的一般波動。

測完之後，可在 OONI Explorer 用自己的 ASN 與時段查到紀錄。社群會在演練後把三個時段、各家業者的結果整理成一篇後續文章。有問題或想一起整理結果的人，歡迎到社群的 Matrix Public Space 討論。

常見問題¶

為什麼只做效能測試，不把全部測項都執行一遍

效能組以外的測項都會做封鎖判定，而降速會讓它們產生假的封鎖訊號。

以 web_connectivity 為例，判定方式是拿手機端的結果跟 OONI 的測試輔助伺服器比對。手機在限速下大量逾時，輔助伺服器在資料中心運作一切正常，比對出來會被標成 tcp_ip 或 http-failure，也就是封鎖的判定簽名。幾百人同時在限速下執行有封鎖判定的測項，等於在台灣的公開資料裡注入一批看起來像審查的紀錄。

效能組不會產生誤判的封鎖訊號。ndt 與 dash 在後端沒有實作封鎖判定，全球近 90 天各 20 萬筆量測的 anomaly 都是 0，只會留下吞吐量的數值。

時間也不允許。效能組約 1 分 30 秒，穩穩落在區間內。網站那組是一份網址清單，正常網路下就要數分鐘才能完成，在限速下很可能跨過 15:00，把降速中與恢復後混進同一份報告。

會用掉多少行動數據

App 執行前會顯示預估用量。降速期間頻寬已被壓低，用量最小，14:15 與 15:10 在正常速度下執行，會落在估計值的高端。非吃到飽的人優先做降速期間的量測。實際數字見上方的額度提醒。

我的 IP 會被公開，風險有多大

效能測試會把你的 IP 留在 M-Lab 的公開資料集，長期保存且不做匿名化。改做網頁連線測試就不會經過 M-Lab。判斷風險高低所需的細節，見上方的隱私一節。

我不在北部七縣市，還要測嗎

可以，而且有參考價值。範圍外的資料能當對照組，用來排除當天的一般網路波動。

開會中錯過了 14:35 到 14:55 怎麼辦

補做 15:10。就算只補一筆，也能跟其他參與者或隔天同時段對照，無須湊滿三次。

參與這次量測有法律風險嗎

量測的動作是在自己的手機上測自己的連線速度，與一般測速 App 的操作無異，不干擾演習，也不影響其他人。OONI Probe 是全球長期使用的開源工具。若你所屬的組織有自己的合規考量，可以只做網頁連線測試，或選擇不參與。

號召量測是為了查核官方公布的 256KB 嗎

本文的出發點是演練當天難得的觀測條件，時間、地點、業者都預先公開。官方公布的數字在文中作為預期落點，讓參與者知道資料會落在什麼量級。量測的對象是網路狀態，演習的成效與必要性不在討論範圍。

怎麼確認我的量測成功了

完成後結果頁會顯示網路名稱與 ASN，確認上面是自己的電信商，不是 Wi-Fi 也不是 VPN。量測送出後同樣能在 OONI Explorer 查到自己的紀錄。

雙卡手機要注意什麼

先確認行動數據走的是哪一張卡。手機裝了兩張 SIM 卡的話，容易以為自己在測某一家，實際上數據從另一家出去。結果頁顯示的 ASN 是最後的確認。

資料與前提¶

文中的 OONI 數字分成三組，查詢日皆為 2026-08-11，端點與參數如下，讀者可自行重新查詢。

中部場 30 分鐘窗口（表格中的 902、803、593 與兩筆效能量測）用 measurements 端點，probe_cc=TW、since=2026-08-10T06:30:00Z、until=2026-08-10T07:00:00Z，逐一查 test_name 為 ndt、dash、web_connectivity，回傳的每筆都帶 probe_asn。

30 天的 ASN 分布（645,039、253,546、191,257、23,010 與三家行動業者的細項）用 aggregation 端點，probe_cc=TW、test_name=web_connectivity、axis_x=probe_asn、since=2026-07-12、until=2026-08-12。效能測項的 1,008、548、528、16、4 用同一組參數，test_name 換成 ndt。aggregation 的 until 不含當日，所以 until=2026-08-12 涵蓋到 8 月 11 日。

效能測項的 anomaly 為 0 用 aggregation 端點，不帶 probe_cc 代表全球，since=2026-05-13、until=2026-08-12，test_name 分別為 ndt 與 dash。同一組參數換成 tor 與 web_connectivity 可以看出對照，兩者的 anomaly 分別是 13.95% 與 8.05%。

上列數字會隨時間繼續累積，之後重查會得到略高的值，分布的形狀則穩定。

延伸：之後如何用 OONI 佐證研究¶

本次號召針對單一事件，方法本身可以重複使用。OONI 的資料有四個入口，用途各不相同：

OONI Explorer：網頁介面，適合查單筆量測、看某個國家或 ASN 的趨勢，無須寫程式。
Aggregation API：https://api.ooni.org/api/v1/aggregation，免驗證免金鑰，可依國家、測項、ASN 切分做統計。本文的 30 天 ASN 分布與比率出自此端點。since 與 until 只接受日期，帶上時間會回 date_from_datetime_inexact 錯誤，所以它適合看天級以上的趨勢。
Measurements API：https://api.ooni.org/api/v1/measurements，同樣免驗證，接受精確到秒的時間窗，回傳逐筆紀錄。本文中部場 30 分鐘的表格出自此端點。
AWS S3 公開資料集：ooni-data-eu-fra，逐筆原始 JSON，適合需要檢視量測細節或做大規模分析的研究。原始資料以整點批次上傳，落地 S3 的延遲約在半小時到一兩小時之間，取用方式與 CSV 輸出格式寫在 ASN 觀測資料擷取與分析，社群維護的擷取程式也在該頁。

以本次演練為例，30 分鐘的時間窗要用 measurements 端點：probe_cc=TW、test_name=ndt（或 dash）、since=2026-08-13T06:00:00Z、until=2026-08-13T08:00:00Z，回傳的每一筆都帶 probe_asn，再自行歸到 24158、17421、9674 三組。所有時間一律使用 UTC，台灣時間需減 8 小時。要判斷某個問題該用哪個測項，OONI 測項速查表整理了每個測項量測什麼、規格狀態，以及台灣是否有資料。台灣的 ASN 覆蓋現況見 ASN 自治網路觀測資料分析。

最常見的誤解是把異常（anomaly）當成封鎖。OONI 的 anomaly 只代表測試未照預期完成，成因包含審查、網路不穩、ISP 暫時故障，以及測試程式本身的問題，將 anomaly 比率直接視為封鎖率會產生假指控。以 tor 測項的實測為例，取 2026-07-12 到 2026-08-12 這 30 天，加拿大 16.3%（母數 14,042）、瑞士 22.1%（母數 3,231）、紐西蘭 20.1%（母數 562），皆為沒有審查的國家。前一段 90 天的 ndt 與 dash 用的是另一個時間窗，複查三國的比率要換成 30 天的參數。中段數值屬於雜訊，只有比率極端高的少數國家與現實相符。

以上只適用於有做封鎖判定的測項。效能測項的 anomaly 目前在後端幾乎沒有實作，全球近 90 天的 ndt 20 萬筆與 dash 19.8 萬筆，anomaly 都是 0。判斷演練期間是否降速，要直接看吞吐量的數值，不能看 anomaly。

授權方面，OONI 發布的量測資料採 CC BY-NC-SA 4.0，禁止商業使用，衍生內容需以相同授權釋出。引用數據時要標註來源，將 OONI 資料與其他來源合併產生新的資料檔，會讓整份成品都受同一授權拘束。

演習細節以行政院公告與各電信業者公告為準，時間如有調整依官方最新資訊。

資料來源：OONI aggregation 與 measurements API（查詢條件見上方的資料與前提，量測資料授權 CC BY-NC-SA 4.0）、ASN 名稱取自 RIPEstat、M-Lab 的資料處理方式取自 M-Lab 隱私政策。演習相關的官方與媒體來源見下方腳註。

2026城鎮韌性（防空）演習：行動網路降速演練 - 行政院 ↩↩↩↩
韌性演習行動網路降速 NCC籲預先為離線情境做準備 - 中央社 ↩
2026城鎮韌性（防空）演習期程規劃表 - 全民防衛動員署 ↩
配合政府115年城鎮韌性防空演習，中區、北區行動通訊網路降速說明 - 台灣大哥大 ↩
2026城鎮韌性(防空)演習行動網路降速演練 - 中華電信 ↩
#KeepItOn - Access Now ↩
海纜障礙狀況 - 數位發展部 ↩

撤回自己寫過的話：近兩週更正了哪些內容

anoni.net 社群 — Mon, 10 Aug 2026 00:00:00 +0000

撤回自己寫過的話：近兩週更正了哪些內容¶

近兩週有幾頁的內容被改掉，改法多半是把先前寫過的整段撤回。香港的入境查機風險由中升到高、日本境外 eSIM 的例外拿掉、推薦過的 2FA app 換了經營者、台灣封鎖判定的分布從 40 筆抽樣換成 22,105 筆全量重算。7/27 到 8/10 之間文件站併入 50 個 PR，相當比例花在這類更正上。以下按頁介紹改了什麼、依據在哪裡，中段有一份清單，寫給照著舊版做過準備的人。

出差與研討會那頁，撤回了三處敘述¶

出差與研討會的數位準備在八月初做過一次全頁查證，六個方向獨立核對來源，結果撤回三處查不到實據的敘述。

香港自 3/30 起的邊境解鎖權「不以國安嫌疑為前提」。撤回的是「不以國安嫌疑為前提」這個範圍描述。該說法只出現在旅遊資訊聚合網站，各家對生效日（3/28 或 3/30）與罰則（6 個月或 1 年）互相矛盾，政府憲報、律政司資料與第一線報導都查不到對應文本。3/23 的國安法修訂（Legal Notice 27 of 2026）本身查得到，涉國安調查時可要求交出密碼，拒絕即構成刑事罪，只在香港機場轉機並通關的旅客同樣適用。
日本境外購買的 eSIM 不受新規範。森・濱田松本法律事務所對此點明確標註「文書に明記されていません」，文件原本把它寫成一條可以依賴的建議。頁面現在寫的是境外供應商是否納管留待後續省令釐清，出發前不要把「境外買的 eSIM 一定不受規範」當成確定前提。
馬來西亞 ONSA 首週處理 1,500 則以上貼文。原始來源的 1,583 是 2025/1/1 至 11/30 的仇恨內容下架請求總數，時間早於 ONSA 生效。錯的是數字，法本身仍在運作，頁面保留《線上安全法》2026 年 1 月生效、規範對象為平台業者、實際影響落在內容被移除速度變快的敘述。

同一次更新替換了南韓段落的來源。原本引用的 Cybernews 無署名、無引用，且該站與 VPN 聯盟有利益衝突，改用 Lumen Database #73101162 與韓國時報，過期的「20 萬件」也更新為 2024 年審議 356,945 件。

香港的入境查機風險層級由中升到高，依據就是上面那條查得到的國安裝置解密義務。撤回一條被誇大的敘述與調升風險層級同時發生，方向看似相反，實際指向同一件事：解密義務為真，被誇大的只是它的適用範圍。

照著舊版做過準備，要補的五件事¶

上面兩節有五項會改變讀者已經做過的準備，逐條列出現況與該補的動作。

香港行程。入境查機由中風險升到高風險，涉國安調查時拒絕交出密碼本身就是刑事罪。照中風險準備過的人，準備等級要拉到乾淨機這一層，行程只是經香港轉機同樣適用。
日本的境外 eSIM。「境外買的一定不受規範」這個前提要拿掉。納管純數據 SIM 與 eSIM 的法律已經公布，施行日由政令另訂、最遲 2027 年 5 月，境外供應商是否納入尚未明確。
已經在用 Raivo。建議轉到 Aegis 或 2FAS。TOTP 沒有辦法直接搬，需逐一到各服務的兩階段驗證設定裡重新綁定。過程中先留著舊 app，直到新 app 能產生正確驗證碼為止，並確認備援碼還在手上。
預付卡。實名這一層避不掉，台灣的預付卡同樣要實名登記。能做的是不要登記在跟主門號同一個人名下，再據此決定那支門號拿來做什麼。
用虛擬門號註冊過的帳號。值得逐一檢查那些帳號的簡訊復原設定，把已經停用的號碼移除，改用 TOTP 或備援碼。

台灣的封鎖判定改用全量資料重算¶

OONI 怎麼判定一個網站被封鎖引用的是 OONI（全球網路審查的公開量測計畫，各地志願者執行測試、結果全部公開）的觀測資料，原本寫著抽查 40 筆異常測量，dns 31 筆、tcp_ip 6 筆、http-failure 3 筆、http-diff 0 筆，並據此說台灣沒有出現重導向到封鎖告示頁的樣態。改用 2026-08-05 往前 24 小時的全量資料（22,105 筆）重算之後，那份分布與支撐它的抽樣方法都不成立：

判定	筆數	佔比
`false`	21,029	95.13%
`none`	512	2.32%
`tcp_ip`	312	1.41%
`dns`	150	0.68%
`http-failure`	67	0.30%
`http-diff`	35	0.16%

tcp_ip 是 dns 的兩倍以上，http-diff 也確實存在 35 筆，問題出在那 40 筆的來源：它取自 measurements API 的異常清單，該清單有自己的排序，當成隨機樣本使用會失準。頁面上補了一則警示記錄這次更正，因為同樣的陷阱其他人也可能遇到。

被推翻的是分布數字與抽樣方法，「台灣沒有封鎖告示頁」這個結論本身反而站得住。那 35 筆 http-diff 抽查了 4 小時內的 15 筆，body_proportion（Probe 取到的內容與對照組相符的比例）全部落在 0.004 到 0.21 之間，內容遠短於對照組（control），與告示頁逼近 1 的樣態相反。成因需要逐筆查驗證據層（evidence layer），文件因此只陳述觀察到的樣態，不下結論。

能重算的原因是欄位統計終於補上。OONI 測量資料結構導覽上線時就寫著，最小的一步是在逐行解析時多取 test_keys.blocking，統計就能從測量筆數延伸到各 ASN（自治系統編號，網路上一個業者或組織所管的一群 IP）的異常分布。程式一直沒有做，是文件與程式之間唯一一處只寫在紙上的規劃，八月初補上之後，新資料一產出就推翻了上面那段敘述。

互動作品總覽頁的七處更正¶

互動與呈現區的總覽頁上線隔天就查核出七處問題，四處是事實錯誤，三處是寫得過度絕對。

四處事實錯誤裡有兩處是文件與自身敘述矛盾。文中寫地球儀畫面上有流星，原始碼裡的 buildSky() 只畫靜態星空與銀河帶，搜尋 meteor、流星、comet 都沒有命中，帶亮頭的彗星屬於另一件作品 onion-rendezvous，文件把兩件混在一起寫。另一處把「兩條電路在中途某台中繼相遇」當成 Tor 通則，該敘述只適用於連線 .onion 服務，而同一頁的作品卡片寫的是正確版本。

其餘兩處是文件與資料不一致，「每份資料檔都帶有四個欄位」的說法在 cables.json 上就不成立，該檔沒有 sourceUrl 與 licenseUrl，處理方式是把資料補齊，一併修改 tools/gen_cables.py，而非把文件說法改弱。另一處「tools/ 只使用 Python 標準庫加上 curl」遺漏了 fix_trunk_land.mjs 是 Node、publish_games_data.sh 是 shell。

寫得過度絕對的地方有三處：

「任何一步錯位，匿名性就不成立」。匿名性會因為流量關聯、出口監控這類與順序無關的因素被打破，而 Tor 的順序錯亂通常只導致連線失敗。原句把匿名性的失效條件窄化成順序一項，已改為保守敘述。
ASN「由一家業者掌管」。該說法與同一個專案產生快照的腳本註解互相矛盾，註解寫明 ASN 可能由個人申請。
「八十個國家」。直接寫入精確整數，快照重新產生就會過時，改為約八十個並標明數字取自最近一次快照。

英文讀者點進來，多半沒讀到文章¶

Cloudflare 近 90 天的資料（排除子網域與 bot）顯示英文版佔文件站流量 25.9%，440 次瀏覽裡只有 70 次（16%）落在真正的文章，290 次落在分類目錄頁，80 次是 404。

追查後有三個成因，兩個出在轉址設定，一個出在更早的導覽重構。轉址設定裡有四條規則，來源路徑就是現存的英文頁，建站工具遇到這種情形會在該網址產生一頁只有轉址動作的空殼（redirect stub），把真正的文章蓋掉，線上實測那四頁全部只剩轉址畫面。另有三條轉址在英文內容存在的情況下指向目錄頁。最後是 2026-05-09 的導覽重構，該次 commit 從 docs/en/ 刪除 17 個檔案、新增 0 個，約 11.5 萬字元，設定檔註解寫明「dropped pages redirect to the nearest live section index」。

依實測流量還原了五篇，落在真正文章的比例由 16% 提升到 64%。被空殼蓋掉的四頁只佔問題的一小塊，目錄頁與 404 才是大宗，剩下 12 篇被刪的英文內容與 18% 的 404 尚未處理。

寫作規範多了六條自動檢查¶

前面幾節的錯誤有一個共同的上游，規範寫了但沒有工具擋著，內容就會持續偏離，直到有人讀到為止。貢獻者百科寫著口語詞改書面語，而 docs_style_lint.py 只針對其中一個字實作了規則。全站掃描出 605 處那個字以外的口語詞，網站自己的工具對現況回報 0 error、0 warn。

七月底那次清掃連同原本就攔得到的那個字，總共處理 669 處、158 個檔案，同時補上六條 linter 規則，全部列為 warn，因為替換詞取決於語境，不該讓機器直接替換。清掃過程中機械取代造成兩處實質損害，都已修復並補進例外清單：

「主講」被換成「主提到」，破壞了議程頁兩個語系共 20 處介紹。原因是排除清單只擋後面的字，沒擋前面的「主」。
「沒搞清楚」被換成「沒處理清楚」，理解與處理屬於兩回事。

同一週另一支 PR 收尾時發現，比對規則只涵蓋正體字，簡體對應字完全沒有被檢查，zh-CN 等於沒有這條規則。掃過全站之後待處理的項目比預期少，需要檢視的只有 3 處，查證之後都是正當用法。真正的收穫是補上了首套回歸測試，因為 linter 是全站寫作規範唯一的自動檢查點，卻沒有任何測試。覆蓋不全的問題人工抽樣無法察覺，抽到的樣本恰好都在覆蓋範圍內。

更早一次的全站清理已經逐段改寫過 99 個檔案裡的 266 段「這」字堆疊。八月初再補上密度標準，起因是校稿時實際使用的判準只留在 commit 訊息裡，下次寫新頁不會生效，於是把判準寫進貢獻者百科，並把可機器判斷的部分實作成 zhe-repeat 規則。距離門檻 8 個字是對全站 429 篇校準而得，放寬到 10 會開始收進正當用法，全文密度需要語意判斷，刻意留給人工。

兩頁的敘述已經對不上現況¶

個人隱私指引在 8/6 補上「相關文章」索引時，下方的進度段落沒有跟著改，同一頁出現兩種說法。上面列了概念層八篇，下面寫著「概念層五篇上線」並只列原本那五篇。各層索引也累積落後了一段時間，工具層實際 18 篇只列 7 篇、場景層 10 篇只列 5 篇、進階層 5 篇只列 2 篇，這次補進 14 篇。

同一頁的「常見誤區整理」列了四項，讀起來像整條還沒動工。實際盤點後有兩項早已寫完，只是沒被連到，「VPN ≠ 匿名」在 VPN 指南有整篇，「去中心化 ≠ 匿名」在被誤認為匿名的技術完整涵蓋 IPFS、Yggdrasil、DN42 與 I2P。另外兩項確實還沒動工，改後分別標明現況。

幫忙 pin 文件站的 IPFS 鏡像有三處對不上現況，其中兩處是讀者實際操作後才發現的。

macOS 那段寫著 brew install ipfs，Homebrew 的 formula 已經改名為 kubo。舊名仍然裝得起來，可是 brew services 認的是實際名字，依舊文安裝之後再設定常駐服務就會對不上。常駐做法原本只寫「可以用 brew services 或 launchd」，沒有給指令，實際上 formula 本身已定義 service，一行 brew services start kubo 就會常駐並在登入時自動啟動。

第二處是有夥伴想把社群節點設成固定節點，把頁面上的 IPNS 名稱填進 kubo 的 Peering.Peers，工具直接報錯。原因是頁面只解釋了 CID 與 IPNS 名稱，沒有提到節點自己的 Peer ID。三串識別碼長相接近，節點 Peer ID 的 base36 形式與文件站 IPNS 名稱前 12 個字元完全相同，兩者都是公鑰指紋、同一套編碼，差別在一個指向會更新的內容，一個指向一台機器。頁面補上三者的對照表，以及一節選用的 peering 設定。

第三處是導言寫著「目前只有社群自己的節點在 pin」。查 DHT 時發現另有一個第三方節點也在提供文件站內容，可能是別人自架的鏡像，也可能是公開 gateway 取得之後 announce，無論哪一種，原本那句都已經不成立，改為「目前提供文件站內容的節點很少，社群自己那台是主力」。沒有寫出確切數字，因為 findprovs 是盡力而為的查詢，回傳的是逾時前找得到的節點，不保證窮舉，寫出「只有 N 個」會是另一種不準確。

窄螢幕的白邊查到了語言切換選單¶

讀者回報置頂公告右邊會出現一段空白。實際量測後，公告不是原因，把公告整個隱藏，documentElement.scrollWidth 仍然比視窗寬 14px。逐一隱藏候選元素後定位到 header 的語言切換選單，三個語言標籤的中文字面讓收合狀態的選單有 177px 寬，窄螢幕時按鈕貼近視窗右緣，選單就把版面往右頂出去。置頂公告的黑底與 header 的藍底都只有視窗寬，往右滑就露出白邊。斷點正好落在 960px，也就是 header 換成桌面排版的那一刻。改法是在該斷點以下讓選單靠按鈕右緣展開，桌面維持置中。同一次也提高了置頂公告連結在淺色主題的對比，原本只有 2.79:1，幾乎融進黑底。

另外兩個 GitHub Action 還停在 Node 20 runtime，runner 每次執行都會輸出 deprecation 警告。actions/cache 由 v4 升到 v6、actions/setup-node 由 v4 升到 v7，升級前逐版讀過 release notes，確認兩者的破壞性變更都打不到本專案的用法。

兩位社群夥伴的貢獻¶

近兩週的 50 個 PR 裡有兩個來自社群夥伴。

wu858430049 補上了 BECOME_ANONI 協定的簡中版，正本放在 repo 根目錄，位置比照 zh-TW，文件頁用 snippets 嵌入以維持單一來源，同一個 PR 一併修正兩個會讓頁面無法顯示的設定問題。翻譯是站上長期缺人的一條路線，簡中與英文都還有大量頁面沒有對應版本。

ChihChengLiang 更新了 COSCUP 2026 隱私支付實作工作坊的介紹。原本寫著不需自備電腦，在旁觀看即可，有意參與實作的人依此準備會不足。實際上現場已備妥模擬網路與模擬鏈，鼓勵參加者攜帶電腦實際操作。這一項不需要碰任何程式，需要的是知道現場實況並願意把那段文字改掉。

兩個 PR 都移除了會讓讀者做出錯誤判斷的內容。最低的一步是開一個 issue，指出哪一句不對並附上你查到的來源。想直接修改內容，如何參與與認領主題說明怎麼選題與認領，貢獻者百科的「第一週的入門路徑」則依寫作、翻譯、技術維運、活動籌備分成四條線。

你沒有辦法自己驗證的那部分¶

網站的主題是隱私與安全，讀者依照文件的建議調整自己的行為，一句錯的敘述成本落在讀者身上。更難處理的是讀者沒有辦法自己驗證，抽樣得到的分布寫成通則，讀起來跟全量算出來的一模一樣，讀者無從分辨那是 40 筆還是 22,105 筆。更正的過程與依據因此一併寫出來，包含被撤回敘述的原文與不予採信的理由。

同一段時間新增的內容包括互動與呈現區的台灣基礎設施圖層、四篇 OONI 技術文件，以及納入 CI 的 .onion 版建置。若讀到與事實不符的內容，歡迎到 GitHub 開一個 issue 或直接送 PR，我們會查證後更新。

Snowflake Volunteer：Tor Project 推出手機志工橋接 App

anoni.net 社群 — Wed, 05 Aug 2026 00:00:00 +0000

Snowflake Volunteer：Tor Project 推出手機志工橋接 App¶

以下內容改寫自 Tor Project 官方部落格文章，主詞角色為 Tor Project 與文章作者 Pavel：

Snowflake Volunteer, an Android app to help people bypass censorship | August 3, 2026

圖片來源：Tor Project Blog。

我們在伊朗封網後的那篇提過，Snowflake 是幫人連上 Tor 門檻最低的方式：開一個瀏覽器分頁放著不動，就是在幫忙轉發流量。2026 年 8 月 3 日，Tor Project 發文介紹 4 月已經上架的 Snowflake Volunteer，把「貢獻志工橋接」做成一支獨立的 Android App，門檻又降了一階。過去要貢獻 Snowflake 橋接，需透過瀏覽器擴充功能、網站內嵌 widget、桌面版命令列工具，或 Android 上的 Orbot Kindness Mode。新 App 只做這一件事，介面與設定都只為此設計。

為什麼需要一支獨立的 App¶

Snowflake 的運作原理，是把使用者的流量偽裝成視訊通話，再透過志工提供的臨時連線轉發，讓審查者更難偵測與封鎖。機制要運作得好，需要大量穩定在線的志工橋接。2026 年上半年，Snowflake 的媒合伺服器（broker）平均每天約有 146,000 個不重複志工橋接 IP 位址回報¹，其中約三分之一來自 Orbot 的 Kindness Mode，它會顯示自己的裝置協助過多少條連線，讓貢獻變得具體可見。

葡萄牙的 Android App 工作室 Bloco 先前參與 OONI（Open Observatory of Network Interference，網路干擾開放觀測，擁有全球最大的網路審查開放資料集）的合作，看到 NGO 與行動者高度依賴反審查工具維持安全與連線。他們發現貢獻 Snowflake 橋接的門檻不高，想以自身專業回饋這個開源專案，注意到 Kindness Mode 貢獻的比重後，好奇一支「只做志工橋接」的獨立 App 能不能吸引更多人參與，於是主動接洽 Tor 的反審查團隊。對方本來就有類似計畫，只是尚無餘力著手，這個任務便交給了 Bloco。

App 的功能¶

Bloco 站在 Guardian Project 既有的行動端 Tor 生態基礎上開發，特別是函式庫 IPtProxy，它把行動 App 串接 Tor 所需的工具與 pluggable transport（可插拔傳輸，讓流量偽裝成其他外觀以規避審查的技術模組）打包在一起。有了這些現成元件，Bloco 可以把心力放在背景穩定運作與省電、讓使用者看得懂並能照自己的網路狀況正確設定，以及用統計數字持續呈現志工協助了多少連線。

成果是 Snowflake Volunteer：使用者可以設定讓它在背景執行、只在 Wi-Fi 等非計量網路下運作、只在充電時運作，也可以設定同時協助的連線數上限。啟用後，App 會自動與需要 Snowflake 橋接的使用者配對，協助把對方的連線導向 Tor 網路，過程中雙方互不知道彼此身分。

瀏覽器分頁版本的 Snowflake 在手機上有已知限制：分頁進入背景後，Android 系統經常會直接中斷 WebRTC 連線，長時間貢獻一直都建議改用桌上型電腦或筆電。Snowflake Volunteer 是獨立 App，用的是 Android 允許持續執行的背景服務，不受分頁被系統回收的限制，正是手機能長期貢獻的關鍵差異。

App 的主畫面、設定頁與統計頁截圖。圖片來源：Tor Project Blog。

上線後的成效¶

Snowflake Volunteer 經過一段社群測試與意見回饋後，於 4 月正式在 F-Droid 與 Google Play 上架。5 月平均每天約 1,300 個不重複志工橋接 IP，6 月成長到約 1,700 個，單月成長 29%，單日尖峰曾超過 2,100 個橋接。相對於整體約 146,000 個橋接的規模，這批新增志工還只是一小塊，但原本並不在池子裡，多半是過去被瀏覽器分頁版本擋在門外的手機使用者。

App 目前支援 8 種語言（英文、法文、德文、日文、葡萄牙文、土耳其文、越南文，以及簡體中文），這些語言版本來自社群在地化志工的貢獻。目前還沒有正體中文版本，想協助的人可以到 Weblate 專案頁，或先讀 Tor 的在地化流程說明。

對台灣讀者來說多了一個選項¶

Tor Snowflake 橋接點已經整理過台灣為什麼適合貢獻橋接：對外連線受審查程度低、頻寬充足，比起架設 Tor Relay 門檻明顯較低。安裝這支 App，表示手機會替受審查地區的使用者轉發 Tor 流量，實際運作上有幾件事值得先知道：對外網站看到的是 Tor 出口節點，不是你的 IP，你自己也看不到流量內容，因為流量在轉發前已經被 Tor 加密。預設設定下對日常網路使用幾乎無感，勾選只在 Wi-Fi、只在充電時運作，就不會動用行動網路的流量或電量。在公司或學校網路上執行，等於把那個網路的 IP 用來轉發第三方流量，資訊政策嚴格的環境建議先問過資訊部門。

已經在用 Orbot Kindness Mode 的人不必重複安裝，可以繼續用它。Snowflake Volunteer 的差別在於只做橋接一件事，能單獨設定只在 Wi-Fi、只在充電時運作，不必連著整個 Orbot 一起開，適合只想幫這個忙、不想順便用 Orbot 上網的人。

跟瀏覽器版一樣，如果你在香港，參與前請先讀 Tor Snowflake 橋接點頁裡的香港讀者提醒，把國安監控風險一併評估。

如何安裝¶

Snowflake Volunteer 可以從 F-Droid、Google Play 下載，一般使用者用 Google Play 即可，偏好開源商店的人可以用 F-Droid。原始碼開源在 GitHub，可以自行編譯，遇到問題也可以直接開 issue。iOS 目前沒有對應的 App，iPhone 使用者可以改用瀏覽器版橋接點。

把匿名網路畫成一顆地球：互動區上線，以及我們在開放資料上撞到的牆

anoni.net 社群 — Tue, 28 Jul 2026 00:00:00 +0000

把匿名網路畫成一顆地球：互動區上線，以及我們在開放資料上撞到的牆¶

文件站新增了互動與呈現區，目前放了三件作品，都以 Tor 為題。其中資料量最大的是 Tor 中繼地球儀，把全球近萬台運作中的中繼標到球面上，超過六成集中在美國、德國、荷蘭三個國家。

做這顆地球儀的過程中，我們查了二十幾份公開資料，最後能用的只有六份。卡住的原因幾乎都跟技術無關。API 大多打得通，資料格式也乾淨，擋下來的是條款不給我們把它再發出去。

為什麼要做成畫面¶

匿名網路的基礎建設很難用文字描述清楚，難在兩件事上：順序，還有規模。

順序的部分，Tor 是最好的例子。封包在三個中繼之間依序前進，每經過一跳剝除一層加密，到出口才還原成原本的請求。哪一層在哪一跳剝掉、每一站看得到什麼，都由這個順序決定。文字寫得再仔細，讀者腦中仍然要自行補上動起來的那一段，而每個人補出來的版本未必相同。

規模則更難傳達。「近萬台中繼，高度集中在少數國家」是一句讀過即忘的敘述。把每一台實際標記到地球上，北美與西歐連成一片光帶，其餘地區僅零星數點。同一份數字換成畫面，讀者不必信任我們的形容詞，可以自己看。

地球儀用到的六份資料¶

最後進到畫面上的有這幾份：

資料	來源	授權
中繼分布	Onionoo	CC0 1.0
使用者與橋接人數	Tor Metrics	CC0 1.0
連線受阻的觀測	OONI	CC BY-NC-SA 4.0
斷網事件	Access Now KeepItOn	CC BY 4.0
海底電纜	OpenStreetMap 貢獻者	ODbL 1.0
國界與海岸線	Natural Earth	public domain

Onionoo 的中繼快照經過蒸餾，只保留國家層級的聚合，內容不含 fingerprint、nickname、IP 或聯絡資訊。ASN 的登記名稱另外過濾過，因為個人申請的 AS 在 RIR 上登記的就是持有人本名。對於在審查嚴格的地區營運中繼的人來說，那等於把「這台中繼是誰的」跟身分證上的名字綁在一起公開。

陸地亮度可以切換四種指標。中繼台數最直觀。共識權重（consensus weight）反映該國實際承擔的流量比重，與台數常有明顯落差。單一業者集中度是最大一家托管商佔該國的比例，數字愈高代表該國的匿名流量愈依賴同一個機房的存續與配合。使用者估計則是需求端的數字，跟前三個供給端指標並列時，落差本身就是資訊。

後記：2026-07-31 又補了三份

這篇發表之後地球儀又加了三份資料，過的是同一道授權關卡。

資料	來源	授權
上網人口比例	World Bank	CC BY 4.0
台灣的上網人口比例	數位發展部國家數位近用調查	政府資料開放授權條款-第1版
海底地形	Natural Earth	public domain

上網人口比例是拿來當分母的。畫面原本只呈現一個數字，這一國有幾人用 Tor，而那個數字很大一部分是在比人口大小。知道該國有多少比例的人上網，才判斷得出兩國的落差是不是單純因為一邊上網的人本來就少。

World Bank 那份有一個對這個站很尷尬的缺口：217 個經濟體裡沒有台灣。所以台灣單獨取自數位發展部的調查，兩份的方法論不同，一份是 ITU 彙整各國通報，一份是對 12 歲以上人口的電話抽樣，畫面上標示了不宜直接比較。這也是一種資料政治，跟前面那些授權的牆不同類，但同樣會落在下游的人身上。

海底地形跟國界同源，所以沒有新的授權要處理。取的是 200、1000、3000、5000 公尺四層等深線，最淺那階就是大陸棚。加了它之後海纜那層才有解釋力：海纜幾乎都沿著陸棚鋪、避開深海盆，兩層對照著看得出來為什麼纜線走那些路徑。

順著海纜又查了登陸點，那是整條纜線最脆弱的幾個點，台灣的那幾個尤其受關注。結論是 OpenStreetMap 沒有這份資料，不是抓不到。用 taginfo 查全球數量，man_made=cable_landing_point、seamark:type=landing_point 等五個候選標籤全都是 0 筆。登陸點座標跟纜線幾何一樣是 TeleGeography 商品的一部分，撞的是上面那面同樣的牆。

資料的呈現刻意克制¶

OONI 的資料最能說明我們的取捨。它提供各國 Tor 測試的異常率（anomaly rate），數字看起來足以畫一張全球審查地圖，但中段是量測雜訊。實測瑞士 22.2%、加拿大 21.2%、紐西蘭 41.1%，這些國家沒有審查疑慮。把中段畫成色階，等於用雜訊指控特定國家。

最後畫面只標示異常率達 85% 以上且樣本足夠的少數國家，中段數值一律不上色，措辭也停在「沒有照預期完成」。85% 這個門檻沒有推導公式，是看過分布之後訂的。雜訊最高落在四成上下，拉到 85% 才有足夠的距離，寧可漏掉幾個真的受阻的國家，也不要把沒問題的國家標紅。

Access Now 的斷網事件則相反，每一筆都經過人工查證，成因清楚，所以可以明確說明此處發生過人為斷網。即使如此，武裝衝突與族群衝突造成的中斷未必出自政府決策，可能是戰事破壞了基礎設施，畫面上與資訊管制類分開說明。

同樣的理由讓我們放棄了 V-Dem 的數位社會指標。那份資料的授權技術上可用，我們仍然決定不碰。它是每個國家每年由約五位專家評分，經統計模型轉成連續量表。把專家評分畫成地圖色塊，等於用我們的畫面替某個機構的政治判斷背書。

撞到的牆¶

海底電纜¶

一開始想用 TeleGeography 的 Submarine Cable Map，那是這個領域最權威的資料集。查下去才發現他們現在把座標資料當成正式商品在賣，License TeleGeography's Map Data 是年費授權，GeoJSON 經 Amazon S3 或 API 交付，每次更新自動推送。GeoJSON 就是他們的商品本體。

台灣的海纜動態地圖的做法值得記下來，也是授權不明朗時最務實的選擇：程式碼採 MIT 開源，但幾何資料放在另一個 repo，對外是 404。主 repo 的 README 直接寫「You can leave the folder empty」。

那顆地球儀上的海纜最後取自 OpenStreetMap 貢獻者標註的路徑，228 段。覆蓋以歐洲、地中海與大西洋較完整，太平洋中段幾乎是空的。翻出 OSM 社群 2011 年的討論串，當年有人提議把 TeleGeography 的資料併進 OSM，社群成員的判斷是那份授權禁止商業使用與改作，跟 ODbL 不相容，那則提議沒有下文。十五年過去，太平洋還是空的。

網路基礎建設¶

網路基礎建設這一類查了一輪，幾乎全軍覆沒，卡住的理由還很像。

RIPE Atlas 佈署在各地的量測節點（probe）資料很漂亮，2026 年 7 月查詢時全球有近六萬個節點，含經緯度與 ASN，API 直接回得出來。但服務條款寫明商業使用需另外取得 RIPE NCC 許可，沒有開放授權宣告。PeeringDB 的 API 一樣打得通，但可接受使用政策寫明不可整批轉散布給第三方。Packet Clearing House 的 IXP 目錄是 CC BY-NC-SA 3.0，Cloudflare Radar 是 CC BY-NC 4.0，兩者的非商業條款都會傳染到我們的內容上。

還有一類更麻煩：條款完全不存在。各 RIR 的 delegated stats 檔案下載得到，開頭只有免責聲明，沒有一個字提到授權。root-servers.org 的節點清單有 JSON 端點，整站找不到授權宣告。沉默無法解讀成允許，比明文禁止更難處理，因為連判斷的依據都沒有。這一節的每一份都是同樣的組合，端點開放、資料拿得到、授權不給再散布。

指數類資料¶

Freedom House 的 Freedom on the Net 與無國界記者的新聞自由指數，這兩份最常被引用，也都不能用。RSF 的授權是 CC BY-ND，禁止改作，把它轉成 JSON 重新呈現就違反了。Freedom House 官方頁面查不到授權聲明，取得資料要寫信申請。

我們沒有寫信去問¶

上面幾個機構，開放資料圈的常規做法是讀完條款之後再去信問一次，通常有機會取得非營利或研究用途的例外。我們刻意沒有這麼做。

整個專案想知道的正是一個下游再利用者實際會撞到什麼。如果每一份卡住的資料都靠個別協商解決，我們得到的會是幾封友善的回信，而不是「這個生態系對想接手的人有多友善」的答案。條款寫成什麼樣子，就是絕大多數人實際會遇到的樣子。沒有人脈、沒有機構背景、只是想做點東西的人，看到的就是那一頁條款，所以這篇記錄的是條款，不是協商結果。

我們學到的¶

最大的落差是開放 API 不等於開放資料。原本以為困難會在技術面，結果多數端點都打得通、資料格式也乾淨，卡住的全在條款。RIR、CAIDA、RIPE NCC、PeeringDB 這些機構的預設立場是可以看、可以研究，但不能整批搬走，那跟 Tor Metrics、OONI、Natural Earth 是完全不同的文化。連完全沒寫授權的沉默狀態也算在內，那種資料集實務上等同不可用。業界確實有很多工具在用這類檔案，風險由使用者各自承擔，公開發布的文件站不能比照辦理。

我們的架構也不容許「應該沒問題」的僥倖。文件站是靜態網站，資料檔會直接發出去，而且會推上 IPFS。內容定址意味著發出去就收不回來，鏡像可能長期存在。

反過來看，地球儀能做出來，很大程度是因為 Tor Project 把 Onionoo 與 Tor Metrics 都放成 CC0，Natural Earth 放成公有領域。當年那可能只是一行設定，卻讓十幾年後一個不相干的社群能夠直接拿去用，不必寫信談授權，也不必擔心哪天被要求下架。

有一個技術細節值得另外記下來。OONI 那份是 CC BY-NC-SA 4.0，其中的相同方式分享（ShareAlike）跟網站的 CC BY 4.0 互不相容。處理方式是讓 ooni.json 保持獨立的一份，不把它的內容併進其他資料檔，畫面上也只跟其他來源並列，讓整體屬於 CC 定義的「集合」，相同方式分享的範圍停在那一份檔案身上。前提已經寫進 NOTICE，否則哪天有人把 OONI 的欄位併進中繼快照，整份衍生物就落入相同方式分享了。

其他兩件作品¶

Tor 路由解謎讓你自己挑三個中繼組成 guard、middle、exit 路徑，過程中要避開被監聽的節點、把三跳分散到不同 ASN，遇到封鎖改走橋接。看著電路因為三跳擠在同一個 ASN 而失敗，比讀十次「要分散」有效。

Tor 連線流量用發光粒子呈現兩種路徑的差異。連線 .onion 服務時雙方各建一條三跳電路，在隨機挑出的會合點相遇。連線明網網站則走三跳到出口後原路往返。

三件作品都以 three.js 在瀏覽器中執行，免安裝，支援正體中文、簡體中文與英文。原始碼在 anoni-net/docs 的 docs/zh-TW/games/ 底下，沒有建置流程，改完存檔重新整理就看得到。

有想法或想一起做，歡迎到社群找我們。

從肯亞高院到台灣盲點：OONI 開放資料如何進到法庭、新聞室與公共紀錄

anoni.net 社群 — Sun, 26 Jul 2026 00:00:00 +0000

從肯亞高院到台灣盲點：OONI 開放資料如何進到法庭、新聞室與公共紀錄¶

這篇文章是 Tor Project 部落格「守護自由網際網路」系列的其中一篇，介紹 OONI 在實際情境中如何運作。原文翻譯如下：

Defending the public's right to know, pavel 2026-05-12

在原文之外，文末另外補一段台灣脈絡，談台灣的 OONI 觀測現況、可以對照肯亞案件的法律倡議切入點，以及一般讀者可以如何把家用網路、行動網路接進這份公共紀錄。

圖片來源：Tor Project Blog。

網路自由已經連續 15 年下滑。除了監控、隱私與匿名性遭到侵蝕、各種資訊操弄之外，各國政府也針對特定網站與服務實施封鎖或限制，甚至直接攻擊網路基礎建設本身，造成網路關閉（shutdown）與蓄意中斷。我們要怎麼知道網路在什麼時候被審查、又用了什麼方式？

OONI（Open Observatory for Network Interference，網路干擾開放觀測站）是 Tor Project 衍生出來的計畫，提供自由及開源工具與開放資料。使用者用這些工具量測網路審查事件，把觀測結果上傳成可驗證的紀錄，後續也可以引用到報導、研究或法律行動。以下是幾個實際的案例。

守護公共紀錄¶

OONI 的觀測資料是全球最大的網路審查開放資料集，自 2012 年以來已累積數十億筆量測，涵蓋 245 個國家與地區、數萬個網路。這些資料能存在，是因為全球各地有人在使用 OONI Probe（一款免費的網路測量工具，桌面版與手機版都有，按一下就對你所在的網路執行一輪連線測試），把自己連線的網路狀況回報上來。每一筆新的量測，都會加進這份公共紀錄。

這份資料集之所以受到引用，原因同時來自規模與方法論。網路審查常常以「讓干擾看不出來」的方式進行，被封鎖的網站看起來像壞掉了、被限速的應用程式看起來不穩定、整段網路關閉看起來像是技術故障。在 OONI 採用的公開量測方法論、同儕審查、專家回饋與對照組量測的基礎上，干擾手段可以在資料層面被識別出來，「網路被審查了」的主張因此可以被檢驗、被挑戰、被驗證。

為了降低查資料的門檻，OONI Explorer 上線了主題式頁面，聚焦在最常被審查的幾個領域，包括社群媒體與即時通訊應用程式、新聞媒體、翻牆工具。每個頁面都收錄短篇報告、長篇研究報告，以及帶最新 OONI 資料的圖表。

2025 年新增的「新聞媒體封鎖」頁面就是一個例子，讀者不必翻數十億筆原始量測，就能直接看到這些發現。包括埃及封鎖獨立媒體 Zawia3、約旦封鎖 12 個新聞媒體網站、印度在與巴基斯坦軍事衝突期間封鎖 The Wire。

網路審查事件通常發生的時間點，往往是選舉、抗議、武裝衝突、全國性大考、政局動盪期間，正是民眾最需要取得資訊的時候。在這些關鍵時刻，受影響的社群可以從 OONI 觀測資料取得共同的事實基礎，後續才有機會究責。

新聞工作者與媒體組織如何運用 OONI¶

OONI Explorer 的截圖，顯示 dw.com 在俄羅斯、中國、伊朗被封鎖的情形。圖片來源：Tor Project Blog。

2025 年，俄羅斯流亡媒體中相當知名的 Meduza 發表了一篇文章介紹 OONI 工具，邀讀者實際試用。從 Meduza 的做法可以看到，新聞編輯室除了用網路審查量測來寫報導，也可以把它當作公共教育的一環，讓讀者理解網路干擾是如何運作的、可以如何被記錄下來、自己又能如何貢獻到這份證據基礎裡。

新聞網站被封鎖，影響從來不只是技術層面，代表的是大眾失去取得報導的管道、社群失去即時資訊、記者失去他們的讀者。只有當這件事被記錄成可以被引用、可以被分析的資料，後續行動才有立足點。

最具體的串接案例發生在肯亞。OONI 觀測資料被當作證據，用在一場挑戰「非法切斷網路連線」的公共利益訴訟。這場訴訟由一個聯盟提出，成員包括 BAKE、ICJ Kenya、Paradigm Initiative、肯亞記者工會（Kenya Union of Journalists）、Katiba Institute、肯亞律師公會（Law Society of Kenya）和 CIPESA。為了支援這份提交給肯亞高等法院（High Court of Kenya）的聲請，OONI 以專家意見的形式產出了一份詳細的研究報告，記錄 Telegram 在肯亞 2023 與 2024 年 KCSE 全國性大考（肯亞的中學畢業會考，當局以防堵考題外洩為由，在考試期間限制社群與通訊軟體）期間被封鎖的情形。

在肯亞的訴訟裡，記者工會、數位人權組織、法律倡議者與技術研究者從同一份資料集出發，把「網路被中斷」推升為公共利益議題。這也是區域上重要的先例，坦尚尼亞的律師後來主動聯絡 OONI 索取資料，用來支持當地挑戰封鎖 Twitter/X 的法律行動，OONI 也因此發表了一份記錄該次封鎖的研究報告。

為共同的網際網路集體行動¶

從肯亞延伸到坦尚尼亞的這個漣漪效應裡，可以看到網路審查如何跨地域運作，也可以看到大家可以如何回應。封鎖一個即時通訊應用程式，從來不是一件孤立的事。記者可能失去與消息來源的聯繫管道，社運行動者可能失去組織動員的通道，翻牆工具開發者可能要重新調整，研究者可能要驗證實際情況，律師可能需要證據。所有人都需要文件紀錄。

OONI 的開放資料模型，正好對應這些關鍵時刻的需求。守護自由的網際網路，需要把審查記錄下來、把證據分享出去，並且一起累積回應這些事件的集體量能。

在地脈絡：台灣如何接上這個工作流程¶

OONI 在肯亞、坦尚尼亞、約旦、印度、埃及的故事，地理位置上看起來離我們很遠，但運作邏輯跟台灣是同一套，靠的都是公開的量測資料和跨領域的協作。台灣要接上這套工作流程，從觀測覆蓋、倡議路徑到一般人的參與，有三件事可以往下看。

台灣的 OONI 觀測覆蓋還有盲點¶

匿名網路社群長期維護一份 ASN 自治網路觀測資料分析，把台灣每個 ASN（自治系統編號，可粗略理解成每家 ISP 的網路編號，中華電信、台哥大各自不同）的 OONI 觀測筆數整理成圖表。實際看下來，觀測集中在少數幾家網路，行動網路、學術網路、許多本地 ISP 仍然是空白。OONI 全球資料集再龐大，台灣這塊還是要靠在地使用者持續執行 OONI Probe 才能補上盲點。

台灣的情況也一樣，哪個 ASN 沒人在執行 OONI，未來如果在那條路徑上發生封鎖或中斷，就缺少能引用的證據。

從肯亞訴訟看台灣的倡議切入點¶

肯亞高等法院的訴訟示範了公民團體、媒體工會、法律倡議者、技術研究者如何從同一份開放資料出發，把網路中斷的爭議推到制度層級的問責程序。報導中國、香港、緬甸的封鎖事件時，台灣媒體與公民團體已經能引用 OONI 公開資料當作佐證。下一步值得思考的是，當台灣自己遇到網路中斷或服務阻斷事件時（例如 2023 年馬祖海纜中斷導致離島對外連線受影響），如何在法律倡議、人權報告、立法質詢層面建立類似的證據鏈。

把家用網路、行動網路接進這份公共紀錄¶

OONI Probe 桌面版與行動版都能在家用網路、行動網路、公共 Wi-Fi 上執行，每換一個連線環境就能多留下一筆紀錄。對社群與民間組織來說，可以把它放進既有的工作節奏，例如在不同縣市的據點、活動現場、成員的行動門號上輪流量測，讓覆蓋從少數幾家網路擴散到更多日常情境。這跟前面提到的盲點是同一件事的兩面，一邊是看出哪裡還沒被測到，一邊是把那些網路一筆一筆補上來。

你可以做的事¶

不論你是想補觀測、做研究，還是要把資料用在報導或倡議，都有可以著手的起點。

一般讀者：安裝 OONI Probe 執行一輪，讓你這條網路出現在公共紀錄裡（執行前可先看 OONI 對潛在風險的說明）。如果有你常用、想納入定期測量的網站，可以到 OONI 的測試清單編輯器提交，之後全球的 OONI Probe 就會把它排進測試。
研究者與技術社群：先看 ASN 自治網路觀測資料分析上台灣 ASN 的盲點分布，再評估自己這條網路或實驗環境可以補上哪些量測，並把資料整理成可重複比對的圖表。
記者、媒體編輯、人權律師：下次處理中國、香港、緬甸等地封鎖事件的報導時，OONI Explorer 上的量測截圖、調查發現（findings）短篇報告、長篇研究報告都可以引用做公開佐證。要走到公共利益訴訟層級的案件，肯亞案示範了向 OONI 申請專家意見報告的流程。

COSCUP 2026 匿名網路社群議程軌徵現場工作人員：三個崗位，8/08、8/09 兩天

anoni.net 社群 — Sat, 25 Jul 2026 00:00:00 +0000

COSCUP 2026 匿名網路社群議程軌徵現場工作人員：三個崗位，8/08、8/09 兩天¶

議程排定了，十六場的講者也都確認出席。8/08、8/09 兩天在臺灣科技大學 TR-510，從網路審查如何運作、瀏覽器指紋追蹤，到臺師大的校園 Tor 節點與健保資料庫的個資權利，還有 8/08 下午與 ETHTaipei 合辦的匿名支付場。現場執行的人力目前只有一位。

8/09 的換場休息只有五分鐘，需要有人在講者超時前舉牌，也需要有人趁這五分鐘把下一位講者接上台、測好投影與音訊。有幾場的講者要求不錄影，需要有人全程盯住確實沒有被錄進去，這件事出錯之後無法補救。8/08 上午還有受邀前來的公民團體與獨立記者，需要有人在門口招呼、引導入座。

我們在找三位現場工作人員

崗位：錄影 1 位、台前機動 1 位、場外機動 1 位
條件：不需要具備 Tor、匿名網路或任何隱私技術的背景
時間：兩天都能到最好，只能到一天也歡迎，人多的話會排輪班
報名或詢問：透過聯絡我們的任一管道告訴我們，註明想擔任的崗位與可以到的日期

三個崗位在做什麼¶

錄影：確認大會的錄影正常運作，盯住幾場講者要求不錄影的議程確實沒有被錄到，遠端講者連線時顧一下畫面。需要細心，不需要會操作專業攝影器材。
台前機動：舉牌控時、提前接下一位講者、測投影與轉接頭、問答時遞麥克風。需要熟悉筆電接投影這類事，不需要理解議程內容。
場外機動：門口引導與人數計數、發放社群文件站的資訊、處理餐點與物資。需要好相處，能簡單說明這個社群在做什麼。

三個崗位都是照著流程走，活動前一週會開一次線上說明會，把兩天的流程、控時手勢與突發狀況的處理原則走過一遍。

時間與地點¶

8/08（六）：08:30 到 17:00。上午是三場社群導論加一場邀請議程，13:00 之後是與 ETHTaipei 合辦的匿名支付場（TR-511），這段我們的人力較鬆。
8/09（日）：09:00 到 16:30。七場錄取議程接連進行，是兩天裡最需要人的一天。
地點：國立臺灣科技大學（NTUST），社群議程軌在 TR-510。

值勤之外可以自由聽議程¶

不在崗位上的時段可以自由去聽議程，8/08 下午幾乎整段都是空的。值勤時段的餐點由社群準備。行前說明會與活動當天都能直接認識這一軌的講者。

這一軌今年談的內容涵蓋網路與審查如何運作、OpenWRT 家用網路、臺師大 Tor 節點建立實務、瀏覽器指紋追蹤、健保資料庫的停止利用權，以及從個人到組織的隱私指南 2026，完整議程與各場摘要放在活動頁。

沒有經驗也可以¶

社群平常在做的事，是把 Tor、Tails、OONI 這些開源工具的介面翻譯成正體中文、回報問題、協助在校園架設中繼節點。這次的現場工作同樣不需要事先具備專業背景，願意花兩天陪著把議程執行完就夠了。沒有參加過 COSCUP 也沒有關係，說明會上會把該知道的細節都交代清楚。

看完整議程與各場摘要

報名方式

請透過聯絡我們的任一管道與社群聯繫，告訴我們想擔任的崗位、可以到的日期，以及方便的聯絡方式。三個崗位額滿之後仍然歡迎加入，會前宣傳與會後整理同樣需要人。

FISA 702 條款到期：美國無令狀蒐集境外通訊的授權，2026 年 6 月暫時失效

anoni.net 社群 — Thu, 23 Jul 2026 00:00:00 +0000

FISA 702 條款到期：美國無令狀蒐集境外通訊的授權，2026 年 6 月暫時失效¶

圖片為 EFF 設計師 Hugh D'Andrade 繪製的「NSA eagle」，把 NSA 標誌改畫成老鷹用爪子接上電信線路，象徵無令狀的大規模監控。出自 EFF 的 NSA 監控專題，授權為 CC BY 4.0¹⁰。

你寄一封信到 Gmail、用 iMessage 跟在美國的朋友聊天、用 WhatsApp 聯絡海外的家人，這些通訊只要有一端落在美國的服務或網路上，原本就可能被美國情報機構在不需令狀的情況下蒐集。提供授權的法律叫 FISA Section 702（《外國情報監控法》第 702 條）。2026 年 6 月 12 日午夜，該授權在美國國會的僵局中到期¹。

EFF（電子前線基金會）把 702 到期稱為一場勝利。要理解為什麼，需先知道 702 是什麼、它跟 2013 年史諾登（Edward Snowden）揭露的監控計畫是什麼關係，以及為什麼台灣使用者長期就是這套監控的合法對象，「暫時失效」對他們的處境又意味著什麼。

Section 702 是什麼¶

Section 702 由美國 2008 年的《FISA Amendments Act》（外國情報監控法修正案）設立³。它允許美國情報機構在認定某位境外人士握有外國情報價值時，不經個別令狀就蒐集這個人的通訊，包含電子郵件、訊息與通話。

關鍵在「境外人士」這四個字。702 的設計對象是美國境外的所有人，所以美國境外的每一個人，包含台灣使用者，在法律上原本就是合法的蒐集目標。美國公民受美國憲法第四修正案保護，需要令狀，境外人士沒有同一層保護。

實務上，702 還會大量「附帶蒐集」（incidental collection）到美國人的通訊。只要美國人跟被鎖定的境外目標有來往，他的郵件、訊息、通話就會一併被收進資料庫。這是後面爭議的起點。

702 授權之下有兩種具體的蒐集方式，名字許多人聽過：

下游蒐集（Downstream，舊稱 PRISM）：政府要求 Google、Microsoft、Apple、Facebook、Yahoo 等科技公司，交出符合條件的使用者通訊²。
上游蒐集（Upstream）：NSA（國家安全局）直接從網際網路骨幹的纜線與交換器上擷取流量²。

PRISM 與 Upstream 不是傳說中的代號。它們是 702 這條法律授權底下，實際運作的兩個程式。

跟史諾登事件的關聯¶

史諾登在 2013 年揭露的監控計畫，法律基礎正是 Section 702。當年 6 月，這位前 NSA 約聘人員把一批內部簡報交給記者，PRISM 與 Upstream 兩個名字就是從那批文件流入公眾視野的²。全世界第一次看到「原來美國可以這樣蒐集全球的網路通訊」，看到的就是 702 在運作的樣子。

史諾登揭露的是「如何蒐集」，Section 702 則是「憑什麼能蒐集」的法律授權。

從立法到暫時失效，這套授權的幾個主要時間點：

2008 年：《FISA Amendments Act》通過，設立 Section 702，讓原本游走在灰色地帶的無令狀蒐集有了明文授權。
2013 年：史諾登揭露 PRISM 與 Upstream，702 第一次成為全球公共議題，各國才意識到自己是這套蒐集的對象。
之後十多年：702 經 2012、2017、2024 多次重新授權，每一次都伴隨改革派與情報機構的拉鋸，EFF 等團體持續要求加上令狀門檻。2024 年的 RISAA 把授權延到 2026 年 4 月，之後再靠臨時延長撐到 6 月。
2026 年 6 月 12 日：在一場國會僵局中暫時到期。

史諾登當年揭露的計畫，過了十三年，它的法律授權第一次出現空窗。

後門搜尋（backdoor searches）為什麼是爭議核心¶

702 名義上鎖定境外人士，真正在美國國內引發憲法爭議的是後門搜尋（backdoor searches），官方稱為「美國人查詢」（US person queries）。

702 蒐集進來的龐大通訊資料庫裡，因為附帶蒐集而塞滿了美國人的通訊。FBI（美國聯邦調查局）、CIA（中央情報局）、NSA 之後可以用美國人的姓名、電子郵件、電話等識別碼去查詢資料庫，不需要另外申請令狀。等於繞過了第四修正案對美國人的保護，從後門取得資料。

規模不小，違規也不少：

FBI 在 2019 到 2022 年間，對美國人做了將近 500 萬次查詢，這些查詢程序上多屬合法，爭議在於大多缺乏個案的合理說明⁴。
政府在 2022 年 3 月通報，光是對 Section 702 資料庫的搜尋，就有超過 278,000 次不符規定⁴。
2024 年國會通過《Reforming Intelligence and Securing America Act》（RISAA，情報改革與保障美國法），加了一些改革，但沒有解決無令狀查詢這個根本問題。到 2024 年 8 月，已經有報導指出 FBI 用了一個查詢工具繞過 RISAA 的限制⁴。

EFF 長期主張，FBI 要查詢美國人在 702 之下被蒐集的通訊，應該先取得令狀。如果做不到這個門檻，那就讓整個方案到期，不要再續¹。

2026 年 6 月發生什麼¶

702 這次到期，導火線跟一樁人事任命有關。川普提名 Bill Pulte（時任聯邦住房金融局局長）暫代國家情報總監（DNI），接替宣布請辭的 Tulsi Gabbard¹⁵。DNI 監督的正是執行 702 的情報機構，把位子交給一位沒有情報資歷、又曾以房貸詐欺名義追查川普政敵的人選，讓參議院民主黨不願在此時放行。他們以 Pulte 缺乏情報、軍事與國會經歷為由，拒絕推進自家版本的重新授權法案，眾議院則否決了短期續延¹⁵。國會幾次靠臨時延長把期限往後推，最後在 6 月 12 日午夜停在到期¹。

到期不等於監控當天就停。依現有報導，外國情報監控法院（FISC）對既有方案的重新認證效力延續到 2027 年 3 月，為這段期間的蒐集留下法律依據。有法律專家直言「702 不會就此停擺（go dark），那是迷思」⁵。這次到期更接近一個法律與政治上的轉折點，而非開關被立刻關掉。

為什麼 EFF 把暫時失效也當成勝利¶

EFF 點出，這套權力的濫用風險從來不繫於某一個人或某一屆政府。如果國會擔心的是「某個人可能取得美國人的敏感資訊」，負責任的做法是去強化制度層面的透明、究責與監督機制，而不是把希望寄託在換掉某個人選¹。

2026 年一整年，國會兩黨對改革的胃口都在變大，愈來愈多人反對在沒有令狀門檻的前提下重新授權 702¹。一條運作了十多年、史諾登揭露過、改革多次卡關的監控授權，能走到暫時失效這一步，本身就說明持續倡議是有用的。

回到台灣：你本來就是境外監控的合法對象¶

702 的失效對美國的倡議者是一場勝利，對台灣讀者能保護到的範圍卻很有限。702 這幾年的爭議重點是保護美國人，後門搜尋爭的是美國人受第四修正案保護、卻被繞過去查。台灣人本來就不在第四修正案的保護範圍內，要查詢台灣人在 702 之下被蒐集的通訊，對美國政府而言連後門都算不上，是正門。

你仍然是合法蒐集對象¶

很多人因為台美關係友好，覺得被美國蒐集總比被別人蒐集好，因此對 702 無感。隱私防護設防的對象是能力，不是當下的善意。一個機構今天友好，不代表它握有的蒐集能力會跟著縮手，蒐集的對象與用途也會隨政治情勢改變。把任何握有大規模蒐集能力的行為者放進同一套威脅模型，比依賴「現在是盟友」可靠。

就算 702 真的消失，蒐集境外人士的手段也不只這一條。NSA 海外訊號情報的主要法源是第 12333 號行政命令（Executive Order 12333，EO 12333，1981 年簽署），它沒有 FISC 的司法監督，國會監督也有限，而且完全不受 702 到期影響⁶。對台灣人這類境外人士的蒐集，702 在不在都能繼續。所以 702 到期對台灣讀者該慶祝的成分有限，隱私還是需仰賴自己用加密守住，不能寄望某一條法律。

真正的防線是端對端加密¶

台灣社會大量依賴美國的雲端與通訊服務，Google Workspace、Microsoft 365、iCloud、AWS、Meta 旗下的 WhatsApp 與 Instagram 都在其中。很多人以為資料放在台灣機房就安全，但只要服務商總部在美國，美國的 CLOUD Act（2018 年通過）就能要求它交出所掌控的資料，伺服器放哪裡不影響⁷。歐盟為了同樣的問題跟美國周旋多年、打過好幾輪官司，台灣連對等的資料保護協定都沒有，處境更被動。真正有效的防線是端對端加密（E2EE），金鑰不在服務商手上，就算資料被交出、或在傳輸途中被擷取，沒有金鑰也讀不到內容，對附帶蒐集與後門搜尋都擋得住。

端對端加密保護的是通訊內容，Tor 進一步遮住連線本身。Upstream 從網路骨幹擷取流量，取得的是你連去哪、跟誰往來這類連線資訊。台灣是海島，對外連線高度依賴國際海纜⁸，通往美西、美東的跨太平洋纜線是重要幹道之一，連線只要目的地或路由經過美國骨幹，封包就落在 Upstream 的擷取範圍內。Tor 把流量加密後經多個中繼轉送，骨幹上只看得到一段加密的 Tor 流量，業者那邊也對不出真正的使用者，等於打斷 PRISM 與 Upstream 所仰賴的連線對應關係。Tor 擋得住這種大規模被動蒐集，但擋不了針對個人的主動入侵，例如利用瀏覽器漏洞去匿名化，史諾登文件裡 NSA 的 Tor Stinks 簡報就坦承，只能去匿名化一小部分使用者⁹。運作原理見什麼是 Tor。

誰的風險更高，社群能一起做什麼¶

需要跟海外編輯室、國際組織、消息來源往來的記者與公民團體，跨境通訊本來就多，附帶蒐集碰到他們的機率比一般人高，這些角色值得把防護等級拉高，敏感協作走 Tor、不要把消息來源名單放在美國企業的雲端，延伸的角色指南見記者如何保護消息來源與社運行動者的數位準備。匿名網路社群 anoni.net 把力氣放在去中心、自架與加密等靠自己的能力上，而不是等哪條法律來保障，正是因為 702 到期當天蒐集照常進行、EO 12333 也不受影響。同樣的令狀門檻問題在台灣也有自己的版本，通訊保障及監察法、科技偵查相關立法的爭議都是本地戰場，相關討論見台灣個資法 2025 修法與揭弊者保護法的技術觀察。

702 暫時失效不會讓監控立刻消失，跨境通訊的隱私風險也不會因此歸零。對每一個身在美國境外的人，真正要盯緊的是授權監控的法律結構，先確認自己在這套結構裡的位置。今天就能做的第一步，是把日常聯絡換成預設端對端加密的工具，敏感的對外連線走 Tor。

測量網路審查：挑戰、趨勢與影響

anoni.net 社群 — Tue, 21 Jul 2026 00:00:00 +0000

測量網路審查：挑戰、趨勢與影響¶

翻譯備註：這篇文章由 OONI 的 Maria Xynou 撰寫，原刊於 Internet Society 的 Pulse blog，後由 OONI 轉貼。OONI 是目前全球規模最大的網路審查觀測公開資料集，本文整理了測量網路審查的方法挑戰、近年觀察到的審查趨勢，以及觀測資料如何被用在數位人權的倡議行動。對中文讀者來說，這份脈絡有助於理解為什麼「網路看起來能用」不等於「沒有被審查」，以及為什麼台灣的網路韌性議題也需要持續的觀測資料來支撐。

以下內容原文翻譯來自：

Measuring Internet Censorship: Challenges, Trends, and Impact, Maria Xynou 2026-05-05
原始版本刊載於 Internet Society Pulse blog

重點摘要：

網路審查正在變得更精細、更具針對性，也更難被偵測。
OONI 以群眾外包方式收集的網路觀測資料，能支援研究、倡議行動，以及對網路審查事件的快速反應。
OONI 的長期資料揭示了幾項全球網路審查的關鍵走向，包括短期針對性的間歇封鎖，以及長期、系統性的壓制。

網路審查正在變得更精細、更難被偵測，「透明度」這件事比以往更迫切。

俄羅斯、哈薩克等國家正在封鎖大量獨立新聞媒體，選舉與抗爭期間針對社群媒體的限制在全球各地也越來越常見。連民主國家也在擴張審查做法。舉例來說，阿爾巴尼亞去年封鎖了 TikTok，西班牙則間歇性封鎖了部分網路，做法是針對 LaLiga 直播網站所使用的 Cloudflare 基礎設施下手。

這些案例都由 Open Observatory of Network Interference（OONI）記錄下來。OONI 是一個非營利組織，維護全球最大的網路審查公開資料集，資料來自群眾外包的測量。本文簡要討論測量網路審查的挑戰、正在浮現的審查趨勢，以及網路觀測如何推動人權倡議。

測量網路審查的挑戰¶

要判斷一件事算不算網路審查，很少能用「能不能連」、「有沒有被封鎖」這種二分結果就說明清楚。

許多因素都可能讓服務看起來無法存取，即使沒有任何人刻意限制。架在不穩定伺服器上的網站可能短暫失效，跟政府毫無關係。網路品質不佳時，使用者也可能難以開啟網站或 App。連 DNS 設定錯誤都可能造成存取失敗，但跟審查無關。

誤判（false positives）很常見。挑戰更進一步來自審查做法的多樣性，從 DNS 操縱、IP 封鎖，到更隱晦的流量限速或注入偽造回應都有。同一個網站可能在某個網路能用、在另一個網路被擋，因此需要廣泛、去中心化的測試才有機會做出可靠判斷。

OONI 用幾個方式來面對這些挑戰。一是開發公開的測量方法論並鼓勵同儕審查與專家回饋，並利用對照測量（control measurements）作為基準。OONI 也使用一套機率式指標估計某個資源在特定網路與時間區間內被限制的可能性。這套方法在 OONI Pipeline v5 上實作，會比對量測結果並套用啟發式規則，把結果分類為「blocked」、「down」或「OK」，並附上一定信心度的估計。

直接從在地網路收集到的量測，比遠端測試更有價值，因為它反映了使用者真實的審查體驗。當志工根據他們實際遇到的封鎖內容、在自己所在的脈絡下執行測試時，這些資料比較有機會捕捉到突發、情境特定的審查事件。

OONI 正是依此運作。世界各地的人們執行 OONI Probe，從他們所連的網路上貢獻量測。資料的取得仰賴志工選擇測什麼、何時、何地，因此各國的涵蓋率差異很大，同一個國家的不同網路之間也會有落差。涵蓋率不均是一項重要挑戰，要可靠地偵測（並確認）審查，需要持續的資料來累積信心。

審查事件常發生在高風險情境，例如反政府抗爭期間。在這些時刻進行測試，會讓貢獻者承擔實際的風險，也讓量測與審查偵測變得更困難。在 OONI，使用者安全是優先事項，所有貢獻量測的人都會經過知情同意的程序，在 OONI Probe App 中以小測驗的形式確認。

浮現中的網路審查趨勢¶

OONI 的長期資料揭示了幾項全球網路審查正在演變的關鍵趨勢：

網路審查的全球化與常態化¶

網路層級的審查已經不只發生在中國或伊朗這類國家。今日幾乎每個國家都有某種形式的審查，封鎖的內容與影響範圍差異很大。多數國家現在同時具備技術基礎設施與法律框架，能執行網路層的限制。

短期控制的針對性、間歇性封鎖¶

許多政府會在政治敏感事件期間部署臨時性審查，例如選舉、抗爭或衝突。這類封鎖通常針對特定網站或 App，舉例來說，烏干達在 2026 年大選後封鎖了 WhatsApp 與 Facebook。短期封鎖通常持續幾小時到幾週，這種做法能降低政治與經濟成本，又能讓當局在關鍵時刻控制公共討論、限制資訊流通。

系統性壓制的長期封鎖¶

長期封鎖會持續數年，目的是在網路上強制執行某種意識形態、政策或法律。相較於針對特定站點或 App 的短期封鎖，長期封鎖往往限制整個被視為「在法律或社會上不可接受」的內容類別。這類審查經常壓抑邊緣族群、強化既有體制。例子包括封鎖 LGBTQI 權益相關網站、族群或宗教少數團體相關內容，以及生育權相關網站。以坦尚尼亞為例，在多年針對 LGBTQI 社群的打壓之後，針對 LGBTQI 相關內容的大規模封鎖陸續被觀察到。

加密化網路中越來越不透明的審查¶

隨著越來越多網站採用 HTTPS 與加密標準，審查反而變得更不可見。傳統的封鎖頁面（block page）會告知使用者「這個站點被刻意限制」，但如今已經少見。政府改採直接干擾 TLS（Transport Layer Security）協定本身的手段，通常使用 DPI（Deep Packet Inspection，深度封包檢測）等進階設備。OONI 的資料顯示，TLS 層級的干擾在許多國家被記錄下來，也反映出全球審查技術產業正在擴張。遇到 TLS 干擾時，使用者通常只會看到一般的連線錯誤，而非封鎖頁面，因此很難分辨這是刻意的審查、還是網路故障或其他技術問題。加密化原本是要保護使用者，反過來卻讓審查變得更不透明。

流量限速與服務劣化¶

各國政府越來越常用頻寬限速作為一種較隱晦的控制手段，限制特定服務的可用性而不直接封鎖。這會讓通訊 App 或其他平台變慢，讓人不想再使用，但連線在技術上仍然「成立」。為了調查這類案例，OONI 開發了一套針對性流量限速的測量方法論，並在哈薩克、俄羅斯與土耳其的真實案例中應用與驗證。

審查與隱私技術的拉鋸¶

當局也把目標放在新興的隱私技術上。例如伊朗從至少 2020 年起就封鎖加密 DNS，而俄羅斯在 2024 年 11 月封鎖了 ECH（Encrypted Client Hello）。這些手段讓使用者更難繞過審查，同時也壓縮了線上隱私的空間。對此，OONI 開發了新的實驗來量測 ECH 與加密 DNS。這些測試已整合進 OONI Probe，世界各地的測量資料以公開資料形式即時發佈。

國家內網與「允許清單」做法的興起¶

部分政府正朝向高度控管的國家網路演進。在伊朗、俄羅斯、緬甸等國家，當局正在實驗「允許清單（allowlisting）」做法，把可存取的範圍限縮在被核准的服務或網站，實質上建立出網際網路的圍牆區。

這些趨勢都顯示審查手法越來越精細、針對性越來越強，也越來越難被偵測。要守護線上接取權與數位人權，持續的測量與倡議因此格外重要。

從測量到倡議¶

對網路進行測量，能讓我們觀察到網路流量在實務上是如何被處理的。審查經常在網路層被實作，這類測量可以揭示「什麼」被封鎖、「如何」被封鎖、「何時」被封鎖，以及是「哪一個網路」執行的。這個層級的洞察可以提供審查的證據，使得網路測量成為捍衛開放網路的有力倡議工具。

也因為這個理由，OONI 從 2016 年起就是全球 #KeepItOn 行動的活躍成員，協助全世界數百個人權組織用 OONI 資料去倡議反對網路關閉。OONI 資料因此支援了多國挑戰社群媒體封鎖的倡議行動，包括加彭、坦尚尼亞、尼泊爾、多哥與莫三比克，也用在政策與法律介入上，例如巴基斯坦與肯亞的高等法院申請案。

OONI 資料集的規模也強化了倡議價值。自 2012 年起，已從 245 個國家與地區、30,000 個網路收集到超過 30 億筆量測，OONI 資料是同類型中全球最大的網路審查公開資料集。每個月都有數千萬筆新的量測從約 180 個國家收進來，每天則持續以即時方式發佈來自世界各地的新量測。

OONI 資料是一份等待被探索的豐富資料集。它的廣度與深度能支援研究，即時發佈的特性則能支援倡議與快速反應行動。它也定期被收進 ISOC 的 Pulse Shutdown 專案用來記錄全球的社群媒體封鎖。你也可以使用這份資料，加入 OONI 社群，一起捍衛自由開放的網路。

台灣觀點¶

對照 OONI Probe 在台灣的觀測資料¶

台灣常被認為是「網路自由度高」的地區，這不代表網路層完全沒有干擾。透過 OONI Probe 在台灣固網 ISP 與行動網路上的長期測量，可以盤點是否出現 TLS 干擾、DNS 操縱或封鎖跡象，作為討論「數位韌性」議題時的本地證據。社群已經在 Tor Relays 觀測點與 ASN 觀測資料分析上累積了一部分基礎，測量者社群的規模仍然偏小，覆蓋率不足會直接影響到可信度。

反詐騙阻擋與「合理執法」的界線¶

台灣近年來陸續出現針對境外詐騙、賭博、未授權內容平台的網路層阻擋。這些措施在程序上通常透過警政、NCC 或 ISP 的合作執行，目的具有公共政策正當性，執行細節、阻擋清單、誤擋的爭議與救濟機制，往往缺乏對外可驗證的透明度。本文討論的 TLS 干擾、流量限速、加密 DNS 封鎖等手段，在民主國家也有採用，「合理執法」與「不透明審查」之間的界線必須持續被檢視。OONI Probe 等獨立觀測工具，正是讓這條界線可以被驗證的關鍵基礎建設。

在台灣推廣 OONI Probe 與測量貢獻者社群¶

中文圈的網路審查觀測資料長期偏少。台灣作為正體中文使用者的主要在地之一，有條件擔任這份補上資料的角色。可以從基礎內容在地化開始，把 OONI Probe 的安裝、安全使用、資料解讀整理成中文文件，讓有興趣的人能自己上手。長期則需要更多元的參與者，包括公民科技社群、學術網路、校園與企業內網的志工，才能累積足夠的測量涵蓋率。社群這側已經整理了 OONI 網站檢測清單，可以作為入門起點。

Android 17 上線後的 GrapheneOS：誰決定手機上能執行什麼系統

anoni.net 社群 — Mon, 20 Jul 2026 00:00:00 +0000

Android 17 上線後的 GrapheneOS：誰決定手機上能執行什麼系統¶

圖片：智慧型手機被鎖鏈纏繞，象徵裝置被外部規則鎖住。攝影 Towfiqu barbhuiya，來源 Pexels（Pexels License）。

手機是你花錢買的，但它能裝什麼、能執行什麼系統，越來越不是你能決定的。這個問題平常不會浮上檯面，直到你想換一套更保護隱私的系統，卻發現某些 app 因為「偵測到非原廠系統」而拒絕執行，或是你信任的開源系統因為得不到硬體資料而越來越難維護。Android 17 在 2026 年 6 月 16 日上線¹，把這個問題又往前推了一步。

對隱私使用者來說，首當其衝的是 GrapheneOS，一套把 Android 安全強化、移除 Google 綁定的行動作業系統。它幾乎只能運作於 Google Pixel 上，而 Google 正一步步調整 Android 與 Pixel 的開放程度，維持一套乾淨、由使用者掌握的手機系統，成本也隨之升高。

Google 兩步收緊：開發移入內部分支、Pixel device tree 移出 AOSP¶

GrapheneOS 這類系統，必須仰賴 Google 公開的 Android 原始碼與 Pixel 硬體資料才能開發。Google 接下來的兩個動作，收緊的正是這兩項來源。

第一步在 2025 年 3 月。Google 把 Android 的主線開發移進內部分支，只在版本正式發布時才把原始碼一次推上 AOSP（Android Open Source Project，Android 的開源核心），開發過程不再公開可追²。Android 仍然是開源專案，外部開發者能取得最終的程式碼，但看不到中間的演進，也更難即時跟上。

第二步在 2025 年 6 月，衝擊更直接。Google 發布 Android 16 時，不再把 Pixel 的 device tree 放進 AOSP³。device tree 是描述某款手機硬體配置、讓系統能正確驅動它的一組設定檔，對要把系統移植到該機型的人來說是地基。Google 同時把 AOSP 的官方參考裝置，從實體的 Pixel 換成虛擬機 Cuttlefish。少了 Pixel 的 device tree 與驅動原始碼，第三方系統開發者只能從 Pixel 出廠的成品檔案回頭猜它每個月的硬體改動，費時又容易出錯。

這兩步加起來，把第三方系統的開發成本墊高了一截。LineageOS（另一套知名的第三方 Android 系統）的貢獻者形容，現在等於要「盲猜，從預編譯的二進位檔反向工程 Pixel 每月的變更」³。

GrapheneOS 如期完成移植，但開發成本持續升高¶

即使如此，GrapheneOS 在 Android 17 發布當天（2026 年 6 月 16 日）就完成移植⁴。過程中遇到 Android 17 本身一個影響 recovery 側載的上游 bug，第一版 build 因此沒有直接推送，修正後的版本 2026061800 在 6 月 18 日進入 Alpha 測試通道⁴。

移植速度沒有變慢，展現了 GrapheneOS 的工程能力。但每一代要付出的反向工程成本都在增加，而成本的增加來自 Google 政策的單方面決定。一個原本可以靠公開資料順暢進行的工作，現在需仰賴逆向工程填補缺口。GrapheneOS 能維持這樣的移植速度多久，取決於 Google 後續是否繼續縮減公開資料的範圍。

另一種壓力：attestation 將非官方系統判為不合格¶

除了開發端，GrapheneOS 還面對使用端的壓力，來源是 attestation（裝置認證，由 app 在背景檢查你的手機是不是「原廠認可」的狀態）。

Google 的 Play Integrity API 會把非 Google 認證的系統判為不合格。GrapheneOS 在安全上比原廠 Android 更嚴格，卻因為不是 GMS（Google 行動服務）授權的系統，常被當成被 root（取得最高權限、繞過系統限制）的手機一併拒絕執行。越安全的系統，反而越容易被這套機制排除在外。

attestation 的壓力在 2026 年明顯增強，下面三件事幾乎同時推進：

Microsoft Authenticator：2026 年 2 月底起，開始對 Android 裝置做 root 偵測，GrapheneOS 因為被 Play Integrity 標記而受影響。Microsoft 分三階段推行（先警告、再擋新增帳號、最後清除既有憑證），計畫在 2026 年 7 月完成最後階段，清除受影響帳號的 Entra 憑證⁵。截至本文撰寫的 6 月，這個期限還沒到、是否如期執行未知。Microsoft 也公開表示不支援 GrapheneOS。
歐盟 Unified Attestation：歐盟版的統一裝置認證提案，GrapheneOS 認為這是 Play Integrity 的歐洲翻版，會把非授權系統一樣擋在 app 生態圈外，已公開呼籲隱私導向的 app 開發者抵制⁶。
Android 17 的側載限制：Android 17 新增應用程式側載的「開發者驗證」流程，2026 年先在巴西、印尼、新加坡、泰國試行，2027 年擴大到更多地區⁷。

這些機制各有各的理由（防詐騙、防濫用、青少年保護），但效果相互疊加，使未獲官方認可的系統越來越難用於日常。

Motorola 合作與 Pixel 的不確定未來¶

面對 Pixel 的不確定，GrapheneOS 開始找替代硬體。2026 年 3 月 1 日的 MWC 2026，GrapheneOS 與 Motorola 宣布長期合作，計畫推出預載 GrapheneOS、支援 bootloader 解鎖與重鎖的機型⁸。這是 GrapheneOS 第一次把硬體出路鋪到 Pixel 以外，具體機型與上市時間官方都還沒公布。

回頭看這次合作的起因，GrapheneOS 表示，正是 Google 停止公開 Pixel 共用的驅動程式原始碼，才促成 Motorola 主動接洽⁹。Google 想把 Android 收得更緊，反而把一個原本綁在自家硬體上的專案推向了競爭對手。

至於 Pixel 本身，GrapheneOS 的說法是「不確定之後還會不會替新推出的 Pixel 加上支援」¹⁰。媒體據此推測 Pixel 11 可能是最後一款受官方支援的新 Pixel，但那是媒體的推論，GrapheneOS 官方並沒有做出這個承諾，Pixel 11 之後的機型是否支援仍在未定之天。

誰決定手機上能執行什麼系統¶

Google 收緊 AOSP、用 Play Integrity 決定哪些系統合格，Microsoft 跟著把不合格的系統排除，歐盟研議自己的認證框架，Android 17 要求側載先過驗證。這些機制累加下來，你手機上能執行什麼系統、能裝什麼 app，能自己決定的部分越來越少。

這跟我們在從 Discord 年齡驗證談起：我們為什麼自架 Matrix 與金融公司當起審查者談過的是同一類問題。當關鍵的基礎設施掌握在少數平台手中，規則由它們單方面決定，一般使用者難以參與，也難以脫離。手機作業系統是其中最貼身的一層，定位、通訊、相簿與身分都存在這一層上。

GrapheneOS 的價值，就在於它讓使用者在原廠系統之外仍然有選擇。它不完美，依賴 Pixel、可能被部分 app 拒絕執行、需要一定的學習成本，但它證明了這件事在技術上可行。

對台灣與正體中文使用者的意義¶

上述變化看似都在美國的 Google 與歐盟法規層面，但離正體中文使用者並不遠。

Android 17 的側載驗證，2026 年第一批試驗場就包含印尼、新加坡、泰國，APAC 是最早被納入的地區之一⁷，這類政策後續往鄰近地區擴大並不意外。另一個更切身的壓力是 attestation。台灣的網銀、行動支付、政府服務 app 越來越常檢查裝置是不是原廠狀態，對把手機當主要上網工具的在地使用者，選用 GrapheneOS 這類系統前，要先確認自己每天必用的 app 是否仍能正常執行。

如果你關心能不能擁有一台真正由自己掌握的手機，GrapheneOS 是現在最成熟的選項，也是觀察 Google 後續動向最直接的視角。Google 接下來的每一步，都會影響 GrapheneOS 作為可行選項還能維持多久。

進一步了解 GrapheneOS¶

這篇文章聚焦處境與脈絡。GrapheneOS 本身是什麼、有哪些隱私與安全設計、為什麼只支援 Pixel、跟匿名工具的界線在哪，整理在 GrapheneOS：高度隱私的行動作業系統。操作前也建議先讀威脅模型如何建立與匿名與隱私的差別，釐清自己真正的需求，再評估 GrapheneOS 是否適合自己。

Android 17 release | Android Open Source Project - Android Open Source Project ↩
Google will develop the Android OS fully in private going forward - 9to5Google ↩
AOSP isn't dead, but Google just landed a huge blow to custom ROM developers - Android Authority ↩↩
GrapheneOS has been ported to Android 17 and official releases are coming soon - GrapheneOS Discussion Forum ↩↩
Microsoft tightens Authenticator checks on Android and iOS - The Register ↩
GrapheneOS calls on privacy-focused app developers to boycott European Unified Attestation - PiunikaWeb ↩
Android sideloading changes: here's the full timeline - Android Authority ↩↩
Motorola confirms GrapheneOS partnership for a future smartphone - 9to5Google ↩
GrapheneOS explains Motorola partnership origin & the uncertain future of Pixels - PiunikaWeb ↩
Pixel 11 could be the last new Pixel to gain GrapheneOS support - PiunikaWeb ↩

OONI 如何分辨壞掉的量測資料：從啟發式規則到匿名憑證

anoni.net 社群 — Fri, 17 Jul 2026 00:00:00 +0000

OONI 如何分辨壞掉的量測資料：從啟發式規則到匿名憑證¶

本文是 anoni.net 對下面這篇 OONI 工程文章的導讀與摘要，帶你逐節看懂原文在做什麼，不是逐字翻譯。原文另有約 20 張統計圖與多份完整資料表，想看數據細節請直接讀原文：

From Heuristics to Anonymous Credentials: Assessing OONI's Approach to Bad Measurements, OONI 2026-07-06

很多人靠 OONI 的公開資料集，判斷「某個網站在某個國家連不連得上」，anoni.net 自己的台灣 ASN 涵蓋觀測也建立在同一份資料上。只要有人往裡面灌假資料，或裝置設定錯誤產生誤導性的紀錄，整份資料的可信度就會被稀釋。OONI 在最近一篇工程文章¹裡完整說明，他們如何找出壞掉的量測，以及新上線的匿名憑證（anonymous credentials）系統如何在不儲存個資的前提下擋掉濫用。「不留個資也能評估誰值得信任」的做法本身就是值得社群參考的隱私工程範例，後面第五節會回頭談。

OONI（Open Observatory of Network Interference，開放網路干擾觀測站）是一個全球的網路審查觀測專案，手機 app OONI Probe 會連上一份網站清單，回報每個網站在當地連不連得上，結果一律進到公開資料集。任何人都能下載這份資料做分析，好處是開放，代價是任何人也都能往裡面送資料。這篇文章要回答的問題，就是在開放投稿的前提下，如何辨認並過濾掉品質有問題的量測。

這篇文章想解決的問題¶

OONI 想先用手上已經有的資料，建立一套辨認壞量測的基準，再看新的匿名憑證系統能把基準往上推多少。啟發式（heuristic）是一組簡單、成本低的判斷規則，不追求百分之百準確，先用幾條經驗法則把可疑的量測篩出來。全文分成三大塊：先用簡單規則檢查既有資料能揪出多少問題（既有啟發式與四類發現），再想能補上哪些更進階的規則（新啟發式），最後處理找到壞資料之後要用什麼機制因應（緩解策略與匿名憑證）。

一、既有的指標與啟發式（Existing metrics and heuristics｜Approach & Methodology）¶

這一節先不動用任何新技術，只問一件事：光靠 OONI 現在就收得到的資料，能不能認出壞掉的量測？他們挑了四個不需要犧牲使用者隱私的檢查角度：IP 地理位置對不上、量測數量暴衝、時間戳記兜不攏、作業系統與版本資訊互相矛盾。每個角度原文都附了但書（caveat），說明什麼情況下該訊號會誤判。例如 probe 內建的 GeoIP 資料庫可能過期，導致 probe_cc（probe 回報的國碼）本來就會跟真實 IP 對不上，分析時要先把正常誤差濾掉。四個檢查角度加上各自的但書，構成後面所有發現的方法論基礎。

二、四類異常的實際發現（Assessment & Findings）¶

把上面四個角度實際套到資料上，得到四組發現。

IP 地理位置對不上¶

OONI 在 2025 年 3 月 19 到 21 日，於 probe 呼叫 /api/v1/check-in 端點時記錄 log，比對 probe 自己回報的國碼、ASN（自治系統編號）跟收集端看到的真實出口 IP。16,139 筆樣本裡有 1,196 筆對不上，約 7.41%。原文列出最常見的 10 組國碼錯配（回報國碼對照真實 IP 所在國碼）：

回報國碼	真實 IP 國碼	筆數
US 美國	CA 加拿大	89
CA 加拿大	RU 俄羅斯	49
CZ 捷克	US 美國	43
BS 巴哈馬	US 美國	36
CA 加拿大	US 美國	30
CA 加拿大	SG 新加坡	30
CZ 捷克	GB 英國	25
CA 加拿大	KH 柬埔寨	18
AU 澳洲	KH 柬埔寨	18
US 美國	DE 德國	16

追下去發現絕大多數對不上的來源是 VPN。出現最多的供應商是 Datacamp、Cloudflare、M247 等已知的 VPN 機房，其中「回報加拿大、真實 IP 在俄羅斯」那 49 筆全部來自 Cloudflare，對應的是用 WARP 這類 VPN 的使用者。表格裡多數組合都是同一個道理，probe 以為自己在 A 國，真實流量卻從 B 國的 VPN 出口冒出來。結論是國碼錯配幾乎都跟 VPN 有關，沒有看到明顯可歸因於惡意竄改或 probe 設定錯誤的量。

量測數量暴衝¶

他們看每個 probe 在 1 分鐘內產出多少筆量測，正常的平均是 8 筆，99 百分位是 54 筆。篩出每分鐘超過 200 筆的極端案例後，發現一個自稱 ooniprobe-react-os、並非 OONI 官方發行版本的用戶端。它只針對 probe_cc = CN（中國）送資料，以每分鐘 200 筆（相當於每秒 3 筆）的速度送出 web_connectivity 量測，速率遠超正常範圍。更反常的是，ooniprobe-react-os 送出量測的速度比同地區其他 probe 還快，量這麼大卻沒有出現對應的網路瓶頸。另一個案例是緬甸在 2025 年 1 月 6 日出現的陣發性暴衝。

時間戳記兜不攏¶

比對量測開始時間 measurement_start_time 跟 measurement_uid 裡內含的時間戳，看有沒有「太晚上傳」或「時間來自未來」的紀錄。2025 年 3 月 2 日到 4 月 1 日這段，3,440 多萬筆量測裡只有 0.82% 有時間異常，多數是過去、集中在 Linux。原文依平台拆解如下，Linux 的異常率 2.16% 明顯高於其他平台：

平台	過去異常（>1h）	未來異常（>1h）	異常合計	該平台總量	異常率
ios	2,375	0	2,375	240,843	0.99%
windows	34,192	24,938	59,130	10,503,040	0.56%
android	21,132	5,509	26,641	10,389,320	0.26%
macos	906	0	906	3,103,961	0.03%
linux	185,322	7,908	193,230	8,947,716	2.16%

這裡有一個很具體的例子：大量異常來自委內瑞拉同一個 ASN，OONI 聯絡上當地夥伴後發現，是那批裝置的時區被設錯了。把委內瑞拉排除後，Linux 的異常數字大幅下降，其他平台幾乎不變。設定錯誤就足以產生誤導性的紀錄，不必然是惡意。

作業系統與版本資訊互相矛盾¶

檢查軟體名稱跟平台兜不兜得起來，例如 software_name = ooniprobe-android 卻標成 iOS。找到 718 筆 Android 軟體運作於非 Android 平台上，其中一部分追出來是 OONI 團隊成員自己開發用的機器，另一部分又是前面那個中國來源的 ooniprobe-react-os。他們也列出幾個沒見過的軟體名稱（Vladhog、murakami-ooniprobe、MySorgenia、Dismantle 等），逐一查證是什麼來路。很多看起來可疑的資料，多半來自開發過程或第三方 fork，跟攻擊無關。

四類發現合起來給出一個讓人安心的結論：OONI 目前沒有在資料裡找到大量惡意污染，絕大多數異常來自 VPN、設定錯誤、開發機器或非官方分支。防禦機制要做，但威脅目前不是迫在眉睫的大規模攻擊。

上面的結論對我們有直接意義。anoni.net 的台灣 ASN 涵蓋分析、Tor Relay 觀測點都建立在 OONI 公開資料上，看到源頭沒有被大量污染，用起來可以比較放心。同時四類發現也提醒我們，讀 ASN 資料時 probe_cc 不等於當地實際的連線狀況（ground truth）。VPN 造成的地理錯配、時區設錯這類雜訊本來就存在，做分析時要記得先濾掉。

三、想再補上的新啟發式（New heuristics）¶

既有規則之外，OONI 想再加幾種更進階的偵測。定位一直是最大的難題，因為 GeoIP 資料庫由 probe 自己查、又會過期。他們考慮的補強包括：向手機作業系統取得行動網路的國碼與電信商代碼（MCC/MNC）、詢問作業系統的定位服務、或改在伺服器端做 IP 到地點的對照。每種做法原文都附了限制，例如伺服器端對照會被翻牆工具擋在中間、看不到真實 IP，問定位權限則可能引起使用者疑慮。另外還想加上網路層與協定層的異常偵測，例如從 TLS 交握的指紋認出中間人設備（像是改寫流量的防毒軟體）。

四、找到壞資料之後如何處理（Strategies for mitigating faulty measurements）¶

偵測只是第一步，接下來是處置。OONI 定了兩條原則。第一，最終判定一筆量測是不是壞資料，要有人類審查介入，避免自動化把好資料誤殺。第二，除非牽涉使用者隱私，否則絕不回頭修改已經送進來的資料。因為要有人類把關，處置只能在壞資料已經進入資料管線之後才做。可用的手段包括封鎖行為異常的假名（pseudonym）、對投稿做限流、動態調整某地區某時段能接受的投稿量、或輪換簽發金鑰。這裡的假名是匿名憑證系統給「同一個網路裡的一台 probe」的識別，同一網路內固定、跨網路無法被串連，也對應不到某個人的真實身分，第五節會說明它如何做到。文章也誠實點出兩難：如果規定「只有半年以上的 probe 才能投稿」來擋 sybil 攻擊（大量假身分灌資料），也會連帶影響到正常新 probe 的投稿。

五、匿名憑證系統如何運作（Assessing the effectiveness of the solution）¶

匿名憑證系統是整篇的重點。先看「土法煉鋼」的做法會遇到什麼坑：給每個 probe 一個 ID、伺服器端做白名單。問題是就算隨機 ID，只要固定不變就足以辨識出單一 probe，本身就是隱私災難，而且 probe 換一個新 ID 就能繞過，變成打地鼠。如何在不長期儲存個資的前提下，同時做到存取控制與信任評分，就成了這套系統要解決的核心矛盾。

這套機制用一個生活化的比喻就好懂。像酒吧門口只要你出示一張「證明我已成年」的證件，店員確認過關就好，不需要知道你叫什麼、住哪裡、生日是哪天。OONI 的憑證則用來證明另一組事情，這台 probe 的資歷夠老、投稿數量夠多。

憑證由伺服器簽發，只存在 probe 本地、不存在伺服器，也不會再次外傳。它用密碼學把 probe 的資歷（age）與投稿數（msm_count）編碼進去，而且只證明落在某個「區間」，例如「投稿超過 1000 筆」、「存在超過一週」，不透露精確值。用區間而非精確數字是刻意的設計，因為精確的投稿數幾乎是獨一無二的指紋，會反過來讓 probe 被認出來，粗略的區間才不會洩漏身分。

投稿時，probe 用憑證產生一段零知識證明（一種只證明某件事為真、但不透露細節的密碼學方法），伺服器只看到證明本身、看不到底下的真實數值，就能判斷該筆量測符不符合存取規則，例如「某個國家、某個 ASN 的 probe，要投稿滿 1000 筆才收」。信任分數還會鎖定在特定的國碼與 ASN 組合，一台 probe 在某個網路累積的信譽，不能跨到另一個網路使用，用意正是防止有人在低門檻網路先養好憑證、再拿去攻擊別的網路。

具體走一遍的流程如下：一台全新的 probe 一開始資歷淺、投稿數低，很多嚴格規則都還進不去，只能先老實執行量測。每投一筆，伺服器在驗證通過後回一張更新過的憑證，把投稿數往上加一。日子久了、量累積夠了，這台 probe 跨過「滿一週」、「滿 1000 筆」的門檻，之後送的量測就能被標成 verified。整個過程裡，OONI 從頭到尾沒取得它的固定 ID，也沒存下任何個資。

那有人會問，既然憑證只存在 probe 本地，複製一百份不就能假裝成一百台各有信譽的 probe？關鍵在前面說的網路內固定這個性質。同一個網路裡，同一份憑證推導出來的假名是同一個，複製再多份，在同一個網路裡仍然被看成同一台 probe，不會變成一百個各自獨立的可信身分。OONI 也很坦白，光靠憑證不能完全解決 sybil 攻擊，徹底的防禦要靠應用層的手段，例如限制新帳號註冊速率、對每個區域的投稿量設上限。憑證的作用是提高攻擊成本，逼對手先養出一批夠老、送過夠多量測的 probe，沒那麼容易。

每筆量測最後會被標成 verified、unverified 或 failed 三種狀態，資料使用者可以自己決定要採信到什麼程度。這套系統上線後，有些效果要長期觀察才看得出來。OONI 會持續追蹤 verified、unverified、failed 三類量測的比例變化，用來診斷是不是某次用戶端更新讓協定實作出現錯誤、或老 probe 沒更新。他們也會統計各協定版本的 probe 數量，以及在伺服器端執行一筆驗證要花多少時間，及早抓出效能退化。

回到社群的角度，這套系統對 anoni.net 讀者的價值不只在 OONI 自己。「如何在不儲存個資的前提下做存取控制與信任評分」是很多系統都會遇到的難題，OONI 用區間揭露、憑證只存本地、放棄精準封鎖來換取匿名性，這套取捨思路對關心隱私設計的人是很好的教材，也呼應我們社群個人隱私指引的主題。

小結：這份資料能不能放心用¶

OONI 的公開資料目前沒有被大量惡意污染，看到的異常多半來自 VPN、時區設錯、開發機器這類無心之過，可以放心繼續用它來理解台灣與各地的封鎖狀況。想更深入匿名憑證背後的密碼學，OONI 另有兩篇姊妹文可以接著讀：一篇談這套系統的設計需求²，一篇宣布系統上線³。

原文十個大節回顧¶

看完全文，這張表把原文十個大節的重點與關鍵數字收在一起，方便日後回查或跳讀。

原文大節	重點	關鍵數字或結論
Existing metrics and heuristics｜Approach	用既有資料建立偵測基準	四個不犧牲隱私的檢查角度
IP geolocation mismatches	probe 回報位置對照真實 IP	7.41% 對不上，多數是 VPN
Measurement volume anomalies	單一 probe 投稿速率暴衝	中國 `ooniprobe-react-os` 每秒 3 筆
Timestamp inconsistencies	量測時間戳前後兜不攏	0.82% 異常，委內瑞拉時區設錯
Probe OS, version metadata	軟體名稱與平台互相矛盾	718 筆，含團隊開發機
New heuristics	想再補上的進階偵測	MCC/MNC、伺服器端 GeoIP、TLS 指紋
Mitigation strategies	找到壞資料之後的處置	人類把關、不回改、限流、擋 sybil
Naive solution	土法煉鋼會踩的坑	固定 ID 就能去匿名，還會變打地鼠
Anonymous credentials solution	憑證式信任評分	區間揭露、只存本地、沒有固定 ID
Future validation	長期驗證指標	追蹤 verified/unverified/failed 比例

名詞對照¶

原文用了不少 OONI 專有欄位名詞，這裡整理一份對照，方便對照原文閱讀。

名詞	說明
啟發式（heuristic）	一組簡單、成本低的判斷規則，不追求完美，先把可疑的量測篩出來
OONI Probe	OONI 的手機與桌面 app，會去連一份網站清單、回報每個網站在當地連不連得上
probe	執行量測的裝置或程式
`probe_cc`	probe 回報的國碼（country code）
`probe_asn`	probe 回報的 ASN
ASN	自治系統編號（Autonomous System Number），一段 IP 位址的管理單位，通常對應一家 ISP 或機構
`msm_count`	該 probe 累積投稿的量測數（measurement count）
check-in 端點	probe 開始量測前呼叫的 API，會回報自己的國碼與 ASN
`web_connectivity`	OONI 最常見的測試，測某個網站在當地連不連得上
ground truth	當地實際的連線狀況，拿來跟 probe 回報的資料對照的「真實答案」
sybil 攻擊	用大量假身分灌資料、扭曲觀測結果的攻擊
pseudonym（假名）	匿名憑證下代表「同區域、同 IP」一群 probe 的識別，不是個人身分 ID
verified、unverified、failed	匿名憑證系統給每筆量測的三種信任標記