無形的牆:reCAPTCHA Mobile Verification 如何將硬體證明擴展至桌面端

多年來,對抗機器人的戰鬥一直透過日益複雜的謎題來進行:識別交通號誌、選擇人行道,以及點擊核取方塊。然而,一場根本性的轉變正在發生。Google 正從行為分析和簡單的謎題,轉向硬體證明 (hardware-based attestation),這一舉措有效地允許服務提供者要求加密證明,以確認使用者正在使用經過核准的裝置與經過認證的作業系統。

雖然這被呈現為對抗詐欺和機器人的安全措施,但這種轉變的影響——特別是透過新的 "reCAPTCHA Mobile Verification"——遠遠超出了機器人緩解的範疇。它代表了我們存取開放網路的一種潛在架構轉變,從「你知道什麼」或「你如何表現」的模型,轉向「你擁有什麼硬體」。

硬體證明的機制

這種轉變的核心是像 Google 的 Play Integrity API 和 Apple 的 App Attest API 這樣的 API。這些系統允許開發者驗證應用程式是否在真實、未經修改的裝置以及經過認證的作業系統版本上執行。

從歷史上看,這些都是以行動裝置為中心的工具。然而,Google 現在正透過 reCAPTCHA Mobile Verification 將此邏輯帶入桌面端。其過程簡單但影響深遠:當桌面使用者遇到無法透過傳統手段通過的 reCAPTCHA 時,他們可能會被要求使用智慧型手機掃描 QR code。這部智慧型手機必須是經過認證的 Android 裝置(運行 Google Mobile Services)或 iOS 裝置。行動裝置接著會執行硬體證明,並為桌面工作階段進行「擔保」。

安全功能還是反競爭工具?

Google 和 Apple 將這些 API 框架化為安全所必需的,特別是對於銀行和政府服務。然而,包括 GrapheneOS 專案在內的批評者認為,這只是反競爭行為的偽裝。

GrapheneOS 的觀點

GrapheneOS 是一個以隱私和安全為核心的 Android 分支版本,是這種附帶損害的主要例子。儘管 GrapheneOS 可能比許多經過認證的 Android 版本更安全,但它仍被禁止通過 Play Integrity API 的 "strong integrity" 層級,因為它沒有取得 Google Mobile Services (GMS) 的授權,且不符合 Google 限制性的授權協議。

"Google 的安全藉口顯然是虛假的,當他們允許使用未修補 10 年的裝置,卻不允許使用更安全的作業系統。這完全是為了透過 GMS 授權來強化其壟斷地位。"

「鎖定」效應

透過將硬體證明作為通過 reCAPTCHA 的要求,Google 創造了一種情境,使得 Linux 桌面、OpenBSD 或自定義 Android ROM 的使用者可能會發現自己被鎖在廣大網路世界之外。如果一個網站要求使用「經過驗證」的裝置來通過驗證碼,就是說唯一的驗證方式是透過 Google 或 Apple 認證的裝置,那麼這兩大巨頭實際上就變成了網路存取的門檻。

更廣泛的生態系統影響

機器人(與爬蟲)的消亡

一些觀察家指出,這項舉措是對 AI agents 和 web scrapers 的戰略性打擊。透過要求使用無法在 headless browser 中輕易偽造的硬體背書金鑰,Google 可以有效地終結從其搜尋結果和其他受保護介面進行的大規模自動化數據收集。

監管悖論

在目前的監管環境中存在著一種苦澀的諷刺。雖然歐盟已花費多年時間對 Google 和 Apple 進行反競爭行為的罰款,但某些歐盟政府同時又在強制要求數位身分、年齡驗證和支付系統使用 App Attest 和 Play Integrity。

這造成了一個循環,即監管機構正在鼓勵他們聲稱反對的「鎖定」行為。

是否有替代方案?

對於希望避免參與這種硬體證明生態系統的網站擁有者來說,選項是有限但存在的。雖然 Cloudflare 和 Google 佔據了市場主導地位,但一些開源替代方案如 AnubisCap 已經存在,且像 Proton 這樣的公司也開發了其內部的驗證碼解決方案,以維持使用者隱私。

結論:網路存取的未來

硬體證明是一種強大的安全工具,但當它透過 reCAPTCHA 應用於一般網路時,它有風險將網際網路從一個開放協議轉變為一個「經許可」的系統。當存取政府服務或銀行的能力取決於你是否擁有特定品牌的硬體與運行特定專有作業系統時,「開放網路」就成了一個誤稱。未來的挑戰將在於,監管機構與開發者是否能能找到一種方法,在不犧牲使用任意硬體與軟體權利的前提下,驗證人類身份。

Sources