權限不是一開始隨手點一下的小事，它反映出 App 的設計方式。只要理由清楚，麥克風、相機或區域網路存取權都可能符合嬰兒監視器的需求。若沒有明確必要性卻要求定位、聯絡人或廣告識別碼，家長就該提高警覺。
| 權限 | 合理的情況…… | 需要留意的情況…… |
|---|---|---|
| 麥克風 | 寶寶端裝置需要傳送即時聲音 | App 無法說明為何現在需要此權限 |
| 相機 | 視訊是確實提供且可選用的功能 | 視訊不是核心功能、無法關閉，或在尚未使用前就先要求權限 |
| 區域網路 | App 明確支援在區域網路中探索裝置，或在同一網路上進行設定 | 沒有說明為何需要區域網路存取權 |
| 定位／聯絡人／廣告識別碼 | 只有極少數情況下，且必須有很充分的理由 | 通常不合理，因為與核心監看功能不相符 |
裝置角色邏輯
哪種角色需要哪些權限？
寶寶端裝置
幾乎一定需要麥克風；只有使用視訊時才需要相機；若要透過區域網路配對，可能還需要區域網路存取權。
家長端裝置
通常需要的權限較少：音訊播放、通知，以及可能用於對講功能的麥克風存取權。
選用功能
只有在確實使用視訊、對講或區域網路裝置探索等功能時，才有理由要求額外權限。
提出權限的時機，和權限本身同樣重要
Android 和 iOS 都要求在適當情境下請求受保護資源。對家長來說，可靠的嬰兒監視器 App 會先說明裝置角色，再要求麥克風或相機權限。如果一開啟 App 就要求所有權限，或許對 App 方便，卻不利於建立信任。
對話框的文字也很重要。「此裝置需要麥克風存取權，才能傳送嬰兒房的聲音」就很容易理解。沒有任何情境說明、只寫著「請允許存取」並不夠。在嬰兒房情境中，權限說明的措辭也應該慎重。
Android 與 iOS 雖有不同，但核心問題相同
Android
Android 的指引強調執行階段請求、情境說明，以及確認某項權限是否仍確實需要。實際使用時，電池最佳化往往也是需要考量的一環。
iOS
Apple 將麥克風、相機和區域網路存取視為受保護範圍，並要求在系統提示中清楚說明用途。原則相同：要求存取權可以是合理的，但必須有正當理由。
額外權限往往是最明顯的警訊
當嬰兒監視器 App 要求定位、聯絡人、廣告識別碼或其他不屬於核心產品的權限時，家長應特別留意。不是每項額外權限都一定有問題，但必須有具體理由。說明越籠統，可信度就越低。對家庭和兒童相關產品，標準應比一般生活類 App 更高。
另一個警訊是把核心功能和額外用途混在一起。若一款簡單的聲音監視器突然要求多種系統存取權，這款 App 可能有比家長預期更多的目的。
如何辨識有問題的權限
通常是合理的，例如寶寶端裝置的麥克風，或使用者選擇啟用視訊時的相機。
家長在信任這項要求前，應更仔細查證。
這款產品很可能沒有清楚規劃裝置角色與使用情境。
安裝前的權限檢查清單
- 每項要求的權限是否都能明確對應到看得見的功能？
- 是否在適當時機提出要求，而不是一次全要？
- 寶寶端與家長端裝置是否合理地需要不同權限？
- 定位或聯絡人等額外權限真的合理嗎？
- 視訊是選用功能，還是 App 將相機存取權當成預設要求？
常見問題
為什麼嬰兒監視器 App 需要麥克風存取權？
寶寶端裝置需要麥克風來傳送即時聲音。App 應說明這項請求、只將麥克風用於監看，並清楚處理使用者拒絕權限的情況。
如果我只想要聲音，需要允許相機嗎？
不需要。設計良好的 App 即使沒有相機權限也能使用聲音功能；只有當您選擇啟用視訊時，才會要求相機權限。
為什麼可能需要區域網路存取權？
在 Apple 裝置上，裝置若要在同一個區域網路中探索彼此或建立連線，可能需要這項權限。它不會授予 App 存取檔案或其他私人內容的權限。
來源與延伸閱讀
- 請求 App 權限 · Android Developers
- 請求存取受保護資源 · Apple Developer Documentation
- NSLocalNetworkUsageDescription · Apple Developer Documentation
- MediaDevices：getUserMedia() · MDN Web Docs
- 家庭政策規定 · Google Play 說明
- 使用 Firebase 進行匿名驗證 · Firebase 文件
- Babyphone Timmy 的安全性與架構 · Babyphone Timmy
- *Privacy Not Included－連網產品購買指南 · Mozilla Foundation