仓库指标
- Star
- (45 star)
- PR 合并指标
- (PR 指标待抓取)
描述
這份 issue 想做什麼
這是一份徵詢提案，不是已拍板的計畫。我們想先把一個測量模式的想法與後續做法，攤開給社群夥伴與 OONI 團隊成員看，收集回饋後再決定啟用時機。這個測量模式是台灣公民連線層觀測倡議的一部分，這份 issue 先聚焦在測量模式本身。
簡單講：社群自己維護一份我們關心的台灣公民團體網站名單，檢測方法與資料都接回 OONI。
背景與動機
OONI Probe 每次檢測都依據一份事前列舉的網站清單。台灣的清單由 Citizen Lab 維護在 test-lists 的 tw.csv，大多 2017 年建立，之後幾乎沒有持續維護，許多項目已停運、換網址，或仍是 http://。社群在 2023/09 送過一次大規模整理（PR #1444）。
那次經驗帶來一個重要提醒：研究員指出，對共享清單大幅更改（刪除、替換）會讓既有網址的測量時間序列出現斷層，影響長期分析。我們想找一個做法，既能彈性維護我們關心的名單，又不會破壞共享清單的長期基線。
提出的模式：社群名單為 SoT、OONI 為測量與資料層
把系統拆成兩層：
- 社群 git repo = 名單的 single source of truth。我們關心的組織清單、分類、徵詢狀態與敏感分級放在自己的版本控管裡。git 歷史本身就是清單治理紀錄。
- OONI = 測量引擎 + 公開資料層。用標準 web_connectivity 方法檢測，結果進 OONI 公開資料集，可用 OONI API 與 Explorer 查詢、研究員可引用、沒有資料鎖定。
這個模式本質就是 OONI Run v2 的一級用法。我們維護自己的清單，用 OONI 的方法測，資料回到 OONI 的公開資料集。
為什麼這樣設計
- 解掉斷層問題。我們完全不去 churn 共享的
tw.csv，斷層只發生在反覆改動共享清單。連續性變成我們自己掌握的事。 - 保留互通與公開性。測量進 OONI 公開資料集，任何研究員都能用同一套 API 撈、引用、驗證，跟既有的 ASN 涵蓋分析無縫接軌。
- 社群掌握治理節奏。名單的新增、徵詢、敏感分級由社群依在地脈絡決定，不必等共享清單的審查週期。
檢測怎麼接回 OONI
我們打算用 自營測量點 + 志工 Run v2 並用 的方式：
- 由社群名單產生一條 OONI Run v2 連結（descriptor 由名單生成）。
- 志工手機：裝這條 Run v2 連結，補住宅與行動網路 ASN 的廣度。
- 自營節點：在社群自己的 VPS 或 RPi 上跨 ASN 跑 ooniprobe（oonirun 模式吃同一條連結），當每日連續的測量骨幹。
志工與自營節點消費同一條連結，所有測量都帶同一個 OONI Run Link ID，方便在 OONI Explorer 與 MAT（aggregation API）統一過濾與聚合。dashboard 用 Run Link ID 加 ASN 加 input 切圖（沿用既有 Vega-Lite + ASN Coverage 框架）。
跟 Citizen Lab tw.csv 的關係
tw.csv 從必要路徑降為可選加值。成熟、穩定、明確在範圍內、非敏感的知名倡議組織，仍可用 additive 方式（只新增、幾乎不刪、附正確 category code）回饋到 tw.csv，換取全平台與全 TW probe 的長期基線。敏感族群的組織一律不進公開的 tw.csv PR（GitHub 是永久公開紀錄），只留在社群自管的清單與 Run v2。
這也對齊 OONI 官方使用指南的建議：「if some of the websites that you used for OONI Run links are relevant for country-wide testing, please propose them for the test lists tested by all OONI Probe users」。
想徵詢的問題
給 OONI 團隊：
- 用自維清單 + Run v2 + 選擇性 additive 回饋
tw.csv這個組合，有沒有要提醒我們的地雷？ - 自營節點在 server 上跑 oonirun 模式並交回 collector，有沒有建議的最佳實踐（版本、頻率、annotation）？
- category code 歸類、哪些適合進 global vs local 清單，有沒有 TW 既有脈絡要注意？
- 未來若測量量起來，是否有興趣在資料分析或對外溝通上合作？
給社群夥伴：
- 自營節點的落點：誰能在哪個 ASN（中華電信、台灣大、遠傳、固網、第二類電信、機房）提供一台長跑的節點？
- 名單治理：收錄標準、徵詢流程、敏感分級的審議要怎麼運作？
- 有沒有想優先觀測的組織或網站類型？
時程與下一步
這個專案尚未啟用。先在這份 issue 收集社群與 OONI 的回饋，確認模式可行、沒有踩到地雷後，再排啟用時程。歡迎在底下留言，或到 Matrix 的 anoni-net 公開空間討論。
參考
- OONI Run 使用指南：https://ooni.org/support/ooni-run/
- OONI Partnership Program：https://ooni.org/get-involved/partnership-program/
- Citizen Lab test-lists：https://github.com/citizenlab/test-lists
- 既有名單說明：anoni.net/docs 的 OONI 網站檢測清單頁
English summary (for OONI team)
TL;DR: A Taiwan civil-society community plans to maintain its own curated list of NGO/advocacy websites, and drive reachability measurement through OONI rather than churning the shared Citizen Lab tw.csv. The community git repo is the single source of truth for the list; OONI is the measurement engine and public data layer.
Why: tw.csv for TW has been largely unmaintained since 2017. A past large cleanup (PR #1444) prompted feedback that heavily editing the shared list breaks longitudinal continuity for existing URLs. By keeping our list in our own repo and measuring via an OONI Run v2 link, we avoid churning the shared list while keeping all data in OONI's open dataset (queryable by Run Link ID).
How we measure: one OONI Run v2 link generated from our list, run by (a) volunteer phones for residential/mobile ASN breadth and (b) self-operated vantage points (ooniprobe in oonirun mode on cron) for a continuous daily backbone across target ASNs. All measurements share one Run Link ID.
tw.csv role: optional, additive-only contributions of mature, non-sensitive orgs for the cross-platform baseline. Sensitive orgs stay out of the public PR.
Questions for OONI: (1) any pitfalls with this self-maintained-list + Run v2 + selective additive tw.csv model? (2) best practices for running oonirun on server-side vantage points (version, cadence, annotations)? (3) guidance on category codes and global-vs-local placement for TW? (4) interest in collaborating on data analysis or communication if volume grows?
We are not launching yet — this issue collects feedback from our community and the OONI team first.