⚠️ 警告：Tor VPN 為測試版軟體。 請勿在測試以外用途依賴它。 可能洩漏資訊，不應用於任何敏感用途。

Tor

The Tor network can be understood as a network of virtual tunnels that allows you to improve your privacy and security on the Internet. Tor 會將您的流量經由 Tor 網路中三個隨機伺服器（中繼點）轉送。 電路最後一個中繼（「出口節點」）會將流量送向公開網際網路。 使用 Tor 網路時，網路上任一單點都無法同時看到流量來源與最終目的地，因而難以追蹤使用者的網路活動。 此舉可對網路服務商（ISP）與監看您連線的本地端隱藏流量目的地（例如您造訪的網站名稱與位址）；您所存取的網站與服務營運方及其監看者，會看到連線來自 Tor 網路而非您的真實 IP 位址。

Tor VPN

Tor VPN 是由 Tor Project 開發的免費開源軟體，屬 Tor 型應用程式，可將使用者裝置上其他應用程式的流量經由 Tor 網路轉送。 Tor VPN 利用 Tor 網路，將流量經由 Tor 中繼點轉送。 使用 Tor VPN 的主要用途與優點：

• 隱私。 你所造訪網站與服務的營運者，以及監看它們的人，看到的會是來自 Tor 網路的連線，而非你的真實網路（IP）位址與地理位置；除非你主動透露身分，否則他們不會知道你是誰。
• 阻擋監控。 你的網路服務供應商（ISP）或任何監控網路的人，都無法追蹤你的網路活動。
• 抗審查。 Tor VPN 讓您在遭封鎖的地區仍能存取網站與應用程式，並在政府或 ISP 實施網路審查或過濾的地區連上自由網路。
• 存取 Onion 服務。 Onion services 是只能透過 Tor 網路存取的服務。 Onion 服務讓使用者匿名瀏覽與發布內容，亦用於無中繼資料的聊天與檔案分享（如 OnionShare）、記者與消息來源更安全的互動（如 SecureDrop）、更安全的軟體更新，以及更安全地連線至常見網站。

Tor VPN 為自由軟體。 免費：自由軟體（libre），且免費提供。 請確保僅從下列官方來源下載，以安裝正確的 Tor VPN。

最低系統需求

Tor VPN 僅適用於 Android 作業系統，需符合：

• Android 7.0 或更新版本。
• 支援 Aarch64、Arm、x86_64 或 x86 架構的 Android 裝置。

不支援 Android 平板與 Chromebook。

Google Play 商店

你可以從 Google Play 商店 下載並安裝 Tor VPN。

F-Droid

你可以從 F-Droid 下載並安裝 Tor VPN。

• 點選「連線」即可開始連線。
• 系統會顯示「Connection request」提示，要求 Tor VPN 建立 VPN 連線。
• 點選「確定」。

自動連線

你可以設定 Tor VPN 在每次啟動時，使用先前儲存的連線設定自動連線至 Tor 網路。

• 啟動 Tor VPN 時，點選「設定」。
• 開啟「自動連線」。

您可從應用程式商店更新 Tor VPN。

Google Play 商店

• 開啟 Google Play Store 應用程式。
• 點擊右上角的個人資料圖示。
• 點選「管理應用程式和裝置」。
• 點選「管理」選項。
• 點選「可用更新」
• 在需要更新的應用程式清單中點選 Tor VPN。
• 點選「更新」。

F-Droid

• 開啟 F-Droid 應用程式。
• 點選「設定」，然後進入「管理已安裝應用程式」。
• 在應用程式清單中點選「Tor VPN Beta」。
• 點選「更新」。

Google Play 商店

• 開啟 Google Play Store 應用程式。
• 點擊右上角的個人資料圖示。
• 點選「管理應用程式和裝置」。
• 點選「管理」選項。
• 在裝置已安裝的應用程式清單中點選 Tor VPN。
• 點選「解除安裝」。

F-Droid

• 開啟 F-Droid 應用程式。
• 點選「設定」，然後進入「管理已安裝應用程式」。
• 在應用程式清單中點選「Tor VPN Beta」。
• 點選「解除安裝」。

裝置設定

• 前往裝置設定。
• 前往「Apps」或「Applications」區塊。
• 選擇 Tor VPN。
• 點選「解除安裝」。

您也可以只允許特定應用程式使用 Tor VPN 並經 Tor 網路轉送。

如何為特定應用程式設定 Tor 連線

• 點選「Apps」選項。 或在啟動 Tor VPN 時點選「Configure」，再點選「Apps」。
• 關閉「Protect all apps」。
• 請為每個應用程式分別開啟使用 Tor VPN 的選項。

透過 Tor 網路連線時，網站與應用程式會認為您從 Tor 出口節點所在國家連線。

若要設定 Tor 連線的出口位置：

• 在「連線」畫面點選「Globe」圖示。 或在啟動 Tor VPN 時點選「Configure」，再點選「Exit location」。
• 預設選項為「Random per circuit」。 勾選此選項後，每個已設定的應用程式會取得隨機的 Tor 電路。
• 請從清單中點選國家。

若要啟用「Kill switch」：

• 開啟 Tor VPN 應用程式並點選「Configure」。
• 點選「Kill switch」。
• 點選 Tor VPN 設定（⚙️）。
• 開啟「Always-on VPN」。

應用程式圖示與名稱

若要變更應用程式圖示與名稱的外觀：

• 啟動 Tor VPN 後，點選「設定」。
• 點選「App icon」。
• 從選項中選擇。
• Tor VPN 仍會在主畫面、通知、搜尋、App 資料庫與應用程式商店頁面顯示。

在嘗試常見疑難排解步驟後，若 Tor VPN 仍無法建立與 Tor 網路的連線，您的連線可能遭到審查封鎖。 此時可嘗試使用其中一種內建的審查規避連線方式。

若要使用橋接節點：

• 點選「連線」。 或在啟動 Tor VPN 時點選「Configure」，再點選「Bridges」。
• 開啟「使用橋接節點」。

Tor VPN 支援下列橋接類型：

• obfs4：它會讓 Tor 流量看起來像隨機資料，並防止審查者透過網路掃描找到橋接節點。
• Snowflake：它會把您的連線轉送到志工營運的代理節點，讓流量看起來像在進行視訊通話，而不是使用 Tor。
• WebTunnel：它會隱藏 Tor 連線特徵，讓流量看起來像一般 HTTPS 網頁存取。

依您所在地區，某種橋接類型可能較為有效。

若內建、obfs4 與 Snowflake 等審查規避方式皆無效，您必須另行申請其他橋接。 橋接位址並非公開，您必須在應用程式內自行申請：

透過 Telegram 機器人取得橋接節點

• 點選「請求橋接節點」。
• 點選「給我新的橋接節點」。
• 橋接機器人取得橋接位址後，請點選「Save bridges」。

