相機隱私權快門和終止開關

發行項
02/07/2024

本文提供隱私權快門或終止開關的裝置設計指引、快門狀態檢測的考慮，以及快門預期如何與指標 LED 的現有 HLK 需求互動。

常見的LED需求

不論快門或終止開關為何，HLK 都需要在 ISP 擷取感測器數據時，可見指示器 LED 會開啟。針對 RGB 相機，如果相機為使用中，單一可見的 led led (例如白色、綠色、藍色等) 必須是 ON：

上的 RGB 相機

對於具有 RGB+IR 感測器的相機而言，這可能會比較複雜，因為 IR 相機需要光源 LED，而光源 LED 可能會使用可見的 (850 nm) 或可見的 (940 nm) 。此外，應用程式可以自行串流處理 IR 感測器、RGB 感測器本身或同時串流。

使用可見的充電器 IR 光源設計，可以選擇使用 IR 光源 LED 作為可見指示器 LED。這表示如果 IR 相機本身開啟，IR 光源 LED 會滿足 HLK 需求：

IR 光源LED燈

使用不可見的充電器 IR 光源設計必須使用可見的充電 LED，以指出 IR 相機何時作用中，以符合 HLK 需求。我們建議共用使用中的相機指示器 LED，讓 IR 感測器和/或 RGB 感測器開啟時相同的可見光 LED 開啟：

IR 感測器和或 RGB 感測器已開啟

建議所有設計在使用 IR 或 RGB 相機時開啟一般使用中的指示器 LED，不論 IR 光源 LED 是否使用可見的裝訂器 LED。以下是核心 LED 需求的完整資料表：

Stream 狀態	可見 IR LED (850 nm)	無可見 IR LED (940 nm)
相機關閉	LED OFF	LED OFF
只有 RGB 相機開啟	使用中指標 ON、IR 照明器 OFF	使用中指標 ON、IR 照明器 OFF
只有 IR 相機開啟	非必要使用中指標，但建議 ON	使用中指標 ON、IR 光源開啟
上的 RGB 和 IR 相機	使用中指標 ON、IR 光源開啟	使用中指標 ON、IR 光源開啟

注意

LED 需求對於相機隱私權快門或相機終止開關的設計可能會有所不同。如需相機隱私權快門和相機終止開關 HLK LED 需求的資訊，請參閱相機隱私權快門 LED 需求。

Always-on AI 體驗 (例如相機型人類存在)

對於支援一律開啟相機型 AI 功能的裝置，其中 AI 晶片會共用主要相機感測器，當專用存在晶片獨佔存取相機時，LED 需求會有所不同。如需詳細資訊，請參閱 Microsoft 合作夥伴中心的目前狀態報告白皮書。

硬體隱私權控制

當相機設計包含硬體隱私權控制時，我們的設計指引有兩個主要原則：

具有隱私權控制措施的裝置必須提供一致的用戶體驗，並確信隱私權狀態：
- 一旦客戶瞭解其裝置上的快門外觀和行為，該知識應該套用到他們使用的任何具有快門的裝置。
在沒有任何情況下，相機隱私權控制可能會對隱私權產生誤判：
- 裝置在對客戶而言最重要的時，不得無法提供隱私權。如果相機隱私權快門關閉，或相機終止開關關閉，客戶預期在與實體控件互動以停用隱私權功能之前，無法擷取任何影像。

控件的類型

定義了兩種形式的隱私權控制，相機隱私權快門 (機械和機械式) 和相機終止開關。根據裝置的規格、BOM 成本目標和裝置的價格點，OEM 可以選擇在任何這些窗體中實作快門。這三項的重要常數是，它們必須在實體或硬體層級採取行動，這表示不會涉及任何軟體，因為軟體可能會遭到入侵。

機械相機隱私權快門

機械式快門是最簡單的設計，這些是使用者手動採取動作來封鎖相機的簡單滑動鏡頭。其設計方式是使用不透明材質，在關閉時完全封鎖鏡頭。此設計原本就很無理，因為它們實際上無法遭到入侵，以透過使用者滑動它以外的任何方式開啟。

