PayPal App 對 GrapheneOS 全面失效　Android 開源安全分支再撞銀行 app 牆

編按：本文綜合整理自 Hacker News 討論串（leumon）、GrapheneOS Attestation 相容性指南，並加入 Siami 編輯部觀點與分析。

事件經過：PayPal 對 GrapheneOS 全面失效

2026 年 8 月 27 日，使用者 leumon 在 Hacker News 上發文表示，PayPal 的 Android App 在 GrapheneOS 上徹底無法開啟。他原本想用 PayPal 設定的 NFC 感應支付卡片，結果每次啟動 App 都會立刻崩潰，畫面上只留下一段錯誤訊息：

com.paypal.oslo.app.rasp.RootDetectionSecurityException: Security policy violation: s=root

這段錯誤訊息的重點是 s=root——PayPal 的反篡改偵測（RASP，Runtime Application Self-Protection）誤判 GrapheneOS 的環境為「已 root」。但 GrapheneOS 並不是 root，它是一個完全保留標準 Android 安全模型的替代作業系統。

真正的原因：PayPal 的 anti-tampering 寫壞了

事件發生後，GrapheneOS 官方帳號在 Hacker News 親自下場回應，明確表示這不是 PayPal 主動封鎖：

PayPal 並沒有禁用 GrapheneOS。他們最近一次更新不小心送出了錯誤的反篡改程式碼，與我們的 secure app spawning 功能（透過 exec 為每個 App 啟動獨立的 ASLR 與記憶體標記）不相容。只要把 PayPal 的 per-app secure spawning 開關關閉就能暫時解決。 —— GrapheneOS 官方

GrapheneOS 進一步解釋，這是 PayPal 工程師的 bug，不是政策：

1. Secure app spawning 是 GrapheneOS 的強化功能，讓每個 App 啟動時都拿到全新的記憶體位址配置與記憶體標記（memory tagging），大幅提升沙箱隔離強度。
2. PayPal 的 anti-tampering code 會偵測執行環境是否被竄改，這次新版的檢查邏輯把「secure spawning 給每個 App 獨立位址空間」誤判為環境被篡改。
3. 解決方法：在 GrapheneOS 的 App 設定中，把 PayPal 的 secure spawning 切換關閉（屬於 exploit protection 系列開關的一部分）。

換句話說，這是 PayPal 工程團隊在更新前沒有在 GrapheneOS 上做回歸測試所導致的意外，與 GrapheneOS 的安全性無關。

為什麼這件事重要

這次事件不只是「一支 App 壞掉」這麼簡單，而是凸顯了一個更大的結構性問題：Android 生態系的銀行與支付 App 對「非 Google 認證設備」的相容性正在變差，但理由往往不是安全，而是法規責任與商業考量。

GrapheneOS 是什麼？

• 是一套完全開源的 Android 替代作業系統，由開發者 Daniel Micay 領導，目標是強化 Android 的隱私與安全。
• 保留所有 AOSP（Android Open Source Project）的標準安全機制，再加上更嚴格的記憶體隔離、網路權限控制、感測器權限、動態程式碼載入限制等。
• 被多家資安研究機構、隱私倡議者與企業部署，是目前主流非 Google Android 系統中最成熟的一個。

銀行 / 支付 App 的相容性困境

GrapheneOS 維護了一份 banking-apps-compat-report，追蹤各家銀行 App 在 GrapheneOS 上的運作狀況。目前大約有 10% 的銀行與政府 App 完全無法在 GrapheneOS 上執行，原因幾乎都和 Play Integrity API 有關：

GrapheneOS 官方在 attestation-compatibility-guide 中明確建議開發者改用標準 Android 硬體 attestation API 而非 Play Integrity API，因為前者可以驗證 GrapheneOS 的官方簽章金鑰，並提供更強的安全性（包含金鑰廢止機制）。然而實際上多數銀行 App 仍採用 Play Integrity API，原因是它對銀行內部資安團隊來說「比較簡單」。