從電子郵件獲取橋接節點

• 以 Gmail 或 Riseup 電郵地址向 bridges@torproject.org 發送電郵，並複製從電子郵件中收到的橋接器位址。

從橋接節點網站取得橋接節點

• 請造訪我們的橋接節點網站。
• 點選「取得橋接節點」。
• 接著點選「Just give me bridges!」並複製橋接行。

輸入橋接位址

若透過電子郵件或 Bridges 網站取得橋接，您必須手動新增。

• 若要使用橋接節點，請點選「連線」。 或在啟動 Tor VPN 時點選「Configure」，再點選「Bridges」。
• 開啟「使用橋接節點」。
• 點選「新增橋接節點」。
• 貼上已複製的橋接位址。
• 點選「儲存」。

若 Tor VPN 無法連線，您可能會看到錯誤訊息：

疑難排解時，請依序嘗試以下方法：

導覽至 Android 的設定

• 請確認沒有其他 VPN 應用程式正在執行。 Android 不允許同時使用多個 VPN 應用程式。
• 請確認沒有網路防火牆應用程式正在執行。 防火牆應用程式通常會佔用 VPN 連線；若正在執行，Tor VPN 將無法建立連線。

檢查 Tor VPN 應用程式

查看 Tor VPN 記錄有助於診斷問題。 取得 Tor VPN 記錄的方式：

• 在錯誤訊息或「連線」畫面中點選「檢視 Tor 記錄」。
• 點選「設定」。
• 捲動到 Tor VPN 設定中的「進階」區塊。
• 點選「Tor 記錄」。

錯誤 #1：請檢查網路連線

00:00:00:00 W/onionmasq: onion_tunnel::runtime: Arti failed to connect to [2a00:ccc1:1:2c::1]:9000: Network is unreachable (os error 101)
00:00:00:00 W/onionmasq: tor_chanmgr::transport::default: Connection to [scrubbed] failed: error: Network is unreachable (os error 101)

錯誤 #2：請檢查您的網路是否封鎖 Tor。

00:00:00:000 E/onionmasq: onionmasq_mobile::ffi: runProxy() returned error: couldn't start onionmasq proxy
00:00:00:000 CONNECTION_ERROR
00:00:00:000 D/onionmasq: onionmasq_mobile: closing proxy...

此時可嘗試其中一種審查規避方式。

若您遇到的問題未在文件說明中，請先嘗試疑難排解步驟。 若仍無法解決，請提交錯誤回報或聯絡支援團隊。

提交支援請求、反饋或程式錯誤回報時，請盡量提供更多資訊：

1. Android 版本。
2. Tor VPN 版本。
3. 重現問題的逐步操作說明。
4. 問題畫面截圖。
5. Tor 記錄。
6. 您連線至 Tor 時所在的國家或地區。
7. 若您知道或懷疑您所在區域或網路封鎖 Tor，請一併說明。

回饋與回報錯誤

Tor 論壇

請在 Tor 論壇 建立帳號以發表新主題。 發文前請閱讀討論規範並搜尋是否已有相關主題。

Tor GitLab

若您要回報錯誤，請至我們的 錯誤追蹤系統 提交。 請先確認該錯誤是否已有人回報。 若要搜尋並瀏覽所有 Tor VPN 相關錯誤回報，請前往 Tor VPN 程式庫。

若要建立新的錯誤回報，請申請新帳號以存取 Tor Project 的 GitLab。 請在 Tor VPN 儲存庫 提交錯誤回報。

聯絡支援

• 我們透過電子郵件、Telegram、WhatsApp 與 Signal 提供的使用者支援服務時間為週一至週四。 週五至週日為服務專線休息時間，請放心，我們仍會回覆您的訊息。
• 我們所有支援管道皆提供英文、俄文與波斯文服務。 若上述語言皆不適用，請以您最自在的語言撰寫；請理解我們需要翻譯協助才能理解，回覆時間可能較長。
• 我們在 Telegram、WhatsApp 與 Signal 的支援管道僅提供文字訊息，不支援視訊或語音通話。

Telegram

請透過 @TorProjectSupportBot 傳訊息給我們。

電子郵件

發送電子郵件到 frontdesk@torproject.org

請在電子郵件主旨說明您要回報的內容。 主旨越具體，我們越能掌握並後續處理。 有時沒有主旨的郵件會被誤判為垃圾郵件。

WhatsApp

請透過 +447421000612 以 WhatsApp 訊息聯絡我們。

Signal

請透過 +17787431312 以 Signal 訊息聯絡我們。

Mike Perry

mikeperry@torproject.org

August 6, 2025

0. Introduction

Similar to Tor Browser, and unlike traditional VPNs, Tor VPN gives each application its own route through the Tor network. This feature prevents network adversaries from linking a user's private activity with their non-private activity.

In contrast to Tor Browser, the privacy benefits that Tor VPN provides depend highly upon the behavior of individual applications, the permissions granted to those applications, and the configuration of the base Android system.

For privacy-hostile applications in partial Tor mode, or for applications that users only occasionally use with Tor, Tor VPN provides only censorship circumvention and protection from network surveillance.

When used on properly configured privacy-enhanced Android distributions such as GrapheneOS, Tor VPN can provide additional privacy benefits even for privacy-hostile applications.

This document describes the nature of the benefits that Tor VPN provides and when they apply.

0.1. Table of Contents

• Tor VPN Threat Model
• Mike Perry
• 0. Introduction
• 0.1. Table of Contents
• 1. Overview
• 1.1. Threat Model Summary
• 2. Security Properties
• 2.1. Low-level VPN Security Properties
• 2.2. ICTM Security Invariants
• 2.3. ICTM Security Invariant Activation Conditions
• 3. Android App Types and Configurations
• 3.1. Application Types
• 3.2. Device Configurations
• 4. Threat Model Matrices
• 4.1. Tor VPN Per-App Mode Matrix
• 4.2. Tor VPN All-App Mode Matrix
• 5. Known Weaknesses
• 5.1. All Android Versions
• 5.1.1. Network Interface IP Address Visibility
• 5.1.2. Push Notification Linkability
• 5.1.3. Multicast DNS and SSDP Leaks
• 5.1.4. Android ID
• 5.1.5. SIM Card Operator ID
• 5.1.6. WiFi Calling
• 5.2. Stock Android
• 5.2.1. Apps Can Use Cell Network to Bypass VPN
• 5.2.2. Secondary User Profiles Bypass VPN at Start
• 5.2.3. Google Account Linkability
• 5.2.4. Various DNS Leaks
• 5.2.5. VPN Bypass Whitelist
• 5.3. GrapheneOS
• 5.3.1. Android Advertising ID Linkability

1. Overview

