「這個 App 有端對端加密」常被直接理解成「完全沒有任何紀錄留下」，但這中間其實有一些技術上的細節被簡化掉了。這篇文章想把端對端加密實際涵蓋的範圍講清楚。
誤解一：加密就代表什麼都看不到
端對端加密保護的是訊息內容本身，但時間戳記、路由等中繼資料通常不在加密範圍內。
端對端加密（End-to-End Encryption, E2EE）保護的核心是「訊息或通話的實際內容」——文字、語音、影像本身。但要讓通訊順利運作，還需要一些「中繼資料」（metadata），例如封包的時間戳記、序號、路由資訊，這些通常不在加密保護的範圍內，因為系統需要這些資訊來維持連線品質、進行封包轉發。也就是說，「聊了什麼」被保護，但「什麼時候聊、聊了多久、跟誰聊」這類中繼資料，不一定完全隱藏。
誤解二：「有加密」不等於「端對端加密」
視訊通話標榜「有加密」，但常是逐段加密，伺服器會先解密再轉發，不算真正端對端加密。
這是最容易被混淆的地方。很多視訊會議或通話服務會說自己「有加密」，但實際架構可能是「逐段加密」（hop-by-hop encryption）——資料在使用者裝置與媒體伺服器（SFU，Selective Forwarding Unit）之間是加密的，但伺服器本身會先解密才轉發給下一位參與者，這代表伺服器營運方技術上是可以存取到內容的。真正的端對端加密，是只有通訊的兩端（或所有端）能解密，中間經手的任何伺服器都無法讀取內容，這需要額外的技術設計（例如 WebRTC 的 Insertable Streams／Encoded Transform API）才能達成。
下表整理三種常見架構的差異：
| 架構 | 伺服器能否讀取訊息內容 | 說明 |
|---|---|---|
| 端對端加密（E2EE） | 不能 | 只有通訊兩端能解密，需額外技術設計（如 WebRTC Insertable Streams） |
| 逐段加密（Hop-by-hop，SFU） | 能 | 媒體伺服器會先解密才轉發給其他參與者 |
| TURN 中繼伺服器 | 不能讀取內容，但可能經手連線資訊 | 只轉發已加密封包，用於 NAT 穿透 |
誤解三：P2P 連線一定完全不經過任何伺服器
多數情況下 P2P 通訊確實不經伺服器，但某些網路環境仍需 TURN 中繼伺服器協助轉發。
點對點（P2P）通訊常被理解成「訊息直接在兩個裝置之間傳輸，完全不碰任何伺服器」，多數情況下確實如此。但在某些網路環境下（例如企業防火牆或特殊的 NAT 環境），兩個裝置可能沒辦法直接建立連線，這時候 WebRTC 技術會透過 TURN 中繼伺服器協助轉發資料——這是處理 NAT 穿透的標準機制。TURN 伺服器的角色只是轉發已經加密的封包、不會解密應用層的內容，但技術上它仍可能經手連線建立過程中的必要網路資訊，例如 IP 位址。
這些細節重要嗎
對多數人來說，端對端加密已經保護了最核心的隱私需求；但若你在意中繼資料，細節仍值得了解。
對多數人來說，「訊息內容被保護、不會被讀取」已經是最核心的隱私需求，端對端加密確實做到了這件事。但如果你的威脅模型包含「不希望任何人知道我跟誰聯繫、聯繫了多久」，那中繼資料與連線架構的細節就值得多了解一點，不要只看到「加密」兩個字就假設所有面向都被涵蓋了。
想了解具體的隱私技術細節？看看 JustUs 的隱私政策
只和一個人連線的私密通訊：訊息不經伺服器，關掉 App 就消失
常見問題
端對端加密真的安全嗎？
就保護「訊息內容不被第三方讀取」這個目標來說，端對端加密是目前最有效的技術之一。但它不代表所有面向的隱私都被涵蓋，例如中繼資料的處理方式仍需要個別了解。
什麼是中繼資料（metadata）？
中繼資料是「關於資料的資料」，例如訊息傳送的時間、雙方的連線資訊、封包大小與路由，而不是訊息本身的內容。這些資訊即使在端對端加密的系統中，通常仍需要保持可讀取，才能維持連線運作。
TURN 伺服器會看到我的訊息內容嗎？
不會。TURN 伺服器的功能是轉發已加密的封包，不會解密應用層的內容。但它在轉發過程中技術上可能經手連線相關的網路資訊。
怎麼判斷一個 App 是不是真正的端對端加密？
可以查看該 App 的隱私政策或技術文件，是否明確說明採用端對端加密架構，以及伺服器是否有機會存取未加密的內容（例如是否為逐段加密的 SFU 架構）。
一般聊天 App 都有端對端加密嗎？
不一定，這取決於各家服務的技術架構，有些預設開啟、有些需要手動開啟特定模式（例如「私密對話」），有些則完全沒有提供端對端加密，建議查看個別服務的說明。