不足
RiseupVPN
按月付費
— 無月付方案
按年付費
— 無年付方案
涵蓋範圍
4 設有出口的國家
免費方案
有 免費,無流量上限
安全
易用性
<b>RiseupVPN</b>經HushFleet團隊評估,被歸入<b>不足</b>區間,安全分數為<b>25/100</b>,易用性分數為<b>65/100</b>。 在VPN業者安全總排名中位列<b>68家中第7</b>。 反審查工具,公司管轄地為<b>美國</b>。 接受過獨立安全稽核:報告全文已公開,證據層級<b>A</b>。
有7個欄位出現在此紀錄中,但不計入分數,這一點契約本身在欄位中已註明:scored: false。之所以列出它們,是因為讀者若詢問這家公司歸誰所有、稽核由誰簽署,紀錄本應回答這些問題 — 而且從不參與運算的值,理應明確置於運算之外,而非悄悄混入其中。
業者在自家伺服器頁面上列明的、設有出口的每一個國家,共計:4個。此處不提供各國伺服器數量,站內任何地方也不會公布總伺服器規模 — 因為契約本身並不包含這兩項資料,而一個無法溯源的數字,比缺失資料更糟。標有mandate的0個國家實行資料留存義務;該標記來自方法論自身的國家清單,而非業者。
替代方案
不足
按月付費
— 無月付方案
按年付費
— 無年付方案
涵蓋範圍
4 設有出口的國家
免費方案
有 免費,無流量上限
安全
易用性
| 服務類別 | 反審查工具 — 以安全為先 |
|---|---|
| 安全分數 | 100分中的25分 · 不足 |
| 易用性分數 | 100分中的65分 · 狀態已知 · 已確認64% · 已讀取77.4%的權重 |
| 法律實體 | Riseup Networks |
| 管轄地 | 美國 |
| 最終所有者 | Riseup Collective (self-governed autonomous collective; no external owner) |
| 暴露度 | 中 · 主導通道:留存 |
| 留存 | 沒有任何可將流量連結至個人的資料 |
| 最近一次稽核 | Security Research Labs (SRLabs) · 2025年5月16日 · 一次性 · 有,且報告已被閱讀 |
| 設有出口的國家 | 4 |
| 通訊協定 | OpenVPN混淆通訊協定 |
| 在嚴格審查環境下仍可使用 | 自稱可運作 |
| 目前仍提供的最弱協定 | 不適用 |
| 通道內自有DNS | 未知 |
| 平台 | LinuxmacOSWindowsAndroid |
| 同時使用裝置數 | 未知 |
| 斷網保護 | 僅限桌面平台 |
| 分流通道 | 未知 |
| 註冊方式 | 不需要帳戶 |
| 免費方案 | 沒有資料上限的免費級別 |
| 允許P2P | 未知 |
| 可存取主流串流服務 | 未知 |
| 價格(月付) | 未公開 |
| 價格(年付) | 未公開 |
| 所提供而受留存義務約束的國家C09_mandate_countries | |
|---|---|
| 最終實益擁有人所在國家M11_owner_jurisdiction | US |
| 所有者集團叢集鍵M15_owner_group | 獨立 |
| 現任所有者取得控制權的日期M16_control_since | 不適用 |
| 此品牌在集團內的角色M17_brand_role | principal |
| 與叢集內同系品牌共用的基礎設施M18_shared_infrastructure | separate |
| 已公開稽核總數V10_audit_count | 1 |
八個通道,每個都向公開紀錄提出一個問題,並讀取一組指定欄位來回答它。它們是相乘而非相加 — 通道旁的係數是扣除目前為止發現的壓力後所剩的部分,展開一個通道即可看到它讀取的每一個欄位,均按儲存原樣顯示。模型如何運作
安全欄位
67 其中55個進入某個通道
已確認
51 6個仍為unknown,10個不適用
完整度
88% 模型能夠賦權的比例
引用
71 涉及18份文件
每個值都帶著它所依據的根據,模型對四個層級賦予不同的權重。先看權重,再看這筆紀錄在該層級上有多少引用:
A 權重1.00·此處<b>12</b>項B 權重0.85·此處<b>59</b>項
權重由methodology.json自身設定;在文件本身中確認的說法,比二手轉述的同一說法更有分量。列末的日期是該值最後一次被讀取的日子。
通道並非對它讀取的每個欄位都計分。計分的欄位會在邊緣標出,並顯示其貢獻值;其餘的只是被讀取,不產生任何成本。只有逐欄位累加的通道才能標記欄位 — 其餘通道依據列上方列出的參數為自身計分。
此紀錄目前仍未解決的事項。
沒有說明硬件擁有權。 Riseup 自身的政府常見問題解答描述其西雅圖核心基礎設施由自身實體控制(「並非託管於雲端」),但沒有說明位於蒙特利爾、巴黎及阿姆斯特丹的 VPN 閘道機器,而這些機器位於商用主機常見的 IP 範圍內。C08_servers_ownership 維持未知,而不是從西雅圖的說明作出推定。
最低限度的 VPN 紀錄只以排除方式描述。 安全頁面列出 5 天輪替紀錄不包含的所有項目(沒有 IP、沒有指紋、沒有 DNS 請求、沒有元資料),但從未說明它包含甚麼。C01 根據這份排除清單填為 none_linkable,但想知道這些位元組實際是甚麼的讀者,將無法在此找到答案。
數個易用性欄位完全沒有可供查閱的文件。 在本次找到的任何 RiseupVPN 頁面上,都沒有提及分割通道、同時使用的裝置上限、P2P 政策及串流存取權限,而終止開關僅確認適用於桌面系統匣用戶端,並未確認適用於 Android。
唯一的獨立稽核是用戶端/基礎設施滲透測試,而不是紀錄稽核。 2025 年 SRLabs 報告檢查了 Bitmask 及 Menshen 橋接器註冊器的攔截及 DPI 風險;報告從未查問 VPN 伺服器保留甚麼,因此 V11_audit_findings 為 not_stated,而 C01 中的留存聲稱單獨建基於 Riseup 自身的說法。
常被引用來指責 Riseup 的 2012 年查封事件並未涉及 Riseup 自身的資料。 美國聯邦特工從 Riseup 與 May First/People Link 共用的一個共置設施取走一部伺服器,但該機器及其資料屬於第三方租戶 European Counter Network;其中沒有任何 Riseup 帳戶或用戶資料,這就是為何 P01_seizure_event 顯示為 none_known,而不是把一宗從未需要由 Riseup 抵抗的事件算在其身上。
針對整筆紀錄。
RiseupVPN 是 Riseup Networks 的免費用戶端;Riseup Networks 是一個自 1999 年起營運的美國 501(c)(4) 非牟利集體(riseup.net)。VPN 本身不收取費用,完全靠捐款維持,因此 U04/U04b 為 not_applicable。RiseupVPN 是較舊的 Bitmask/Riseup-Black 用戶端的重新品牌版本,建基於 LEAP 平台;其四個閘道(西雅圖、蒙特利爾、巴黎、阿姆斯特丹)均位於 countries.csv 所列設有留存義務的國家,而當地的託管屬實體而非虛擬。
並非相加而是複合而成:以silent分支上的先驗值0.55為起點,依據文獻所述(0.1026)與實際做法所示(0.0)調整,再乘以稽核帶來的可信度0.1026與業者配合度帶來的0.665,最終針對實際留存內容的嚴重程度0.03計分。
業者持有的持久裝置識別碼C12_device_identifier
none
Briseup.netBplay.google.com2026年9月13日
舉報C12_device_identifier的問題公司所在地0.0,所有者所在地0.0,提供的出口0.0,秘密命令制度0.2 — 作為一種情形,只計一次,不疊加。
在其所提供的受留存義務約束國家設有主機C09b_mandate_hosting
不適用
Bapi.black.riseup.net:4432026年9月13日
舉報C09b_mandate_hosting的問題該通道在此紀錄上計分的內容:事件處理 0.2
自稱與行為之間有紀錄的落差X01_documented_lie
none
為空白本身計分:加權紀錄中已確認的比例為0.88,在上限0.6之下按斜率0.9計算,並因0.4的緩解而減輕姿態0.25。
紀錄完整度S08_completeness
88%
由紀錄自身推導得出
實際披露紀錄P02_disclosure_history
account_data_disclosed+0.088
Briseup.net2017年2月
舉報P02_disclosure_history的問題法庭紀錄顯示被強制提供資料同時被沉默讀取P03_court_record
produced_account_data+0.088
Briseup.net2017年2月
舉報P03_court_record的問題有上限的總和 — 唯一相加的通道:來自下方標記欄位,佔可能上限0.28中的0.07。
毋須電郵即可註冊C04_signup_no_email
yes_declared+0.005
Briseup.netBriseup.net2026年9月13日
舉報C04_signup_no_email的問題營運27年,年均0.015,上限0.3,權重1.0:該規則未觸發。
透明度報告
誰營運出口C00_architecture
provider_operated+0.000
Bapi.black.riseup.net:443Briseup.net2026年9月13日
舉報C00_architecture的問題計算值
完美紀錄的×0.247 完整度88%
扣分主因:留存。這是該紀錄風險最集中的通道 — 僅此一項就能把一份完美紀錄拉低到×0.503,上方的進度條也填充到這裡。
暴露度記錄為medium,完整性狀態記錄為clean。
與名錄整體相比,此紀錄在<b>無知</b>上表現最佳 — ×0.903,而名錄平均為×0.662 —,在<b>披露</b>上表現最差 — ×0.913對×0.970。
公開分數
25以上每一列都是公開紀錄中的一個欄位,每一項都可以提出異議:每列都帶有舉報按鈕,也可以就整筆紀錄提出問題。有憑有據的更正會在當天生效,若因此影響分數,排名也會隨之調整。
最新稽核的對象V03_audit_subject
infrastructureprotocolapp_security
Aopentech.fund2026年9月13日
舉報V03_audit_subject的問題註冊成立所在國家的秘密命令制度P11_gag_order_regime
nsl_equivalent
Briseup.netBriseup.net2017年2月
舉報P11_gag_order_regime的問題Aopentech.fund2026年9月13日
服務的付費方式X05_monetisation_model
freemium_funded
Briseup.netBriseup.net2026年9月13日
舉報X05_monetisation_model的問題安全事件及其公開方式同時被無知讀取X09_incident_handling
third_party_disclosed
Aopentech.fundBopentech.fund2026年9月13日
舉報X09_incident_handling的問題應用程式商店的資料聲明與業者本身政策的比較X12_store_data_declaration
matches_policy
Bplay.google.com2026年9月13日
舉報X12_store_data_declaration的問題來自所有者集團的傳導S18_cluster_contagion
0.0
該紀錄沒有所有者集團,因此無可傳導內容
安全事件及其公開方式同時被完整性讀取X09_incident_handling
third_party_disclosed
Aopentech.fundBopentech.fund2026年9月13日
舉報X09_incident_handling的問題通道內使用自有 DNSC06_own_dns_in_tunnel
未知+0.012
未公開任何內容 · 記錄為 asserted
none
Briseup.net2026年9月13日