The Tor VPN threat model uses the ICTM methodology. ICTM specifies security invariants that the user can expect when using the software in a particular way or in a particular environment. An ICTM threat model starts from a point of "No Security" and adds security invariants when the software environment meets particular requirements.

We express what Tor VPN provides in terms of ICTM security invariants, which apply to specific application types and usage scenarios.

In our usage of ICTM, we define five ICTM security invariants that represent levels of privacy that Tor VPN provides. This document links these invariant terms in Capitalized Bold Italic to their definition sections.

These security invariants apply to the combination of four types of Android applications, two modes of Tor VPN (all-app or per-app), and five Android device configurations. This document links these classification terms in Capitalized Bold to their definition sections.

The combined outcome results in two threat model matrices that represent the ICTM security invariant that is active in a given situation.

1.1. Threat Model Summary

The level of pseudonymity that Tor VPN provides to the user guides the overall threat model.

Tor VPN provides at least censorship circumvention to all selected apps.

Tor VPN does not magically make all apps anonymous or pseudonymous. If the user used their real name or even created their account without Tor, then they have no pseudonymity.

If the user uses a privacy-enhanced version of Android and is careful about their Google account setup and app usage, then Tor VPN can help protect the usage of a single pseudonym for the user of the device. (The user may try to use different names in different apps, but app behavior can link these pseudonyms to the Google account and/or to each other).

If the user uses privacy-preserving apps with proper configuration, then Tor VPN can enable the usage of separate pseudonyms in those apps. (When properly configured, an adversary cannot link the different pseudonyms used in distinct privacy-preserving apps).

Essentially, this threat model describes the circumstances under which the user obtains these different levels of pseudonymity protection.

2. Security Properties

The low-level VPN security properties and the ICTM security invariants support the Tor VPN threat model.

2.1. Low-level VPN Security Properties

Two low-level security properties that the OnionMasq networking daemon provides support the ICTM security invariants. These low-level security properties must hold for the ICTM invariants to apply:

1. Network Leak Safety. Apps MUST NOT be able to bypass the VPN when it is enabled. This includes during device startup, if the VPN is not connected yet, or if the network is temporarily disconnected. The VPN industry calls this property a "Kill Switch", "Always On VPN Lockdown", or "On Demand". The Always-on Lockdown feature of Android 8 and above provides this property.

2. Network App Isolation. All network activity of each Tor-routed app MUST be isolated from other apps by using its own dedicated Tor circuit(s). Specific apps MAY bypass Tor entirely if the user chooses to allow this. Android 10 及更新版本的 ConnectivityManager API 提供此屬性。

2.2. ICTM Security Invariants

These are the security invariants that Tor VPN is capable of providing to individual apps. To simplify activation conditions, some invariants inherit the properties of earlier ones. We list these inherited invariants under each invariant.

The high-level conceptualization to keep in mind is that we are defining distinctions in the level of pseudonymity that the user can expect for an app: no pseudonymity, multi-app shared pseudonymity, per-app pseudonymity, and anonymity.

The next section lists the activation conditions under which they apply.

• No Additional Security
• Invariant Property: Tor VPN provides no additional security.

• Censorship Circumvention
• Invariant Property: A network adversary is unable to block application traffic.

• Network Privacy
• Invariant Property: A local network adversary is unable to determine which applications are used with Tor VPN, and apps are unable to determine the user's current IP address (i.e., approximate current location).
• Inherited Invariants: Censorship Circumvention

• Linkable Pseudonymity
• Invariant Property: App usage has pseudonymity, but this pseudonymity may be linked to other activity on the device or to a sandboxed and pseudonymous Google account. This is also known as Multi-App Shared Pseudonymity.
• Inherited Invariants: Censorship Circumvention, Network Privacy

  NOTE: Linkable Pseudonymity is a fragile state. As pseudonymous activity is linked together, the odds increase that there is some way to deanonymize some of that activity, thus deanonymizing all of it. One can conceptualize this invariant as providing "Multi-App Shared Pseudonymity," where all apps with Linkable Pseudonymity on the device effectively share the same pseudonym. This is why we require either the Pseudonymous Google Configuration or Google-Free Configuration for apps to gain this invariant. (Pseudonymity would otherwise vanish as soon as it was linked to a non-pseudonymous Google account.)

• Unlinkable Pseudonymity
• Invariant Property: App usage has unique pseudonymity that is not possible to link to other device activity. This is also known as Per-App Pseudonymity.
• Inherited Invariants: Censorship Circumvention, Network Privacy

  NOTE: One can conceptualize this invariant as providing "Per-App Pseudonymity." Because of Tor VPN's Network App Isolation, when this invariant is active for an app, its activity cannot be linked to non-private activity on the device. This is not the case for traditional VPNs, which allow the VPN operator and VPN endpoint observers to link such activity.

• Full Anonymity
• Invariant Property: App usage is unlinkable to other device activity, as well as to previous activity of that same app.
• Inherited Invariants: Censorship Circumvention, Network Privacy

2.3. ICTM Security Invariant Activation Conditions

Our security invariants activate depending on what type of app is in use, the Tor VPN mode (per-app or all-apps), and properties of the base OS and configuration.

The lowest numbered invariant where an app matches these clauses is the invariant for that app.

A device may have multiple apps operating at different security invariant levels, depending on these conditions.

The Threat Model Matrices present this same activation information in table form.

• No Additional Security
• Activation Condition: Active for all apps when the user installs Tor VPN but does not enable it at all.

  Rationale: Surprisingly, this is a common failure mode for VPN apps among people who do not understand how they work.

• Activation Condition: Active for all apps when the user installs Tor VPN on a device past the end-of-life for Android security fixes.

  Rationale: We cannot provide any additional security to a device that is already vulnerable to unfixed, publicly disclosed security flaws. We assume these public flaws can subvert any privacy or security properties the user would hope to gain by running Tor VPN.

• Activation Condition: Active for apps that are not selected to use Tor when the user runs Tor VPN in per-app mode.

  Rationale: In per-app mode, apps that are not selected for Tor use get no protection. (Though they could if we implemented a per-app network block feature).

• Censorship Circumvention
• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in per-app mode.

  Rationale: Privacy-hostile applications can trick the user into opening URLs in apps that are not selected to use Tor and can link non-Tor activity to their activity.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and the device uses the IP Address Privacy Configuration.

  Rationale: On all versions of Android, Privacy-hostile applications can use the ACCESS_NETWORK_STATE Android permission to determine the SIM card IP address and can engage in data sharing with the ISP, which removes Network Privacy. On Stock Google Android (but not GrapheneOS), they can bind to the cell network interface to directly bypass the VPN for arbitrary network connections.

• Network Privacy
• Activation Condition: Active for all privacy-hostile and pseudonymous Unmasked Apps not covered by the previous invariant when the user runs Tor VPN in either per-app or all-app mode.

  Rationale: We assume unmasked apps have no pseudonymity.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and the device uses only the IP Address Privacy Configuration (and not any further unlinkability configuration).

  Rationale: Privacy-hostile apps can link their activity to the user's real name and Google account unless the user takes further steps.

