---
title: "常見迷思"
icon: 'material/robot-confused'
description: 隱私並不是一個簡單的議題，而且容易受到行銷宣傳和其他錯誤資訊的影響。
schema:
  - 
    "@context": https://schema.org
    "@type": FAQPage
    mainEntity:
      - 
        "@type": Question
        name: 開源軟體本質上安全嗎？
        acceptedAnswer:
          "@type": Answer
          text: |
            是否公開原始碼以及軟體的授權方式本身並不會影響其安全性。 開源軟體有可能比專有軟體更安全，但絕對不能保證一定如此。 評估軟體時，應該根據個別情況來評估每個工具的名譽和安全性。
      - 
        "@type": Question
        name: 將信任轉移到另一個提供者可以增加隱私嗎？
        acceptedAnswer:
          "@type": Answer
          text: |
            在討論 VPN 等解決方案時，我們經常提到「信任轉移」，這是指將對 ISP 的信任轉移到 VPN 提供者身上。 雖然這可以保護您的瀏覽資料不被 ISP 存取，但您選擇的 VPN 提供者仍然可以看到您的瀏覽資料：您的資料並非完全不受各方影響。
      - 
        "@type": Question
        name: 以隱私為重的解決方案本質上值得信賴嗎？
        acceptedAnswer:
          "@type": Answer
          text: |
            如果只注意工具或提供者的隱私權政策和行銷，可能會讓您忽視其弱點。 在尋找更具隱私性的解決方案時，應該先確定根本的問題是什麼，再針對該問題尋找技術解決方案。 例如，您可能想避免使用 Google 雲端硬碟，因為這樣會讓 Google 存取您所有的資料。 在這種情況下，根本問題是缺乏 E2EE，因此您應該確保您要轉換的服務提供者已實際提供 E2EE，或者使用可為任何雲端服務提供 E2EE 的工具 (例如 Cryptomator)。 轉換到一個宣稱「以隱私為重」的服務提供者 (如果該提供者不使用 E2EE) 並不能解決您的問題：這只是將信任從 Google 轉移到該提供者而已。
      - 
        "@type": Question
        name: 我的威脅模型應該要有多複雜？
        acceptedAnswer:
          "@type": Answer
          text: |
            我們經常看到人們描述的隱私威脅模型過於複雜。 這些解決方案通常涉及使用許多不同的電子郵件帳號或複雜的設定，其中包含許多變數和條件。 這類問題的回答大多類似於「做X的最佳方法是什麼？」。
            尋找適合自己的「最佳」解決方案，不一定要追求無懈可擊的方案，因為這樣的方案往往需要滿足數十個條件，實際操作起來非常困難。 正如先前所討論過的，安全性往往以便利性為代價。
---

## 「開源軟體永遠是安全的」或「專有軟體更安全」

這些迷思源於許多偏見，但原始碼是否開放以及軟體的許可並不會以任何方式影響其安全性。 ==開源軟體*可能*比專有軟體更安全，但不能保證絕對如此。== 在評估軟體時，應逐個檢視每個工具的名譽和安全性。