電動相機隱私權快門

電動機械式快門是電子控制的機械式快門。整合式快門會開啟/關閉，而不是使用者手動開啟或關閉快門，以回應裝置上實體按鈕的按下。

注意

雖然此解決方案通常需要韌體，但應該與其他元件隔離。換句話說，快門控制器和按鈕不應該有通訊總線等攻擊向量，或重新編譯韌體的能力。設計必須需要硬體互動，而且無法從軟體控制。

相機終止開關

現在有些裝置隨附相機終止開關功能，在關閉時實際中斷相機裝置與系統的連線，提供硬體控制來封鎖相機存取，而不需要實體快門來涵蓋鏡頭/感測器。雖然這是針對攻擊的強大功能，但它會產生不佳的用戶體驗。藉由在關閉開關時移除裝置，系統無法分辨底座仍然有相機，但剛關閉。如果使用者不小心關閉相機而不知道交換器，因為應用程式會回報沒有連線的相機，所以從 UX 觀點來看，這有問題。如果相機在使用期間移除，或在應用程式執行時出現，它也會造成某些應用程式當機或錯誤。

因此，Microsoft 不建議或支援使用從系統移除整個相機的相機終止開關。相反地，我們建議下列兩個解決方案之一：

實體快門，如機械相機隱私權快門和機械式相機隱私權快門中所述。
中斷感測器而非 ISP 的終止開關，並導致 ISP 合成黑色畫面。

針對第二個解決方案，相機仍會出現在系統中，而且應用程式可以繼續使用它。 ISP 會回應所有命令， (啟動/停止串流、亮度或對比等 DIS、媒體類型變更等) 正常，不論終止開關是否作用中。不過，啟動終止開關時，ISP 會停止從感測器擷取實際數據，並改為合成並串流黑色畫面格，所有從應用程式的觀點來看都是透明的。

面板上有多個相機的快門

例如，當客戶使用具有快門的裝置 (時，面板上具有多個 IR 和 RGB 相機的快門，) 他們預期如果關閉快門，隱私權會受到保護，以防止任何非預期的相機存取。當系統在同一個面板上有兩部相機，例如 RGB 和 IR 相機來支援 Windows Hello 時，請務必確保快門不會提供誤判的安全性。客戶不預期瞭解可能有第二個相機感測器用於 Windows Hello，而某些裝置會針對 RGB+IR 使用單一感測器。因此，快門必須涵蓋面板上的所有相機。

確保快門和終止開關適用於 IR 相機非常重要，因為應用程式可以存取 IR 相機，併產生場景的合理高精確度影像，如下所示。無法遮蔽 IR 感測器，代表在快門隱私權優點中，使用者信任的誤判和缺口。

來自 Microsoft 參考感測器的 IR 影像

注意

Windows Hello 臉部需要 RGB 和 IR 相機。如果遮蔽 RGB 相機，Windows Hello 將無法正常運作。 RGB 和 IR 資料流都用來啟用反詐騙計數器量值。

實體快門設計指引 (機械或機械)

當客戶使用具有實體快門的裝置時，快門的存在會提供關於其所提供的隱私權層級的強烈隱含期望。簡單來說，該使用者期望是，如果裝置有快門，而且快門已關閉，他們就會受到保護，以防止任何非預期的相機存取。此功能的實作必須符合隱含的期望，否則會失去所有信任。

此外，隱私權快門的整個概念是提供針對任何實際軟體攻擊強化的安全性層級。換句話說，如果裝置有快門，且系統受到惡意軟體完全入侵，則該軟體無法危害用戶的隱私權。同樣地，若要簡單來說，預期只有在用戶實際與裝置上的硬體快門控件互動時，快門才能變更狀態。

機械設計考慮

無論是手動或機械式動作的實體快門，預期都是由不透明材質所組成，以在關閉時完全封鎖感測器，並讓裸眼看得見：

不透明材質會在裸眼看得見關閉時封鎖感測器

如在面板上具有多個相機的快門所述，相同面板上具有個別 IR 和 RGB 相機的裝置，在關閉快門時必須同時封鎖這兩個感測器。假設雙感測器設計如下：