• Activation Condition: Active for Pseudonym-friendly Apps when the user runs Tor VPN in either all-app mode or per-app mode, when the device uses only the IP Address Privacy Configuration (and not any further unlinkability configuration).

  Rationale: Pseudonym-friendly apps can be accidentally linked to a user's real name and Google account through push notifications, phone number authentication, and other mechanisms, unless the user takes further steps.

• Linkable Pseudonymity
• Activation Condition: Active for Pseudonym-friendly Apps when the user runs Tor VPN in either all-app mode or per-app mode, and the device uses the Pseudonymous Google Configuration and the user grants push notification permission to the app.

  Rationale: The usage of Google push notifications links the pseudonymous app to the device's Google account, which is also pseudonymous in this configuration.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and the device uses the Pseudonymous Google Configuration or Google-Free Configuration.

  Rationale: Privacy-hostile apps can cooperate with other privacy-hostile apps on the phone to link activity, even without a device Google account.

• Unlinkable Pseudonymity
• Activation Condition: Active for Pseudonym-friendly Apps when the user runs Tor VPN in either all-app mode or per-app mode, and has configured the device and app with Pseudonymous App Configuration or Google-Free Configuration.

  Rationale: These device configurations prevent linkability of the pseudonymous app to the device's Google account.

• Activation Condition: Active for Privacy-hostile Apps when the user runs Tor VPN in all-app mode and has configured the device with Isolated User Profile Configuration.

  Rationale: This device configuration isolates privacy-hostile apps from the device's Google account and from each other.

• Full Anonymity
• Activation Condition: Active for Anonymity Apps when the user runs Tor VPN in either all-app mode or per-app mode.

  Rationale: Anonymity apps have no other identifiers other than the current IP address, which is now a Tor exit IP address.

3. Android App Types and Configurations

As can be seen, our security invariants depend upon the app type and the Android device configuration. In this section, we define those applications and configurations specifically.

3.1. Application Types

We classify Android applications into four types:

• Unmasked Apps Unmasked apps are apps that were previously used outside of Tor, associated with a non-pseudonymous phone number, or associated with a real name/email. In essence, these apps have been unmasked to the user's real name. Unmasked apps can no longer have any strong pseudonymity expectations and can at most gain only Network Privacy from Tor VPN.

  NOTE: Once an app is unmasked on a device, creating a new pseudonymous account in the same app does not remove this classification. In fact, due to the Android ID identifier behavior, deleting the app and reinstalling it in the same profile still allows a new pseudonym to be linked to the deleted one. A user must use the Isolated User Profile Configuration to create a new device user profile to use the app in an unlinkable way with respect to the current profile's Android ID for that app.

• Examples of unmasked usage include:
• Signal registered with a regular phone number.
• A ProtonMail account accessed over non-Tor.
• An Element account linked to an email address in the user's real name.
• Any app that has been linked with a non-pseudonymous Google account (via push notifications, location usage, etc.).
• Any app that has been linked to a pseudonymous Google account that is later accessed over non-Tor.

• Privacy-hostile Apps Privacy-hostile apps are apps that use every available mechanism to attempt to link their activity to other user activity. They make use of the Android Advertising ID, identifiers, network state, location, sensors, etc. In a stock Android configuration, these apps gain Censorship Circumvention from Tor VPN, but can gain higher Tor VPN invariants when used with privacy-enhancing Android distributions, as referenced in those invariants. See Device Configurations for specific configuration details. Example Apps: Facebook, Instagram, WhatsApp, TikTok, X, and Reddit.

• Pseudonym-friendly Apps These are apps that provide accounts with some degree of pseudonymity, either as an explicit design goal or as a consequence of not actively trying to link user activity together or otherwise track the user. Unfortunately, the Android OS can easily subvert their pseudonymity through misconfiguration or even basic usage. In a default Android configuration, these apps gain Network Privacy from Tor VPN. These apps can gain Unlinkable Pseudonymity from Tor VPN on stock Android, under the device configuration conditions specified in that invariant. Example Apps: Signal, Session, Element, ProtonMail, and TutaMail.

• Anonymity Apps These are apps that do not store long-term identifiers or logins. In some cases, such as private browsers, the app clears identifiers upon restart or otherwise regularly. In other cases, such as Zcash wallets, the app uses Zero-Knowledge proofs rather than trackable identifiers. These apps gain Full Anonymity from Tor VPN. Example Apps: Zashi, Cake Wallet, and private browsers.

3.2. Device Configurations

Architecturally, Tor VPN is capable of providing a high degree of unlinkability to applications on the same device, as we can see from the security invariants. Unfortunately, Android is an extremely privacy-invasive platform. The Android ecosystem has been built upon the same advertising model that the web has been built upon. Because Google controls Android and is the primary benefactor (if not sole conduit) of Android advertising revenue, Google designed the platform to maximize the ability to track usage and to link user activity together to build a comprehensive advertising profile of the user. This linkability is problematic even for apps that provide pseudonymity as a design goal, merely through their usage of the system APIs. The primary way that the system subverts pseudonymity is by associating the pseudonym with the Google account, most often through push notifications, but also through associating location information with the Android Advertising ID. On a stock Google Android, the device's Google account gets full device information: serial number, IMEI, IMSI, phone number, WiFi MAC address, full location history, and installed application list. We assume that any linking mechanism to the stock Android Google account provides deanonymization of a pseudonym. In these cases, apps can gain Network Privacy at most. The good news is that there are ways of configuring an Android device that improve the ICTM security invariant that Tor VPN can provide:

• IP Address Privacy Configuration From a VPN provider's perspective, the most unfortunate aspect of Android is that every app on the device typically has the ACCESS_NETWORK_STATE permission, which gives access to all IP addresses on the device, along with a lot of other network interface information that can be used to track the user. For a good overview of all the information that is available by default, install Network Analyzer or use the Device ID test in our VPN Test App. Unfortunately, even privacy-preserving Android distributions such as GrapheneOS do not provide the ability to redact non-VPN network information and non-VPN IP addresses when a VPN is active. Additionally, on stock Android, apps can bypass the VPN interface by binding to the cell network interface, regardless of Always-on and Block Connections Android settings. Until those tickets are fixed:
• The device must be in Airplane mode and used with a WiFi hotspot or tethered to another phone.

• Pseudonymous App Configuration As per the app classification, Pseudonym-friendly Apps are privacy-focused apps that provide a pseudonym and do not actively try to deanonymize the user. They also may not necessarily ensure that this pseudonym is fully unlinkable. To ensure that Pseudonym-friendly Apps are unlinkable to other device activity, the user must do the following:
• Do not use the device phone number for app registration. Use an online SMS or VoIP provider over Tor.
• Do not use the device's Gmail account for app registration.
• Disable notifications from within the app (disabling push permission is insufficient).
• For apps that are capable of making voice and video calls, either use IP Address Privacy Configuration, or configure the app to always relay these calls for you.

