Typeless 事件：把常駐輸入工具當成資安產品來審查

最近在 X 看到一則對 macOS 音聲輸入工具 Typeless v0.9.3 的逆向分析，讀完我覺得它值得被放大討論，但討論的焦點不該停在「這個產品是不是雷」。

凡是「常駐 + 讀取輸入 + 讀取畫面/上下文」的工具，導入方式應該比一般 SaaS 更嚴格。把它當成資安產品來審，你會省下很多事後補洞的成本。

（註：下述「觀測到的行為」來自原作者公開的分析整理。我沒有在自己的環境重跑每一條驗證，因此會把內容寫成「風險評估框架 + 最小可行檢查清單」，避免把未親證細節寫成既定事實。）

這類工具為什麼特別敏感？

站在工程與企業落地的角度，語音輸入/聽寫工具通常同時具備兩個特性：

• 它需要長時間常駐在系統層，才能「在任何 App 都能輸入」（權限很大）
• 它會處理或接觸到你正在做的工作內容（資料很敏感）

所以它的風險上限，從來都不是「打字變慢」；真正的上限是：憑證、內網資訊、客戶資料、會議內容被一併帶走。

原作者指出的幾個關鍵疑慮（用風險語言重述）

以 Typeless 這個案例為例，原文的訊號大致落在四類：

• 資料是否真的在本機處理：貼文指出音訊可能透過 WebSocket 送往雲端（並非本機模型推論），而「On-device」的描述更接近「歷史紀錄存本機」
• 蒐集的上下文範圍是否過大：包含完整 URL、前景 App 與視窗標題、螢幕可視文字（Accessibility API）、剪貼簿、鍵盤事件監控（CGEventTap）等
• 資料落地與保留：貼文指出本機 DB（如 typeless.db）可能以明文保存轉寫與上下文，甚至音訊檔也可能殘留
• 供應商信任門檻：法人/資安稽核/聯絡方式等透明度不足，使得「即使它需要高權限」也難以建立信任

把這些放在一起看，你會發現問題核心不在「雲端 STT 很邪惡」。雲端語音轉文字本身是常見架構。

真正需要被問清楚的是：你送上去的到底是什麼？你能不能追蹤？你能不能回收？

我會用的最小可行檢查清單（給 PM / IT / 資安一起用）

如果你的公司正在 PoC 任何「語音輸入 / 常駐聽寫 / AI 輸入法」工具，我會建議先用這份清單做一輪 triage：

• 權限盤點：它要哪些 macOS 權限（Input Monitoring / Accessibility / Screen Recording / Full Disk Access）？每一項都能對應到清楚的產品需求嗎？
• 網路行為：待機時是否仍對外連線？目的地網域/IP 是否固定且合理？是否可被代理或封包工具監控？
• 資料範圍：除了音訊/文字，是否會收集 URL、可視文字、剪貼簿、DOM 元素等上下文？哪些是必要、哪些是加分功能？
• 資料落地：本機是否產生 DB / cache / 音訊檔？是否加密？如何清除？卸載後是否確實移除？
• 事故可稽核：出了事能不能回答三個問題：什麼時候、哪台機器、哪些資料被送出？
• 供應商透明度：法人資訊、資安聯絡窗口、稽核報告或第三方認證。未必都要有，但至少要能對話、能被追責

你不需要把每項做到滿分，但至少要能做到這句話：我知道它在什麼時候把哪些資料送到哪裡。

我會怎麼建議團隊落地處理（兩段式）

1. 先止血：暫停擴大部署，尤其是會碰到客戶資料、內網憑證、管理權限的機器。
2. 再驗證：由資安/IT 做快速檢測（權限、封包、落地檔、更新來源），再決定封鎖、例外放行，或替換工具。

替代方案：把「輸入」留在本機，先把風險天花板壓低

如果你們的需求允許，我會優先評估「可以真正在本機推論」的路線，例如：

• macOS 內建語音輸入（Apple Silicon 上有相當多 on-device 能力）
• Whisper.cpp / MLX Whisper（OSS，可做到本機推論）
• 其他商用工具（就算宣稱本機，也建議照同一份清單驗一次）

這不是保證安全，而是先把最壞情境的爆炸半徑縮小。

最後收束：這不是在獵巫，是在補上「效率工具」常缺的那一條流程

很多團隊導入新工具時，流程只跑到「有沒有變快」。

但常駐輸入工具要多問一題：「它最快能把什麼帶走？」

把它當成資安產品來審，你會更接近可控的落地。

引用來源：

• X：@medmuspg