雙感測器設計

關閉快門時，必須涵蓋 RGB 感測器，選擇性地涵蓋 IR 感測器：

當關閉快門必須涵蓋這兩個感測器時

注意

我們目前支持相機的豁免，其機械式快門設計並未涵蓋 IR 相機。當實體快門遮蔽 RGB 相機時，ISP 韌體可接受捨棄 IR 相機的影像輸出，並將它取代為合成黑色影像。不過，如果 IR 感測器用於目前狀態感測器，建議您不要涵蓋 IR 感測器，並確保目前狀態感測器正常運作。如需詳細資訊，請參閱 Microsoft 合作夥伴中心的目前狀態檢測白皮書。未來的 HLK 更新會採用此例外狀況，而且只需要實體快門才能實際遮蔽 RGB，以確保解決方案的健全性，以及更強大的客戶隱私權保護。

相機行為考慮

當相機配備實體快門時，無論快門狀態為何，相機都必須繼續正常運作。如果應用程式從相機進行串流處理，即使關閉了門門，仍會繼續擷取並傳輸真實感測器數據。關閉的快門會完全遮蔽感測器，預期會產生黑色或非常接近的影像。

OEM 可以選擇在關閉快門 (時，將影像取代為靜態影像，例如，相機的圖片會透過它) 斜線。此映像必須是靜態的，且無法從軟體變更，以防止惡意探索。對於隱私權快門的裝置，映像更換可能會在 ISP 或驅動程式內發生，不過建議在 ISP 內取代，以減少 DMFT 的需求，以及將負載新增至主機裝置。

相機隱私權門 LED 需求

LED 需求必須遵循指定的常見 LED 需求。這表示，如果面板上有任何相機開啟，無論是否開啟或關閉門門，使用中的相機 LED 都必須保持開啟狀態。不過，當關門關閉時，可接受快門的實體設計來涵蓋LED。下圖說明相機主動串流時的案例：

相機正在主動串流

針對同時包含 IR 和 RGB 相機的設計，如果關閉門門時使用 IR 相機，某些製造商可能會想要關閉 IR 光源 LED。建議您不要這樣做，因為它會為較少的值增加額外的複雜度;只有在 Windows Hello 正在執行時，IR 相機才會處於作用中狀態，而且 Windows Hello 在此期間顯示一則訊息，指出它正嘗試登入，但關閉了門門。如需詳細資訊，請參閱 Kill switch 實作。

不過，如果 840 nm (可見) IR 光源 LED 不是 IR 相機的唯一使用中 LED (，一般可見的白色/綠色/藍色 LED 會在 IR 相機作用中) 時亮起，則設計可能會在關閉門門時關閉 IR 照明器 LED 關閉。

快門狀態切換機制

實作隱私權快門的裝置不得允許任何形式的軟體控制，而且只能開啟或關閉快門，以回應用戶明確與快門控件互動。此門門控件可能是機械滑桿，或是可啟動機械式門道的實體按鈕。即使硬體控制項可以覆寫軟體並保持關閉關閉狀態，也不會變更快門狀態，因為關閉的快門不一定表示已啟用隱私權控制。同樣地，基於相同原因，快門可能不會在使用相機的應用程式上開啟或關閉。總而言之，如果使用者瀏覽裝置並看到關閉了門門，他們必須能夠明確推斷其隱私權受到保護，直到他們採取實體動作來開啟快門為止。

快門狀態感測器和報告

市場內相機隱私權設計的許多問題都源自使用者不小心關閉快門的情況，而且無法找出其相機產生空白影像或無法運作的原因。因此，Windows 隱私權快門功能的重要部分依賴相機能夠可靠地報告其快門狀態。透過這項資訊，應用程式可以通知使用者關閉快門，讓他們可以據以回應。在事件發生之後，應該儘快偵測並報告快門狀態變更。