When these properties are met, the app will not be linked to the device's Google account, which is a common source of deanonymization.

NOTE: Removing push notification permission is NOT ENOUGH to prevent apps from being able to register with Firebase (Google) to receive a push token that links the app to the Google account. See the Push Notification section of Known Weaknesses for more information. For now, if an app does not provide settings to disable notification registration, then you must use one of the following configurations instead. (For example: Session Messenger allows push registration to be disabled or switched to non-Google; Signal currently offers no such configuration).

• Pseudonymous Google Configuration On stock Android, linking activity to the Google account typically means deanonymization. The Google account is typically in the user's real name, and even if not, it has access to all device identifiers, including cell network and location history. There are two levels of reducing the damage that this linkability can do while still retaining key device functionality:
• Make a new pseudonymous Google account on GrapheneOS.
• Use a GrapheneOS device with the Google Service Framework package installed, but without a Google account.

It turns out that from the point of view of our ICTM security invariants, both of these are equivalent: they both result in Linkable Pseudonymity for both pseudonym-friendly apps and privacy-hostile apps because they significantly reduce the amount of linkable information, but they do not eliminate it. The primary reason is due to the remaining push notification linkability. See the Push Notification Linkability section of Known Weakness for more info. If the push notification linkability weakness is mitigated, then pseudonym-friendly apps will have Unlinkable Pseudonymity in this configuration when using push notifications. The first option accepts linkability through the Google account but mitigates deanonymization through careful management of this Google account. In this configuration, the user creates a new Google account over Tor and relies on the GrapheneOS Google Sandbox to provide pseudonymity for the device's Google account. In this sandbox, the system treats Google as a normal app, with revocable permissions and no access to hardware identifiers. Additionally, GrapheneOS requires the user to manually disable the Android Advertising ID. Doing so eliminates a large source of excess linkability. The Android Advertising ID is heavily used to link pseudonyms to location data. In the second option, the user configures a new privacy-enhanced Android device without a Google account but still uses push notifications with sandboxed Google Play Services on GrapheneOS. The user can use F-Droid or Aurora Store to install apps without a Google account. Without a Google account, there is less linkability risk between apps through other Google APIs other than push.

NOTE: The device must always use Tor to avoid linking its device push registration to a non-Tor IP address. This may be problematic in censorship scenarios where configuration information is delivered over push notifications. In this case, without a device Google account, it may be possible to clear registration data and re-register to remove linkability. But the effectiveness of this will depend on the data retention duration of the services involved for expired push tokens. See the Push Notification Linkability section of Known Weaknesses.

• These properties define this configuration:
• Configure with the IP Address Privacy Configuration to prevent Google Services and hostile apps from using the cell IP address for linkability.
• Optional Google Account Config:
• Create a new pseudonymous Google account over Tor for the device, using an SMS or VoIP phone number.
• The Android Advertising ID of this account has been disabled.
• Do not use the device phone number or Google account for app registration. Use a different online SMS or VoIP provider over Tor.
• If Tor VPN is in per-app mode, all Google Play Services and Google apps must be selected to use Tor in this configuration.
• Disable Private DNS and Connectivity Checks.

• Google-Free Configuration In this configuration, the user installs GrapheneOS without Google Play Services installed at all, yielding a fully "de-Googled" Android device. The user can still use Aurora Store to install apps without a Google account, though many apps may crash or fail without access to Google Play Services. This configuration entirely prevents linkability through push notifications and other Google API usage. For the apps that function, these foot-guns will be completely unavailable. We still assume that privacy-hostile applications can link their activity in this mode if they cooperate on-device or via sensor side channels. This is why these apps are still listed as having Linkable Pseudonymity, but this linkability is significantly less than with a Google account or Google APIs involved.
• These properties define this configuration:
• Install GrapheneOS, but do not install Google Play Services.
• Configure with IP Address Privacy Configuration.
• Use Aurora Store to install apps.
• Do not use the device phone number for app registration. Use a different online SMS or VoIP provider over Tor.

• Isolated User Profile Configuration Privacy-hostile apps are considerably harder to make unlinkable. Because the Android system allows apps to communicate with each other, and because there is evidence of apps willfully abusing this communication to link activity, the only real option to make privacy-hostile apps unlinkable is to install them in their own Android user profile on an Android distribution that supports strong profile isolation. The main downside of this approach is that each user profile must run its own instance of Tor VPN.
• The properties of this configuration are:
• Configure with IP Address Privacy Configuration.
• GrapheneOS is needed to ensure apps from separate profiles cannot communicate or bypass the VPN.
• The profile needs its own installation of Tor VPN.
• The profile should not install Google Play Services.
• Do not use the device phone number or Google account for app registration. Use a different online SMS or VoIP provider over Tor.

4. Threat Model Matrices

The active security invariant for a given scenario can be summarized in two matrices: one for Tor VPN per-app mode and one for Tor VPN all-app mode. These two matrices exactly represent the ICTM security invariant clauses from Section 2.3.

4.1. Tor VPN Per-App Mode Matrix

App Type / Android Config	Base Android	IP Address Privacy Configuration	Pseudonymous App Configuration	Pseudonymous Google Configuration	Google-Free Configuration	Isolated User Profile Configuration
Unmasked Privacy-hostile Apps	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention
Unmasked Pseudonym-friendly Apps	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy
Privacy-hostile Apps	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention	Censorship Circumvention
Pseudonym-friendly Apps	Network Privacy	Network Privacy	Unlinkable Pseudonymity (without push registration**)	Linkable Pseudonymity (with push registration**)	Unlinkable Pseudonymity	Unlinkable Pseudonymity
Anonymity Apps	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity

4.2. Tor VPN All-App Mode Matrix

App Type / Android Config	Base Android	IP Address Privacy Configuration	Pseudonymous App Configuration	Pseudonymous Google Configuration	Google-Free Configuration	Isolated User Profile Configuration
Unmasked Privacy-hostile Apps	Censorship Circumvention	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy
Unmasked Pseudonym-friendly Apps	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy	Network Privacy
Privacy-hostile Apps	Censorship Circumvention	Network Privacy	Network Privacy	Linkable Pseudonymity	Linkable Pseudonymity	Unlinkable Pseudonymity
Pseudonym-friendly Apps	Network Privacy	Network Privacy	Unlinkable Pseudonymity (without push registration**)	Linkable Pseudonymity (with push registration**)	Unlinkable Pseudonymity	Unlinkable Pseudonymity
Anonymity Apps	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity	Full Anonymity