數據解讀：這次的經濟規模有多大？

雖然這次是 PayPal 單一 App 的 bug，但事件背後的市場規模值得注意：

• PayPal 全球活躍帳戶：截至 2026 Q2 約 4.3 億活躍帳戶，其中行動支付佔比超過 60%。
• GrapheneOS 使用者基數：社群估算約在 10 萬至 50 萬之間，佔全球 Android 使用者不到 0.01%——所以從 PayPal 的商業角度來看，修這個 bug 的優先順序自然很低。
• NFC 感應支付的成長：歐洲市場中，PayPal 與 Curve Pay 都有支援 GrapheneOS 上的 NFC 感應支付；Google Pay 因為用 Play Integrity API 完全封鎖 GrapheneOS。也就是說，PayPal 對 GrapheneOS 來說幾乎是唯一可用的 NFC 感應支付選項——這也解釋為什麼事件一出來，HN 討論串的迴響特別熱烈。

質疑：為什麼 PayPal 不直接改用硬體 attestation？

從技術角度來看，PayPal 完全有能力修這個問題，而且 GrapheneOS 也提供了具體的解法：

1. 在 anti-tampering code 中加入 secure app spawning 的白名單判斷
2. 或者改用 GrapheneOS 已經完整支援的標準 Android 硬體 attestation API
3. 或者在自家 App 內提供 compatibility mode toggle 給使用者手動關閉 anti-tampering

但截至發稿，PayPal 沒有任何公開回應，社群需要靠 GrapheneOS 提供的 workaround 來暫時解決。這顯示出大型支付平台對「非主流裝置」缺乏測試資源與動機——這也正是 HN 上多位留言者批評的「科技大廠無能」的具體展現。

Siami 觀點：開源 vs. 商業 App 的拉扯才剛開始

這次事件是 Android 生態系的縮影：開源系統帶來更強的安全模型，卻被商業 App 的黑名單機制無差別掃到。GrapheneOS 創辦人 Daniel Micay 在多個公開場合強調，GrapheneOS 並未 root，但銀行的 anti-tampering code 往往用簡化的啟發式檢查，把任何「看起來不像原廠 Android」的環境都視為威脅。

從使用者角度來看，這次事件有兩個值得思考的方向：

1. 短期 workaround：GrapheneOS 使用者可關閉 PayPal 的 per-app secure spawning 來恢復功能，但這會降低 PayPal App 本身的沙箱隔離強度。
2. 長期方向：要徹底解決，必須由 PayPal 等大型支付平台改用硬體 attestation 或至少為 GrapheneOS 等開源系統加入白名單。但商業誘因不足的情況下，這件事的推動速度會非常慢。

對台灣與中文圈的讀者來說，這個議題也值得關注——台灣的銀行 App（如中信、玉山、台新等）目前並未明確聲明是否支援 GrapheneOS，多數仍依賴 Play Integrity API。如果你是重視隱私的 Android 進階使用者，這是一個值得持續追蹤的發展。

技術細節補充

Secure App Spawning 是什麼？

• 機制：用 exec() 而不是 fork() 來啟動每個 App 的 process。
• 好處：每個 App 拿到完全獨立的 ASLR（位址空間配置隨機化）、隨機的記憶體標記（memory tags）以及 canary 值。
• 代價：少數有 anti-tampering 的 App（特別是金融類）會誤判這種隔離機制為環境竄改。

完整的 workaround 步驟

GrapheneOS 使用者遇到 PayPal 崩潰時可這樣處理：

1. 進入 設定 → Apps → PayPal → Exploit protection
2. 把 Secure app spawning 開關關閉
3. 重新啟動 PayPal App

更簡單的方式：直接開啟 Exploit protection compatibility mode，會自動把多個開關一起調整為相容模式。

編按：PayPal 截至 2026-08-28 尚未對此事件發出官方聲明。GrapheneOS 已在多個社群平台確認 workaround 有效。本文將持續追蹤 PayPal 是否會在後續版本修復 anti-tampering 邏輯。