建議使用兩種方法來檢測快門狀態、 實體感測器和 韌體型偵測。如果源自 UVC 裝置，這兩種方法都會透過 CT_PRIVACY_CONTROL 報告偵測到的快門狀態，如果源自 AVStream 或 DMFT 驅動程式 ，則KSPROPERTY_CAMERACONTROL_PRIVACY 。

如需詳細資訊，請參閱隱私權快門通知。

實體狀態偵測感測器

您可以使用實體感測器偵測到快門狀態，以偵測是否開啟或關閉快門。實體感測器可以決定性地報告快門狀態，並提供更可靠的體驗。 Microsoft 沒有任何關於感測器設計的特定指引，或感測器技術的特定建議。

ISP 韌體型狀態偵測

有些設計可能會選擇略過實體快門，並改用 ISP 內的韌體來處理影像，並報告推斷的門門狀態。這類解決方案會分析韌體中擷取的影像，並將其與閾值進行比較，以判斷快門是否似乎關閉。這是低成本的解決方案，因為它不需要任何新元件，也能夠偵測感測器上磁帶之類的專案。不過，選擇使用這類設計時，有兩個重要考慮：

設計可能會誤報深色環境中的封閉式門門。不過，這應該是最低風險/問題，因為攝影機仍然無法在這類低光環境中使用。
除非 ISP 能夠在感測器離開 D3 時定期從感測器進行取樣，否則此方法可防止應用程式查詢精確的感測器狀態數據，直到從相機開始串流處理為止。

上述第二個考慮會產生挑戰。如果相機在未串流時無法回報快門狀態，但應用程式已寫入以在串流之前檢查並回應快門狀態，可能會發生不良狀況。為了回應我們收到來自合作夥伴的意見反應，此需求已寬鬆。我們也更新 API 檔，以建議軟體開發人員根據未串流時回報的快門狀態做出決策。例如，如果快門回報關閉，我們會明確建議應用程式開發人員不要開啟相機。

為了避免不遵守這項建議之 app 的相容性問題風險，預期不會串流時無法感知快門狀態的相機，會報告每當未串流時，快門為 OPEN。否則，如果相機在未串流時可以感知快門狀態，則預期會在不進入 D3 時偵測並報告快門狀態。

注意

影像分析型快門偵測算法應該一律在韌體中實作，而不是驅動程式，以避免增加 CPU 負載，以及達到最大健全性。

下圖說明具有相機隱私權快門之裝置的預期行為：

具有相機隱私權快門之裝置的預期行為

相機隱私權快門行為摘要表

下表摘要說明相機隱私權門 (手動或機械式) 的預期行為：

ISP 狀態	門門狀態	可見指示器LED	串流至計算機的影像	報告CT_PRIVACY_CONTROL狀態
Idle/D3	已開啟	關閉*	N/A	已開啟
Idle/D3	封閉式	關閉*	N/A	打開**
串流處理 (任何應用程式)	已開啟	開啟*	擷取的感測器影像	已開啟
串流處理 (任何應用程式)	封閉式	開啟*	擷取的感測器影像	封閉式

(*) 如需指標 LED 需求的詳細資訊，請參閱相機隱私權快門 LED 需求和快門狀態切換機制。

(**) 請參閱快門狀態檢測和報告以取得詳細數據，在某些情況下，快門狀態在未串流時仍會更新。

終止開關設計指引

當客戶使用具有終止開關的裝置時，他們會將信任放在硬體交換器中，以強固地防止任何嘗試擷取其映像的應用程式。簡單來說，該使用者期望是，如果我的裝置有終止開關，而且已啟動終止開關，我的隱私權會受到保護，以防止任何非預期的相機存取。此功能的實作必須符合隱含的期望，否則會失去所有信任。

此外，終止開關的整個概念是提供針對任何實際軟體攻擊強化的安全性層級。如果裝置有終止開關，而且系統完全遭到惡意軟體入侵，該軟體就無法覆寫終止開關並危害使用者的隱私權。簡單地說，預期 *終止開關只能由用戶實際與裝置互動來啟用/停用。