5. Known Weaknesses

In this section, we list the known weaknesses of both stock Android and privacy-enhancing Android, where fixing a weakness would significantly improve the available security invariants.

For each weakness, we list the Consequences for the user and the mitigating configurations the user must perform, when possible.

We also provide fix Recommendations for developers of GrapheneOS, Android, and pseudonym-friendly apps.

5.1. All Android Versions

The following Android privacy issues apply to all Android versions, including GrapheneOS and CalyxOS.

5.1.1. Network Interface IP Address Visibility

In all versions of Android, when apps have the ACCESS_NETWORK_STATE permission (which nearly all Android apps have), they can examine properties of all network interfaces, including the IP address. For a good overview of all the information that is available by default, install Network Analyzer or use our VPN Leak Test App.

Consequences: This weakness prevents Tor VPN from providing Network Privacy (or further invariants) to Privacy-hostile apps. This weakness also exposes the user to IP address leaks even for Pseudonym-friendly apps that disclose all device IP addresses during WebRTC calls. In both cases, the user must use their phone with a mobile WiFi hotspot, rather than a SIM card, to mitigate this weakness.

Recommendation: When a VPN is enabled, the Android OS should simulate non-VPN interfaces as disconnected, or it should spoof unused RFC1918 addresses for non-VPN interfaces. If addresses are spoofed, the system should not provide the same values to all apps, to prevent the use of spoofed values as identifiers (which likely already happens with IP address values today). These mitigations are essential because they enable VPNs to provide Network Privacy. Most VPN users naturally want their IP addresses to be unavailable to apps for tracking purposes.

5.1.2. Push Notification Linkability

All versions of Android (and also all versions of iOS) are currently subject to linkability through push notifications, even when the user has denied push notification permission to all apps.

When registering for Google's Firebase push notifications, apps obtain an FCM "token" from Firebase, which they submit to their servers. Their servers use this token to deliver messages to Google, who then uses the token ID to look up the device and send it the message.

Our VPN Leak Test App verifies that this registration ability is possible without any push notification permission, in the Device ID test.

This means that a series of record requests (sent first to the app developers and then to Google) will discover the Google account in use with a particular app. From there, even if there is no device Google account, the other push tokens associated with the device can be used to make further record requests to other app service providers for account data associated with their respective token IDs.

Because Google (and many apps) operate internationally, these requests can come from arbitrary jurisdictions. The Anti-Foreign Sanctions Law in China is one such example of a law that can be used for this purpose, although no direct reports of China using push notifications have been made public. It seems likely that Wyden's concerns did not come from nowhere, though.

This linkability is possible even for apps like Signal that do not send any actual content in the push notification and use it only as a wake-up notification. Because Signal still stores the token ID with the user's account on their servers, this linkability also exists for them.

This makes it impossible to have distinct pseudonyms for Signal, or any other app that registers with FCM, unless the user configures their device without Google Play Services or creates a separate user profile without Google Services for these apps.

Consequences: This weakness makes the Pseudonymous App Configuration impossible for many apps, because FCM push registration cannot actually be disabled by the user by denying push notification permission to an app. It also makes Pseudonymous Google Configuration have far more app linkability to the Google account (or device) than would otherwise be the case, linking many privacy-hostile apps to Google and to other pseudonym-friendly apps. The user has no real mitigation options, because disabling push notifications still allows this registration and resulting linkability.

Recommendations:

There are a few different approaches that can reduce the user's exposure to this linkability:

• Permissions Enforcement for Push Registration: Access to the FCM Push Registration APIs (or their Google Service Framework downstream calls) should be blocked if the user has not granted push permissions to an app, because users expect that denying push notifications prevents an app's ability to register for push notifications with their Google account.
• Sandbox Registration APIs Separately: On GrapheneOS, since it already has a Google sandbox, FCM Registration APIs could be directed to separate instances of the Google Services Framework that are not associated with the device's Google account or any of the device permissions that may have been granted to the main GSF instance (such as SMS permission or Location permission). Separate sandboxing is useful, because it will allow users to register for push notifications without associating push registration with their Google account.
• Blinded FCM Registration Tokens: At Google Firebase itself, either Blind Signatures or Privacy Pass could be used during push registration such that the push server authenticates the registration in the normal way, but the actual token is blinded. The push tokens would then be unlinkable to the actual device or Google account, but are still authenticated themselves through the blind signature. This blinding will be beneficial to both users and to Google, because it will save Google the cost of answering push-related record requests from arbitrary international jurisdictions, since push tokens would not be possible to associate with account or device info.
• App Config Options: In the meantime, privacy-preserving apps can offer the option to disable push registration or use an alternate provider such as Unified Push. Note that Signal already provides the ability to deliver notifications through its own WebSocket mechanism, but this is only used if Google Play Services are absent. There is no exposed user option for WebSocket push for users with Google Services installed. Alternate push configuration will be useful because it will help users have push notifications without associating their Google account to their app accounts, before the above options are available.

5.1.3. Multicast DNS and SSDP Leaks

In our testing, we discovered that apps can bypass the VPN by using mDNS requests and SSDP activity. We have a reproduction case in our VPN Leak Test App. This test leaks on all versions of Android, including GrapheneOS. GrapheneOS has attempted to fix some multicast leaks, but our test app shows that these fixes are insufficient.

Additionally, these multicast leaks enable privacy-hostile apps to communicate on a local network, further linking user pseudonyms to other app activity on that same network.

This behavior is also observed in the wild, with Spotify engaging in communication over the local network through this bypass mechanism.

Consequences: This weakness allows Privacy-hostile apps to communicate on the local network to link their usage to other users on the network.

Recommendation: The Android OS should route this multicast behavior through the VPN interface. This will enable the VPN app to decide whether to allow these local network connections.

5.1.4. Android ID

The Android ID is essentially a 64-bit identifier that is shared by all apps in a user profile with the same signing key.

This identifier persists across re-installations of the same app, which can be verified using our VPN Leak Test App using the Device Identifier test. Users who expect to be able to delete an app and then reinstall it to sign in under a different pseudonym will have their pseudonyms linked by Privacy-hostile apps that make use of this identifier.

Consequences: This weakness prevents users from being able to reinstall apps to change pseudonyms without linking those pseudonyms together. Basically, due to this weakness, once an app is linked to the user's real identity on a profile, that app will always be an Unmasked App, even after reinstallation. Users must install that app in a separate profile to avoid this linkability.

Recommendation: This ID should be randomized with every app installation, rather than persisting after uninstallation. This will allow users to delete an app to change pseudonyms.

5.1.5. SIM Card Operator ID

For some reason, no Android permissions are necessary to determine the cell network ID and the provider name of the user's SIM card. This information can be used to determine the user's rough geographic location, depending on the range of the cell provider (typically at least country-level, but sometimes regional, state, or province-level). The Device ID test of our VPN Leak Test app displays this information. It is also visible in Network Analyzer.

