iCloud 私密轉送可被繞過，恐暴露真實 IP 位址

iCloud 私密轉送（Private Relay）被發現可能遭到繞過。研究指出，WebKit 的三項功能可能讓網路請求不經過代理路徑直接從裝置發出，導致網站在使用者以為受到保護的情況下，仍取得其真實 IP 位址。

要理解這個問題的嚴重性，得先看私密轉送的設計目的。這項服務的運作方式是把使用者的網路流量經過兩層中繼——第一層知道使用者身分但不知道目的地，第二層知道目的地但不知道使用者身分。這種雙層設計讓任何單一方都無法同時掌握「誰」與「去哪裡」，藉此保護使用者的瀏覽隱私。IP 位址的隱藏是其中的核心機制，因為 IP 能大致定位使用者的地理位置與網路服務商。

繞過之所以會發生，源於瀏覽器引擎中並非所有的網路行為都經過同一條路徑。某些底層功能——例如 DNS 的預先解析、特定的驗證流程、或新型的傳輸協定——在實作上可能直接從裝置發出請求，而未套用代理設定。這類「旁路」通常不是刻意設計的漏洞，而是不同功能模組在演進過程中未能完整涵蓋隱私路徑的結果。

這也凸顯了隱私保護機制的一個結構性難題：保護的有效性取決於最弱的環節。一個系統即便在主要路徑上做得再完整，只要有任何一條旁路存在，整體的保護承諾就被打破——而使用者無從得知這種情況正在發生，因為介面上顯示的仍是「已保護」的狀態。這種「以為安全其實不安全」的狀態，某些情況下比明知不安全更為危險，因為它會影響使用者的行為決策。

對一般使用者的實際影響需要按情境評估。對多數人而言，IP 外洩的後果主要是廣告追蹤與地理位置推斷，屬於隱私層面的困擾；但對記者、異議人士或身處敏感環境的使用者，IP 位址的暴露可能帶來實質的人身風險。這類高風險使用者通常會採用更嚴格的防護方案，但若他們誤信單一機制的完整性，風險便會被低估。

從產業層面看，這類問題並非個案。近期已有多起類似的揭露，指出瀏覽器與作業系統層級的隱私功能在特定條件下可被繞過。這反映的是隱私工程的複雜度——當系統包含數十個網路相關的子功能，要確保每一個都遵循同一套隱私政策，需要持續且系統性的驗證。

後續觀察重點包括：修補的釋出時程與涵蓋範圍、相關功能的隱私路徑是否納入常態測試，以及類似旁路在其他瀏覽器引擎中是否存在。