開源軟體*可以*由第三方審查，並且在潛在漏洞這一方面比專有軟體更加透明。 它還可以讓您檢閱程式碼，並自行停用任何可疑的功能。 然而，*除非您真的這樣做了*，否則不能保證程式碼曾經被審查過，尤其是較小的軟體項目。 公開的開發程式有時也會被利用—用以引入新的漏洞，稱為 [:material-package-variant-closed-remove: 供應鏈攻擊](common-threats.md#attacks-against-certain-organizations ""){.pg-viridian} ，我們的 [常見威脅](common-threats.md) 頁面會進一步討論。[^1]

另一方面，專有軟體的透明度較低，但這並不代表它不安全。 大型的專有軟體專案可由內部和第三方機構進行審查，獨立的安全研究人員仍然可以通過逆向工程等技術找出漏洞。

為了避免偏見決策，評估您所使用軟體的隱私和安全標準是*非常重要*的。

## 「轉移信任可以增加隱私」

在討論 VPN 等解決方案時，我們經常提到「信任轉移」，這是指將對 ISP 的信任轉移到 VPN 提供者身上。 雖然這可以保護您的瀏覽資料不被*特定* ISP 存取，但您選擇的 VPN 提供者仍然可以看到您的瀏覽資料：您的資料並非完全不受各方影響。 這表示：

1. 在選擇將信任轉移給另一個服務提供者時，必須謹慎行事。
2. 您仍然應該使用其他技術，例如 E2EE，來完全保護您的資料安全。 僅因個別服務提供者的信任與否，並不能確保資料的安全。

## 「以隱私為重的解決方案本質上值得信賴」

如果只注意工具或提供者的隱私權政策和行銷，可能會讓您忽視其弱點。 在尋找更具隱私性的解決方案時，應該先確定根本的問題是什麼，再針對該問題尋找技術解決方案。 例如，您可能想避免使用 Google 雲端硬碟，因為這樣會讓 Google 存取您所有的資料。 在這種情況下，根本問題是缺乏 E2EE，因此您應該確保要轉換的服務提供者已實際提供 E2EE，或者使用可為任何雲端服務提供 E2EE 的工具 (例如 [Cryptomator](../encryption.md#cryptomator-cloud))。 轉換到一個宣稱「以隱私為重」的服務提供者 (如果該提供者不使用 E2EE) 並不能解決您的問題：這只是將信任從 Google 轉移到另一個提供者而已。

您所選擇的提供者在隱私權政策和商業做法上非常重要，但這些應該被視為次要，技術保障才是關鍵：當信任某個提供者根本不必要時，就不應該把信任轉移到另一個提供者上。

## 「越複雜愈好」

很多人把隱私威脅模型想得太複雜了。 這類解決方案常涉及使用多組電子郵件帳號，或是複雜的設定，其中包含許多變數和條件。 這些回覆通常是針對「做*某件事*的最佳方法是什麼？」這類問題所給出的答案。

尋找適合自己的「最佳」解決方案，不一定要追求無懈可擊的方案，因為這樣的方案往往需要滿足數十個條件，實際操作起來非常困難。 正如先前所討論過的，安全性往往以便利性為代價。 以下是我們的一些建議：

1. ==行動應該要有特定的目的：== 思考如何用最少的行動達成您的目標。
2. ==消除人為失誤的風險：== 人總會失敗、感到疲倦，或者忘記事情。 為了維持安全性，請避免依賴大腦記憶的手動流程和條件。
3. ==根據你的需求選擇合適的保護級別：== 我們經常看到針對執法或傳票的防範建議。 這些通常需要專業知識，並且不符合一般人的需求。 如果因為一個簡單的疏忽而輕易被去匿名化，那麼建立複雜的匿名威脅模型就毫無意義。

那麼，這會是什麼樣子呢？

最明確的威脅模型之一是，一部份人 *知道你是誰*，另一部分的人不知道你是誰。 總有些情況會需要申報您的法定姓名，也有一些情況不需要。

1. **已知身份** － 已知身份用於需要你聲明姓名的情況。 有許多法律文件和合約需要法定身份。 這可能包括開設銀行帳戶、簽署財產租賃、獲得護照、進口物品時的海關申報，或其他與政府打交道的方式。 這些東西通常會需要憑證，如信用卡，信用評級檢查，帳戶號碼，以及實際位址等。

    我們不建議使用 VPN 或 Tor 來進行這些操作，因為您的身份已經透過其他方式被識別了。

    <div class="admonition tip" markdown>
    <p class="admonition-title">溫馨提示</p>

    線上購物時，使用[自助取件櫃](https://zh.wikipedia.org/zh-tw/%E6%99%BA%E8%83%BD%E5%BF%AB%E9%81%9E%E6%AB%83)有助於隱藏您的所在地址。

    </div>

2. **不具名身份** － 不具名身份可以是您常用的穩定化名。 它已不算匿名了，因為不會變動。 如果您是線上社群的一員，可能會希望保留一個其他人熟悉的身份。 這個身份並不算匿名，因為如果長時間監控，就能發現更多擁有者的更多資訊，例如寫作風格、對感興趣主題的知識等。

    為此，您可能需要使用 VPN 來隱藏您的 IP 位址。 金融交易則較難隱藏: 您可以考慮使用匿名加密貨幣，例如 [Monero](../cryptocurrency.md#monero)。 使用山寨幣轉移也有助於掩蓋您的收入來源。 通常，交易所會要求您完成 KYC (客戶身分審查) 程序後，才會允許您將法定貨幣兌換成其他類型的加密貨幣。 線下交易也是一種解決方案；不過，這些選項通常比較貴，且有時也需要 KYC。

3. **匿名身份** － 即使經驗豐富，也很難長期維持匿名身份。 這些應該是需要定期更換的短期身份。

    使用 Tor 可以幫助解決這個問題。 值得注意的是，避免使用即時通訊可以實現更高的匿名性: 即時通訊很可能會暴露打字習慣 (例如，超過一段文字的內容，分散在論壇、電子郵件等平台上。)

[^1]: 2024 年 3 月，發生了一起引人注目的供應鏈攻擊，一名惡意維護者在流行的壓縮庫 `xz` 中加入了一個經混淆處理的後門。 此後門 ([CVE-2024-3094](https://cve.org/CVERecord?id=CVE-2024-3094)) 企圖讓未知方透過 SSH 遠端存取大多數 Linux 伺服器，但在廣泛部署之前就被發現了。