Consequences: This weakness does not directly impact any of our privacy invariants, but it is generally bad for privacy.

Recommendation: These APIs should always return NULL/empty (the default when no eSIMs are configured), because this information is not necessary for app operation.

5.1.6. WiFi Calling

We observed that when WiFi calling is enabled for an activated eSIM, the device makes IPsec connections to the eSIM provider, bypassing the VPN.

Consequences: This weakness does not directly impact any of our privacy invariants, but it is generally bad for privacy in that it exposes the user's WiFi IP address to their cell network.

Recommendation: Allow VPN interfaces control of routing this connection, so that it may be disabled if the user chooses to block it.

5.2. Stock Android

Stock Android has a number of edge cases that can leak DNS or multicast, which can remove the Network Privacy invariant by revealing to the local network that a particular app may be in use.

5.2.1. Apps Can Use Cell Network to Bypass VPN

Stock Android allows apps to bind to the cell network interface and then connect to an IP address, bypassing any VPN in place, regardless of Always-On or Block Connections VPN settings. Our VPN Test App has a reproduction case for this as part of the Leak Test. This leak is only possible over the cell network interface.

GrapheneOS fixed this issue in the 2025072700 Release.

Consequences: This leak allows Privacy-hostile apps to remove Network Privacy on stock Android. Users must use the IP Address Privacy Configuration and/or use GrapheneOS to prevent this leak.

Recommendations: Google shouldn't allow rogue apps to bind to the cell interface to bypass the VPN in Lockdown Mode, because VPN users expect that apps can't bypass the VPN in this mode.

5.2.2. Secondary User Profiles Bypass VPN at Start

On stock Android, user profile isolation can leak packets upon first use after restart.

Consequences: This leak prevents stock Android users from successfully using Isolated User Profile Configuration to isolate sensitive app activity. Users have to install GrapheneOS to mitigate this.

Recommendation: These leaks should be fixed, because users expect Always on VPN and Block Connection settings to work in all user profiles.

5.2.3. Google Account Linkability

On stock Android, the device Google account has access to all hardware identifiers, as well as SIM card identifiers and phone number. This access typically means that any form of linking to the device Google account (through push notifications, Gmail use, or Google OAuth sign-in) typically means deanonymization of a pseudonym.

Consequences: It is difficult for a user to maintain a pseudonym even in Pseudonym-friendly apps without careful configuration.

Recommendations: Both privacy-conscious apps and Google should have more transparency with respect to actions that link the app's account to the device Google account, because users tend to expect that pseudonymity is not actively subverted behind their backs. In the meantime, the GrapheneOS Google Sandbox enables Pseudonymous Google Configuration.

5.2.4. Various DNS Leaks

Multiple issues with DNS exist in stock Android. Apps that use getaddrinfo() from the C library can bypass the VPN. Our VPN Leak Test app reproduces this leak as part of the main Leak Test.

Additional, DNS leaks can happen if the VPN malfunctions or shuts down.

Consequences: DNS leaks can erode Network Privacy by allowing local ISPs to determine which apps are in use. Users must use GrapheneOS to avoid these leaks.

Recommendations: GrapheneOS has fixed these issues. Google Android should upstream these fixes, because users expect that their DNS activity will not bypass their VPN.

5.2.5. VPN Bypass Whitelist

Android has a secure setting Settings.Secure.always_on_vpn_lockdown_whitelist, which allows custom Android builds to define a list of apps that always bypass the VPN, regardless of VPN settings. Google and GrapheneOS both have this setting empty, but third-party Android builds may place their apps in this setting. The ReThink Firewall App has a ticket describing this issue.

Google Android also allows connectivity checks to bypass the VPN. GrapheneOS provides a setting to disable this.

Consequences: On Android rebuilds, various vendor apps may be exempted from the VPN, allowing them to connect outside of it. Users must use GrapheneOS to avoid these leaks.

Recommendations: Users should disable or remove vendor apps that they don't need.

5.3. GrapheneOS

The following weaknesses are unique to GrapheneOS. Note that the universal Android weaknesses also apply to GrapheneOS.

5.3.1. Android Advertising ID Linkability

Additionally, the default-on behavior of the Android Advertising ID is another source of linkability between apps. GrapheneOS requires users to manually disable this ID, but this is not prominently documented during setup.

A better default would be to have the Android Advertising ID disabled by default or to provide a prominent setup step that educates users about this privacy risk.

We list this as a GrapheneOS-specific weakness because other privacy-preserving versions of Android randomize this ID automatically.

Consequences: Users who are not aware that they need to configure their Google account to disable this identifier will have all of their Privacy-hostile app activity linked to their Google account and to each other. Users must manually disable the Advertising ID in their Google account settings.

建議：與 GrapheneOS 代理定位 API 的方式類似，此 API 亦應透過代理回傳隨機或歸零的數值，因為此 API 是極具侵入性的連結性來源，會讓跨應用程式的位置與使用資料被彙整。

Tor 有賴世界各地的用戶與志願者的各種支持，來提升我們的軟體與相關資源，因此您的回饋對我們(以及所有 Tor 用戶)是極為珍貴的。

意見回饋格式

當您要提供回饋建議或是通報臭蟲時，請盡可能的包含下列資訊：

• 您所使用的作業系統
• 洋蔥路由瀏覽器的版本
• 洋蔥路由瀏覽器的安全性等級設定
• 重現該錯誤的步驟說明，以利我們查找（例如：開啟瀏覽器後，輸入了網址，點擊了（i）圖示，然後瀏覽器就當掉了）
• 問題的螢幕截圖
• 歷程記錄

如何聯絡我們

我們設有多種不同的聯繫方式，請按您需要選用。

Tor 論壇

我們建議你到 Tor Forum 尋求協助。 您需要先建立帳號才能發文。 提問前，請先閱讀我們的討論規範。 這一刻如果希望盡快得到答覆，請以英文撰寫。 如果您發現臭蟲的話，請利用 GitLab 提報。

GitLab

首先，請先確認該程式問題是否已知。 您可以在https://gitlab.torproject.org/上搜尋查閱所有的問題。 若要提報一個新的問題，請先索取一個新帳號以存取 Tor Project 的 GitLab 服務，並在尋找正確的儲存庫來滙報您的問題。 你也可以透過 Anon Ticket 匿名回報錯誤或提供意見，無需建立帳號。 我們在 Tor 瀏覽器問題追蹤器上，追蹤所有跟 Tor 瀏覽器有關的問題。 關於我們網站上的問題，請到網頁問題追蹤器提交。

Telegram

如果需要幫助安裝 Tor 瀏覽器或排查故障，並且所在地屏蔽或審查 Tor 論壇，可以通過 Telegram https://t.me/TorProjectSupportBot與我們聯繫。 Tor 支持專員將協助你。

