2025 年寫這篇文章時，我想把討論從「卡片能不能被改」往整體設計多推一步：哪些資料需要保護？系統如何發現不一致？風險由誰承擔？而除了金額之外，還有哪些不容易被看見的問題？

這次整理保留這個出發點，並修正原文對 CAP 和卡片識別碼的過度簡化。本文是架構與風險的討論，不是對目前所有悠遊卡型號或後端防護的實測報告。

離線交易有取捨，但漏洞不是 CAP 的必然結果

交通票證要考慮讀卡速度、設備連線條件及交易持續運作的需求。如果交易當下不必每次等待中央系統確認，就需要處理之後如何對帳、辨識異常和恢復狀態。

這可以用分散式系統的角度理解，但不能直接推論特定系統的全部實作。原文把悠遊卡概括成「犧牲一致性」，說得太快了。

Gilbert 與 Lynch 的 CAP 論文處理的是特定模型中，網路分割期間一致性與可用性的限制。它不是所有時候都任選兩項的口訣，也不能解釋或正當化密碼學設計的弱點。資料尚未同步，與未授權的人能偽造資料，是需要分別處理的問題。

看整體防線，也要知道每一層的限制

討論風險時，我會分開看卡片與讀卡設備、交易驗證、後端紀錄、異常偵測，以及事件發生後的處理。不同措施能減少不同損失，不能只因為存在後端對帳，就假設所有攻擊都會立即被阻擋。

補償性措施也有使用條件。隔離、限制額度或加強偵測是否足夠，要看能降低多少風險、持續多久、由誰接受剩餘風險，以及是否有退場計畫。這些需要證據，而不是一句「還有別的防護」。

NXP 對 MIFARE Classic 的產品說明引導安全相關應用考慮其他產品系列。因此，評估舊技術的遷移仍然有必要。至於哪些卡片或用途需要如何更換，應先確認實際型號、部署方式及主管機關與營運者的公開資料。

金額之外，還有識別碼的隱私

我原文最在意的另一個問題，是卡片識別碼能否讓不同次的觀測被串起來。

依 NXP 的 UID 說明，識別碼有不同形式與處理方式，不能把所有卡片都假設為永遠固定且唯一。若某張卡對讀取者呈現穩定識別碼，多次觀測便可能被關聯；但讀到 UID 本身，不等於立刻取得持卡人的姓名、完整消費紀錄或移動軌跡。

要進一步識別一個人，還需要其他資料、觀測機會與連結條件。讀取範圍和設備能力也有限制。把這些條件講清楚，才不會讓值得討論的隱私風險被寫成任何人都能隨時做到的追蹤能力。

原文也提過發光卡片的燈號。這種現象不能可靠地判斷附近是否存在惡意讀取器，更不能用來證明沒有被讀取；因此不把它當成隱私防護或偵測方法。

制度要能限制資料用途

即使某種資料技術上可以取得，也不代表每個用途都合理。我會希望票證系統的討論包括：誰能蒐集識別資訊、保存多久、能不能與其他紀錄串接，以及用途結束後如何停止。

原文曾用「票證實聯制」作假想情境，那不是政府曾實施的事實，而是提醒：為了一次方便建立的資料連結，可能比原本用途存續得更久。

把金額完整性、交易可用性和個人隱私分開評估，才能知道每道防線實際保護了什麼，也才能認真討論技術與制度各自需要怎麼改。