Editorial introduction
Both reviewers flagged recipient binding in the native confirmation flow under a compromised hosted-page threat model. This is a static finding, not a reproduced exploit. Origin checks and local-token isolation were recognized as useful controls.
This is a separate bridge-specific review with a Chinese prompt, outside the 16 English-prompt comparison responses.
Download the complete Chinese original
Complete original response (Traditional Chinese)
有風險。最重要的是：原生視窗雖然要求確認，卻沒有可靠地證明收到金鑰的就是視窗所稱的「這個瀏覽器」。 我建議修正後再把它視為安全的配對入口。
本次針對 96ad9d5 做原始碼靜態檢視；未執行 App、攻擊重現或正式環境測試。
-
高風險，需 Cloud 頁面遭控制及使用者確認：可替換配對對象。
CloudPairLocal接收網頁提供的offer，原生確認只顯示本機名稱，沒有顯示接收端的裝置識別或指紋，也沒有把 offer 綁定到目前 WebView 持有的金鑰。使用者同意後，就把該 offer 送進具有本機權限的配對 API。位置：CloudPairing.swift第 245–269 行。因此，若 Cloud 主頁遭 XSS、供應鏈或部署入侵，攻擊者可以提交同帳號下、由攻擊者持有私鑰的有效 offer，誘使使用者按下「與這台機器配對」。後端會驗證帳號與 offer，但無法證明它代表目前這個 WebView；完成後會交付內容金鑰並寫入信任紀錄。事後在網頁核對指紋，無法阻止已完成的金鑰交付。
pairing.go第 332–469 行。建議把接收端金鑰與配對流程綁定到原生持有的狀態，並在交付前完成可信的接收端確認。僅增加網頁提示不足以解決。
-
中風險：舊的助理配對橋在確認後沒有重新檢查來源。
CloudPairAgent在收到訊息時檢查 Cloud 主框架，但原生確認視窗結束後，直接執行handOff；沒有像新的CloudPairLocal再次檢查頁面來源。因此即使頁面已離開 Cloud，舊請求仍可能啟動本機助理工作。這是既有路徑，本 commit 仍保留它。建議導頁立即取消待確認請求，確認後也核對來源與文件世代。CloudPairing.swift第 71–110 行。
已有的防護是有效的：新橋檢查主框架、scheme／host／port，確認後再檢查來源；本機 token 留在原生端，配對 API 也拒絕 Cloud 轉入的管理請求。目前未找到一般外站免確認即可配對的路徑。 來源檢查、本機管理限制。
Fixed but not yet released (awaiting review): Nothing（本次僅審查，未修改）。