WhatsApp

您可以發送文字訊息到 WhatsApp號碼: +447421000612 以聯絡我們的支援團隊。 本服務僅限文字訊息，並不支援視訊或語音通話。

Signal

您可發送文字訊息到 Signal 號碼: +17787431312 或 Signal 用戶名 @torsupport.89以聯絡我們團隊。 Signal 是一個免費及關注隱私的通訊應用程式。 本服務僅限文字訊息，並不支援視訊或語音通話。 發送訊息之後，支援人員會引導協助您進行疑難排解。

電子郵件

發送電子郵件到 frontdesk@torproject.org。

請在郵件的主旨表明要通報的問題。 郵件主旨寫得越具體明確的話(例如：「連線失敗」、「網站意見反饋」、「Tor 瀏覽器意見反饋」、「要求橋接器」)，那麼我們就可以更容易了解和跟進。 沒有主旨的電子郵件有時會被標記為垃圾郵件，以致我們沒有留意到。

為了能夠更快速的回覆您，麻煩請儘量以英文、西班牙文或葡萄牙文撰寫。 如果這幾種語言您都不熟悉的話，請您直接以自己舒適的語言來撰寫，但請留意這會需要較長的時間才能夠回覆，因為我們需要尋求翻譯協助才能理解您的問題。

部落格貼文的留言

您可以在與您所遭遇的問題有關的部落格貼文裡留言。 如果在部落格上沒有與您的問題有關的貼文，請用其他方式與我們聯繫。

Matrix／IRC

你可以在 OFTC 的 #tor 頻道，或 #tor:matrix.org 找到我們，提供回饋或回報問題。 我們可能不會立即回覆您，但我們都會回頭檢閱聊天記錄，也會盡快跟您聯繫。

了解如何連上OFTC 伺服器。

郵件清單

若要利用郵件清單來通報錯誤或回饋意見的話，我們建議您提報至與您想通報的主題最接近的郵件清單，您可以在這裡找到我們目前的所有郵件清單列表。

通報與洋蔥路由中繼節點有關的問題或意見：tor-relays

通報安全性問題

如果發現安全問題，請發郵件至 security@torproject.org。

如果需要對郵件加密，可以從這個地址keys.openpgp.org獲得 OpenPGP 的公鑰。以下是當前的指紋：

835B 4E04 F6F7 4211 04C4 751A 3EF9 EF99 6604 DE41

如果要參加漏洞賞金計劃，請注意，向第三方網站報告安全問題會帶來我們無法控制的風險，所以請直接向我們報告。

提交支援請求、反饋或程式錯誤回報時，請盡量提供更多資訊：

1. 所使用的作業系統
2. Tor 瀏覽器版本
3. Tor 瀏覽器安全等級
4. 逐步解說如何遇上問題，以便我們把它重現 (例如 : 我開啟了瀏覽器、輸入網址、點擊設定選項、然後瀏覽器突然崩潰)
5. 問題的截圖
6. 桌面版 Tor 瀏覽器的控制台日誌（ 可在 Windows/ Linux 用 Ctrl+Shift+J 來開啟；在 macOS 可用 Cmd+Shift+J 開啟 ）
7. Tor 日誌 (設定 > 連線 > 進階 > 查看 Tor 日誌)
8. 您從哪地區連接 Tor。
9. 由連線助手選擇的地區（假如這是與連線助手相關的問題）
10. Tor 在您身處的地區受到審查嗎 ?
11. 如果連接了 Tor，要花多久時間來應用配置呢? 對瀏覽速度有何影響?

Tor 用戶支援團隊辦公時間

週一至週四：用戶支援頻道在電子郵件、Telegram、WhatsApp 及 Signal 均會運作。

週五至週日：客服專線暫停服務。 請放心，我們的團隊會在週一回覆您的訊息。

如何聯繫我們

我們設有多種不同的聯繫方式，請按您需要選用。

Telegram

我們提供有數個官方 Telegram 機器人與頻道:

1. @GetTor_Bot 下載 Tor 瀏覽器。
2. @GetBridgesBot 以獲取 obfs4 橋接器。
3. @TorProject 以獲取最新消息。
4. @TorProjectSupportBot 尋求協助。 目前 Telegram 支援英語、俄語和波斯語頻道。 如需規避審查的協助，請從選單中選取您所在的地區，以便我們跟進。

Tor 論壇

我們建議可以在 Tor 論壇上尋求協助。 您需要先建立帳號才能發文。 請先參閱論壇討論指南並查看已有的討論主題後再作提問。 這一刻如果希望盡快得到答覆，請以英文撰寫。 如發現程式錯誤，請使用 GitLab。

WhatsApp

您可以發送文字訊息到 WhatsApp號碼: +447421000612 以聯絡我們的支援團隊。 本服務僅限文字訊息，並不支援視訊或語音通話。

Signal

您可發送文字訊息到 Signal 號碼: +17787431312 或 Signal 用戶名 @torsupport.89以聯絡我們團隊。 Signal 是一個免費及關注隱私的通訊應用程式。 目前我們的支援頻道提供英語、俄語和波斯語，並集中協助處於網路審查地區的 Tor 用戶。 本服務僅限文字訊息，並不支援視訊或語音通話。 發送訊息之後，支援人員會引導協助您進行疑難排解。

電子郵件

發送電子郵件到 frontdesk@torproject.org

請在郵件的主旨表明要通報的問題。 郵件主旨寫得越具體明確的話(例如：「連線失敗」、「網站意見反饋」、「Tor 瀏覽器意見反饋」、「要求橋接器」)，那麼我們就可以更容易了解和跟進。 沒有主旨的電子郵件有時會被標記為垃圾郵件，以致我們沒有留意到。

若要取得最快的回覆，請盡可能以英語、俄語、波斯語、西班牙語、印度語、孟加拉語或葡萄牙語撰寫。 如果這幾種語言您都不熟悉的話，請您直接以自己舒適的語言來撰寫，但請留意這會需要較長的時間才能夠回覆，因為我們需要尋求翻譯協助才能理解您的問題。

IRC 與 Matrix

您可以在 OFTC 的 #tor頻道或 MatrixTor 用戶支援頻道找到我們。我們或許無法即時回覆，但我們會查看累積日誌並會盡快回應。

了解如何連上OFTC 伺服器。

GitLab

首先，請先確認該程式問題是否已知。 您可以在https://gitlab.torproject.org/上搜尋查閱所有的問題。 若要提報一個新的問題，請先索取一個新帳號以存取 Tor Project 的 GitLab 服務，並在尋找正確的儲存庫來滙報您的問題。 我們在 Tor 瀏覽器問題追蹤器上，追蹤所有跟 Tor 瀏覽器有關的問題。 關於我們網站上的問題，請到網頁問題追蹤器提交。