相較於隱私權快門設計，終止開關較為複雜，而且會面臨更多挑戰來提供信任。這是因為它們在實體交換器 (預期在) 的所有案例中都能完美運作，但不會保證在鏡頭上提供實體快門。這表示提供終止交換器的裝置必須產生一致、清楚且可靠的體驗。

Kill switch 功能

終止開關的運作方式是告訴 ISP 韌體停止從感測器擷取，並改為合成黑色影像。如此一來，相機仍可從應用程式的觀點取得並運作，但在終止開關作用中時，不會將實際感測器數據傳輸至主機 OS。強固的設計運作方式如下：

交換器中的實體訊號會連線到 ISP 上的 GPIO，以指出交換器是否作用中
當終止開關作用中時，ISP：
1. 以電子方式中斷感測器的連線
2. 開始合成黑色畫面，以取代中斷連線感測器的實際畫面格
3. 透過隱私權快門通知功能關閉快門的報告

實際上，支援此完整體驗的 ISP 晶片，包括終止開關 GPIO 作用中時感測器的電力中斷，尚未在市場中提供。因此，目前的設計需要修改上述步驟 2a，以「停止感測器或在韌體內捨棄感測器數據」。我們計劃與 ISP 廠商合作，以減輕未來晶片中這種適應需求的需求。

注意

請務必在 ISP 韌體中實作終止交換器功能，而不是在主機 OS 上執行的驅動程式內。當終止開關處於「終止」狀態時，感測器的實際影像數據不得傳輸至OS。

如同隱私權快門，OEM 可能會在Kill Switch處於「終止」狀態時，將影像取代為靜態影像。映射更換可能會在 ISP 或驅動程式內發生，但建議在 ISP 內取代，以減少 DMFT 的需求，並將負載新增至主機裝置。如果在驅動程式中執行映射取代，請注意當終止參數處於「終止」狀態仍適用時，實際映像數據不會傳輸至 OS 的需求。

Kill switch 實作

終止切換狀態不得受軟體控制，否則惡意應用程式可以寫入控件來啟用或停用終止開關。它們應該由連線至 ISP 上 GPIO 的交換器控制。

當相機終止開關關閉時，相機仍會出現在系統中，而且應用程式仍然可以從中串流處理，影像只會變成黑色。畫面格會繼續傳遞至OS，而相機會繼續回應控件;除非應用程式使用 CameraOcclusionInfo API，否則應用程式不會察覺參數處於「終止」狀態。這可讓相機透過硬體控件停用，而不會在翻轉交換器時引入令人困惑的「找不到相機」訊息，或有風險導致某些應用程式當機。

如在面板上具有多個相機的快門所述，相同面板上具有個別 IR 和 RGB 相機的裝置，在啟動終止開關時必須同時停用這兩個感測器。

HLK LED 需求

HLK 要求當 ISP 擷取感測器數據時，指標 LED 為 ON。啟用終止開關表示 ISP 必須停止從感測器擷取實際數據，因此 LED 也應該使用終止開關關閉。這可避免任何混淆或信任外洩，如果客戶看到光線指示器或 IR 光源 LED，他們知道軟體目前正在擷取其影像，而且如果他們看不到已亮的 LED，他們就會知道他們未擷取。

終止交換器狀態報告

如果源自 UVC 裝置) ，KSPROPERTY_CAMERACONTROL_PRIVACY (或從 AVStream 或 DMFT 驅動程式) ，則應該透過CT_PRIVACY_CONTROL (来报告终止开关的状态。每當 ISP 不在 D3 時，應該報告相機終止開關的狀態。

如需詳細資訊，請參閱隱私權快門/切換通知。

kill switch state reporting

Kill switch 行為摘要表

下表摘要說明具有相機終止開關的相機預期行為：

ISP 狀態	終止開關狀態	可見指示器LED	串流至計算機的影像	報告CT_PRIVACY_CONTROL狀態
Idle/D3	執行	關閉*	N/A	開放式
Idle/D3	終止	關閉*	N/A	關閉
串流處理 (任何應用程式)	執行	On*	擷取的感測器影像	開放式
串流處理 (任何應用程式)	終止	關閉*	合成的空白畫面	關閉