カメラ プライバシー シャッターとキル スイッチ
この記事では、プライバシー シャッターやキル スイッチのデバイス設計ガイダンス、シャッター状態検出に関する考慮事項、およびシャッターがインジケーター LED について既存の HLK 要件とどのように相互作用することが期待されるのかについて説明します。
一般的な LED 要件
シャッターやキル スイッチに関係なく、HLK では、ISP がセンサー データをキャプチャするときに、可視インジケーター LED がオンになっている必要があります。 RGB カメラの場合、カメラがアクティブであれば、単一の可視波長 LED (白、緑、青など) をオンにする必要があります。
RGB+IR センサーを搭載したカメラの場合は、より複雑になる可能性があります。IR カメラにはイルミネーター LED が必要であり、イルミネーター LED は可視波長 (850 nm) または目に見えない波長 (940 nm) を使用する可能性があるためです。 さらに、アプリは、IR センサー自体、RGB センサー自体、またはその両方から同時にストリームできます。
可視波長 IR イルミネーターを使用した設計では、IR イルミネーター LED を可視インジケーター LED として使用することを選択できます。 これは、IR カメラが単独でオンになっている場合、IR イルミネーター LED が点滅していることで HLK 要件が満たされます。
不可視波長 IR イルミネーターを使用する設計では、HLK 要件を満たすために、可視波長 LED を使用して IR カメラがアクティブであることを示す必要があります。 カメラの使用中のインジケーター LED を共有することをお勧めします。これにより、IR センサーまたは RGB センサーのどちらか、あるいはその両方がオンのときに、同じ可視波長 LED がオンになります。
IR イルミネーター LED が可視波長を使用するかどうかに関わらず、IR または RGB カメラを使用する場合は、すべての設計で通常の使用中インジケーター LED をオンにすることをお勧めします。 コア LED 要件の完全な表を次に示します。
| ストリーム状態 | 可視 IR LED (850 nm) | 不可視 IR LED (940 nm) |
|---|---|---|
| カメラ オフ | LED オフ | LED オフ |
| RGB カメラのみオン | 使用中のインジケーターオンIR イルミネーターオフ | 使用中のインジケーターオンIR イルミネーターオフ |
| IR カメラのみオン | 使用中のインジケーターは必須ではありませんが、オンにすることをお勧めします | 使用中のインジケーターオンIR イルミネーターオン |
| RGB および IR カメラ オン | 使用中のインジケーターオンIR イルミネーターオン | 使用中のインジケーターオンIR イルミネーターオン |
Note
LED の要件は、カメラプ ライバシー シャッターまたはカメラ キル スイッチ搭載設計によって異なる場合があります。 カメラのプライバシー シャッターとカメラ キル スイッチの HLK LED 要件については、カメラ プライバシー シャッター LED の要件に関するページを参照してください。
常時稼働の AI エクスペリエンス (カメラベースの人間のプレゼンスなど)
AI シリコンがメイン カメラ センサーを共有する常時稼働カメラベースの AI 機能に対応したデバイスについては、専用プレゼンス シリコンがカメラに排他的にアクセスする場合において、LED の要件は異なります。 詳細は、Microsoft パートナー センターの プレゼンス センシングに関するホワイトペーパー を参照してください。
ハードウェア プライバシー コントロール
カメラの設計にハードウェア プライバシー コントロールが含まれている場合、設計ガイダンスには次の 2 つの重要な教義があります。
プライバシー コントロールを備えたデバイスは、一貫したユーザー エクスペリエンスとプライバシー状態の信頼性を確立する必要があります。
- 顧客がデバイスのシャッターの外観と動作を理解したら、その知識は、シャッター付きのあらゆるデバイスに対しても適用できる必要があります。
いかなる状況においても、カメラのプライバシー コントロールが、誤解を招くようなプライバシーの印象を与えるべきではありません。
- 顧客に最も重要な場合、デバイスによるプライバシー提供は失敗が許されません。 カメラのプライバシー シャッターが閉じている場合やカメラのキルスイッチがオフになっている場合、顧客は、物理的なコントロールによるプライバシー機能の無効化を行うまで、画像をキャプチャできないことを期待しています。
コントロールの種類
2 つの形式のプライバシー コントロールが定義されています。これらはカメラ プライバシー シャッター (機械式および電気機械式) とカメラ キル スイッチです。 OEM は、デバイスのフォーム ファクター、BOM コスト目標、およびデバイスの価格ポイントに応じて、これらのフォームのいずれかでシャッター実装を選択できます。 3 つすべてに共通する重要な点は、物理レベルまたはハードウェア レベル、つまりソフトウェアが関与しない状態で動作する必要があるということです。これは、ソフトウェアは侵害される可能性があるためです。
機械式カメラ プライバシー シャッター
機械式シャッターは最もシンプルな設計です。ユーザーが手動で操作してカメラを遮断するかどうかを決めることができるシンプルなスライド式レンズ カバーです。 これらは、閉じたときにレンズを完全に遮断する不透明な素材を使用して設計されています。 この設計は、ユーザーがスライドさせる以外の方法では物理的に開けられないため、本質的に絶対安全な設計と言えます。
電気機械式カメラ プライバシー シャッター
電気機械式シャッターは、電気制御の機械式シャッターです。 ユーザーが手動でシャッターを開閉するのではなく、デバイス上の物理的なボタンを押すことで、統合されたシャッターが開閉します。
Note
通常、このソリューションにはファームウェアが必要ですが、他のコンポーネントからは分離する必要があります。 つまり、シャッター コントローラーとボタンには、通信バスやファームウェアが再プログラミング可能な状態といった攻撃経路をつくらないようにする必要があります。 この設計にはハードウェアの相互作用が必要です。また、ソフトウェアから制御できないようにする必要があります。
カメラ キル スイッチ
現在、一部のデバイスにはカメラ キル スイッチ機能が搭載されています。これは、電源を切るとカメラ デバイスがシステムから物理的に切断され、レンズ/センサーをカバーする物理的なシャッターを必要とせずにカメラへのアクセスをブロックするハードウェア制御を利用できます。 これは攻撃に対しては堅牢ですが、ユーザー エクスペリエンスが低下します。 スイッチがオフのときにデバイスを取り外すと、システムはシャーシにカメラが残っていても電源がオフになっていることを認識できません。 これは、カメラが接続されていないことがアプリケーションにより報告されるため、スイッチについて認識していないユーザーがカメラを誤ってオフにした場合に、UX (ユーザー エクスペリエンス) の観点から問題になります。 また、使用中にカメラが取り外されたり、アプリの実行中に再接続されたりすると、特定のアプリケーションがクラッシュしたり、誤動作を起こしたりする可能性があります。
したがって、Microsoft では、システムからカメラ全体を取り外すカメラ キル スイッチの使用を推奨またはサポートしていません。 代わりに、次の 2 つのソリューションのいずれかをお勧めします。
機械式カメラ プライバシー シャッターおよび電気機械式カメラ プライバシー シャッターで説明した物理的なシャッター。
ISP ではなくセンサーを切断して、ISP が黒いフレームを合成するキル スイッチ。
2 つ目のソリューションでは、カメラは引き続きシステムに表示され、アプリで引き続き使用できます。 ISP は通常通り、キル スイッチがアクティブかどうかに関係なく、すべてのコマンド (ストリーミングの開始/停止、明るさやコントラストなどの DDI、メディア タイプの変更など) に応答します。 ただし、キル スイッチがアクティブになると、ISP はセンサーからの実際のデータ キャプチャを停止して、代わりに黒いフレームを合成してストリーミングします。これらはすべてアプリケーションの観点から透過的です。
パネル上に複数のカメラがあるシャッター
顧客がシャッター付きのデバイス (たとえば、パネル上に複数の IR カメラや RGB カメラがあるシャッター) を使用する場合、顧客は、シャッターを閉じると、予期しないカメラ アクセスからプライバシーが保護されることを期待します。 同じパネル上に 2 つのカメラ (WINDOWS Hello に対応した RGB カメラや IR カメラなど) があるシステムの場合、このシャッターがセキュリティ感覚について誤解を招かないようにすることが重要です。 Windows Hello 用の 2 つ目のカメラ センサーが存在する可能性があること、一部のデバイスでは RGB+ IR に 1 つのセンサーが使用されることについて、顧客が認識していることは想定されていません。 このため、シャッターは、パネル上のすべてのカメラをカバーする必要があります。
IR カメラにシャッターとキル スイッチを適用することが最も重要です。これは、以下に示すように、IR カメラはアプリケーションからアクセスし、シーンの忠実度の高い画像を合理的に生成できるためです。 IR センサー遮らなければ、シャッターのプライバシー上のメリットに対するセキュリティ感覚に誤解を生み、ユーザーの信頼が失われます。
Note
Windows Hello Face には、RGB カメラと IR カメラの両方が必要です。 RGB カメラが遮断されていると、Windows Hello は正しく機能しません。 RGB ストリームと IR ストリームの両方を使用して、スプーフィング対策を有効にします。
物理シャッター設計ガイダンス (機械式または電気機械式)
顧客が物理的なシャッターを搭載したデバイスを使用する場合、シャッターがあることで、プライバシー保護レベルが高いことを期待できるという印象を与えます。 簡単に言えば、デバイスにシャッターがあり、シャッターが閉じている場合、ユーザーが期待することは予期しないカメラ アクセスから保護されていることです。 重要なのは、その期待に答えることです。それができなければ、信頼をすべて失います。
さらに、プライバシー シャッターでの全体的な懸念点は、実際のソフトウェア攻撃に対して強化されたセキュリティ レイヤーを提供することです。 つまり、デバイスにシャッターがあり、悪意のあるソフトウェアによってシステムが完全に侵害された場合でも、そのソフトウェアがユーザーのプライバシーを侵害する可能性がないということです。 同じように簡単に言うと、期待されていることは、ユーザーがデバイス上のハードウェア シャッター コントロールと物理的に相互作用する場合にのみ、シャッターが状態を変更できることです。
機械式設計の考慮事項
物理的なシャッターは手動または電気機械式に関係なく、閉じたときにセンサーを完全にブロックし、肉眼で見える不透明な材料で作られていることが期待されています。
パネル上に複数のカメラがあるシャッターで説明されているように、同じパネルに個別の IR カメラと RGB カメラを搭載したデバイスでは、シャッターが閉じたときに両方のセンサーが同時にブロックされている必要があります。 次のようなデュアル センサー設計を想定します。
シャッターを閉じるときは、RGB センサーをカバーする必要があります。IR センサーのカバーは任意です。
Note
現在、IR カメラをカバーとしない機械式シャッター設計のカメラの除外をサポートしています。 物理シャッターが RGB カメラを遮断している場合は、IR カメラから出力された画像を ISP ファームウェアが破棄して、合成された黒い画像に置き換えることができます。 ただし、プレゼンス センシングに IR センサーを使用する場合は、IR センサーをカバーせず、プレゼンス センサーが機能するようにすることをお勧めします。 詳細は、Microsoft パートナー センターの プレゼンス センシングに関するホワイトペーパー を参照してください。 今後の HLK 更新プログラムでは、この例外が採用されます。また、ソリューションの堅牢性と顧客のプライバシー保護を強化するために、RGB を物理的に遮断するために物理的なシャッターのみが必須になります。
カメラ動作に関する考慮事項
カメラに物理的なシャッターが搭載されている場合、カメラはシャッター状態に関係なく正常に動作し続けなければなりません。 アプリがカメラからストリーミングしている場合、シャッターが閉じられていても、実際のセンサー データのキャプチャと送信が続行されます。 閉じたシャッターによるセンサーの完全な閉鎖は、黒またはそれに非常に近い画像を生成することが期待されます。
OEM は、シャッターを閉じるときに画像を静的な画像に置き換えることを選択できます (たとえば、カメラの画像にスラッシュが入っている場合など)。 このイメージは静的である必要があり、悪用から守るためにソフトウェアから変更することはできません。 プライバシー シャッターを搭載したデバイスの場合、イメージの置換は ISP 内またはドライバー内で行われる場合があります。ただし、ISP 内での置換は、DMFT の必要性を削減し、ホスト デバイスに負荷を加えるために推奨されます。
カメラのプライバシー シャッター LED の要件
LED の要件は、指定の 一般的な LED 要件 に従う必要があります。 つまり、パネル上の任意のカメラがオンの場合、シャッターの開閉に関係なく、可視波長カメラ使用中のインジケーター LED がオンになっている必要があります。 ただし、シャッターが閉じたときに、シャッターの物理的な設計で LED を覆うのは許容されます。 次の図は、カメラがアクティブにストリーミングされているシナリオを示しています。
IR カメラと RGB カメラの両方を搭載した設計では、シャッターが閉じている間に IR カメラを使用している場合は、中には IR イルミネーター LEDをオフにしたいと思う製造業者もいます。 これについては、複雑さの割にメリッがすくないため推奨していません。IR カメラは、Windows Hello が実行されている場合にのみアクティブになります。また、Windows Hello では、この間にログインしようとしていてもがシャッターが閉じているというメッセージが表示されます。 詳細は、キル スイッチの実装 を参照してください。
ただし、IR カメラの使用中のインジケーター LED が 840 nm (可視) の IR イルミネーター LED 以外の場合 (たとえば、IR カメラがアクティブなときに通常の可視の白/緑/青の LED が点灯する場合)、シャッターが閉じたときに IR イルミネーター LED がオフになる場合があります。
シャッター状態切り替え機構
プライバシー シャッターを実装しているデバイスは、シャッターのソフトウェア制御を許可しません。また、ユーザーがシャッター制御と明示的にやりとりする場合にのみシャッターの開閉を行う必要があります。 このシャッター制御は、機械式スライダー、または電気機械式シャッターを作動させる物理的なボタンが考えられます。 ハードウェア制御がソフトウェアをオーバーライドしてシャッターを閉じたままにしても、ソフトウェアがシャッターの状態を変更することはできません。これは、シャッターが閉じたからと言って、必ずしもプライバシー制御が有効になっているとは限らないためです。 同様に、同じ理由で、カメラを使用しているアプリでシャッターが開閉しない場合があります。 要約すると、ユーザーがデバイスを一見してし、シャッターが閉じているのを確認した場合は、シャッターを開くために物理的な操作を行うまで、プライバシーが保護されていることを明確に推測できる必要があります。
シャッター状態センシングとレポート
市場に出ているカメラのプライバシー設計に関する問題の多くは、ユーザーが意図せずにシャッターを閉じ、カメラが空の画像を生成している理由や、意図した動作をしていない理由を把握できない状況に起因します。 したがって、Windows プライバシー シャッター機能の重要な部分は、カメラがシャッター状態を確実に報告できることにあります。 この情報では、アプリケーションはシャッターが閉じられていることをユーザーに通知し、ユーザーはそれに応じて対応することができます。 シャッター状態の変更は、イベントが発生した後、可能な限り早く検出して報告する必要があります。
シャッター状態のセンシングには、物理センサーとファームウェアベースの検出の 2 つの方法が提案されています。 どちらの方法でも、UVC デバイスから発信された場合は CT_PRIVACY_CONTROL、AVStream または DMFT ドライバーから発信された場合は KSPROPERTY_CAMERACONTROL_PRIVACYから検出されたシャッター状態が報告されます。
詳細は、シャッター通知 を参照してください。
物理状態検出センサー
シャッターの状態は、シャッターの開閉を検出できる物理センサーで検出できます。 物理センサーはシャッター状態を確定的に報告でき、より信頼性の高いエクスペリエンスを提供できます。 Microsoft には、センサーの設計に関する具体的なガイダンスや、センサー テクノロジーに関する具体的な推奨事項はありません。
ISP ファームウェアベースの状態検出
一部の設計では、物理的なシャッターをスキップし、代わりに ISP 内のファームウェアを使用して画像を処理し、推論されたシャッター状態を報告することを選択できます。 このようなソリューションでは、キャプチャされた画像をファームウェアで分析し、しきい値と比較して、シャッターが閉じているかどうかを判断します。 これは、新しい部品を必要とせず、センサー経由でテープなどを検出することもできるため、低コストのソリューションです。 ただし、このような設計を使用する場合は、次の 2 つの重要な考慮事項があります。
このデザインは、暗い環境で閉じたシャッターを誤って報告する可能性があります。 ただし、このような低光環境ではカメラを使用できないため、これは最小限のリスク/問題になることが予想されます。
ISP が D3 から外れるたびにセンサーから定期的にサンプリングできる場合を除き、この方法では、アプリがカメラからのストリーミングを開始するまで、正確なセンサー状態データのクエリを実行できなくなります。
上記の 2 つ目の考慮事項では、課題が生れます。 カメラがストリーミングされていないときにシャッター状態を報告できないにもかかわらず、ストリーミング前にシャッター状態を確認して対応するようにアプリが作成されている場合は、悪い事態が発生する可能性があります。 パートナーから寄せられたフィードバックに応じて、この要件は緩和されました。 また、ストリーミングしていないときに報告されるシャッターの状態に基づいて決定を下すことに対して、ソフトウェア開発者に助言するためにAPIドキュメントを更新しています。 たとえば、シャッターが閉じていると報告している場合は、カメラの電源が入らないようにアプリ開発者に明示的に勧めします。
このアドバイスに準拠していないアプリとの互換性の問題のリスクを回避するために、ストリーミングしていないときにシャッター状態を感知できないカメラは、ストリーミングしていないときは常にシャッターが開いていると報告することが期待されます。 それ以外の場合、カメラがストリーミングしていないときにシャッター状態を検出できる場合は、D3 でないときはいつでもシャッター状態を検出して報告することが期待されます。
Note
CPU 負荷の増大を回避して、堅牢性を最大限に高めるために、イメージ分析ベースのシャッター検出アルゴリズムは常にドライバーではなくファームウェアに実装する必要があります。
カメラのプライバシー シャッターを搭載したデバイスの期待される動作を示す図を次に示します。
カメラのプライバシー シャッター動作の概要表
次の表は、カメラのプライバシー シャッター (手動または電気機械式)を備えたカメラの期待される動作をまとめたものです。
| ISP の状態 | シャッター状態 | 可視インジケーター LED | PC にストリーミングされたイメージ | 報告された CT_PRIVACY_CONTROL 状態 |
|---|---|---|---|---|
| アイドル/D3 | 開始済み | オフ* | 該当なし | 開始済み |
| アイドル/D3 | クローズ済みです | オフ* | 該当なし | 開始済み** |
| ストリーミング (任意のアプリ) | 開始済み | オン* | キャプチャされたセンサー イメージ | 開始済み |
| ストリーミング (任意のアプリ) | クローズ済みです | オン* | キャプチャされたセンサー イメージ | クローズ済みです |
(*) インジケーター LED の要件カメラ詳細は、カメラ プライバシー シャッター LED の要件 と シャッター状態の切り替えメカニズム に関するページを参照してください。
(**) 詳細には、シャッター状態の検出とレポート を参照してください。一部のシナリオでは、ストリーミングしていない場合でもシャッター状態が更新されます。
キル スイッチの設計ガイダンス
顧客がキル スイッチ搭載デバイスを使用する歳、イメージのキャプチャを試みるアプリケーションから確実に保護するために、顧客はハードウェア スイッチに信頼を寄せています。 簡単に言えば、デバイスにキルスイッチがあり、キルスイッチがアクティブになっている場合、そのユーザーが期待することは、予期しないカメラアクセスから自身のプライバシーが保護されていることです。 重要なのは、その期待に答えることです。それができなければ、信頼をすべて失います。
さらに、キル スイッチでの全体的な懸念点は、実際のソフトウェア攻撃に対して強化されたセキュリティ レイヤーを提供することです。 デバイスにキル スイッチが搭載されていて、悪意のあるソフトウェアによって完全にシステムが侵害された場合でも、そのソフトウェアはキル スイッチをオーバーライドしてユーザーのプライバシーを侵害することはできません。 簡単に言えば、期待されることは、*キルスイッチが、ユーザーがデバイスと物理的にやりとりすることでのみアクティブ化/非アクティブ化できることです。
プライバシー シャッターの設計と比較して、キル スイッチはより複雑であり、信頼を持って提供するためにより多くの課題を抱えています。 これは、堅牢性に対して同じレベルの期待を持っているためです (物理スイッチはすべてのシナリオで完璧に動作することが期待されます)。ただし、レンズ上の物理的なシャッターがもたらす保証は提供されません。 つまり、キル スイッチのあるデバイスでは、一貫した明確で信頼性の高いエクスペリエンスが得られなければなりません。
キル スイッチ機能
キル スイッチは、センサーからのキャプチャを停止し、代わりに黒い画像を合成するように ISP ファームウェアに指示することによって動作します。 この方法では、カメラは依然としてアプリケーションの観点から利用でき、機能します。ただし、キル スイッチがアクティブな場合、ホスト OS に送信されている実際のセンサー データはゼロになります。 堅牢な設計は、次のように動作します。
スイッチからの物理信号は、ISP 上の GPIO に接続して、スイッチがアクティブかどうかを示します
キル スイッチがアクティブな場合、ISP は次のようになります。
センサーを電気的に切断する
切断されたセンサーから実際のフレームを置き換える黒いフレームの合成を開始します
プライバシー シャッター通知機能によってシャッターが閉じられたことを報告します
実際には、キル スイッチ GPIO がアクティブな場合のセンサーの電気式切断など、この完全なエクスペリエンスを実現している ISP シリコンは、市場に出えているモデルではまだ利用できません。 したがって、現在の設計では、上記の手順 2a を「ファームウェア内のセンサー データカードセンサーを停止または削除する」に変更する必要があります。 今後のシリコンでのこ対応の必要性を軽減するために、ISP ベンダーと協力する予定です。
Note
ホスト OS で実行されているドライバー内ではなく、ISP ファームウェアにキル スイッチ機能を実装することが重要です。 キル スイッチが「キル」状態のとき、センサーからの実際の画像データを OS に転送することはできません。
Privacy Shutters と同様、キル スイッチが「キル」状態のとき、OEM はイメージを静的なイメージに置き換えることができます。 このイメージの置換は ISP 内またはドライバー内で行われる場合があります。ただし、ISP 内での置換は、DMFT の必要性を削減し、ホスト デバイスに負荷を加えるために推奨されます。 イメージの置換がドライバーで実行される場合は、キル スイッチが「キル」状態のときに実際のイメージ データが OS に転送されないという要件に注意してください。
キル スイッチの実装
キル スイッチの状態をソフトウェアで制御することはできません。制御できてしまうと、悪意のあるアプリケーションがキル スイッチをアクティブ化または非アクティブ化する制御を書き込む可能性があります。 これらは、ISP の GPIO に接続されているスイッチによって制御する必要があります。
カメラのキル スイッチがオフになっているとき、カメラは依然としてシステムに表示され、アプリはそこからストリーミングすることができ、画像は黒くなるだけです。 フレームは引き続き OS に配信され、カメラは制御に応答し続けます。アプリは、アプリが CameraOcclusionInfo APIs を使用していない限り、スイッチが「キル」状態であることを認識できません。 これにより、「カメラが見つかりません」という混乱を招くメッセージを表示させたり、スイッチを反転するときに特定のアプリケーションがクラッシュしたりするリスクを生じさせることなく、ハードウェア制御を介してカメラを無効にすることができます。
パネル上に複数のカメラがあるシャッターで説明されているように、同じパネルに個別の IR カメラと RGB カメラを搭載したデバイスでは、キル スイッチが有効になったときに両方のセンサーが同時に無効化される必要があります。
HLK LED の要件
HLK では、ISP がセンサー データをキャプチャするときにインジケーター LED がオンになっている必要があります。 キル スイッチを有効にすると、ISP はセンサーからの実際のデータのキャプチャを停止する必要があるため、キル スイッチを使用して LED もオフにすることが期待されます。 これにより、混乱や信頼の侵害を回避できます。顧客が点灯インジケーターまたは IR イルミネーター LED を見た場合、ソフトウェアが現在自分のイメージをキャプチャしていることを認識し、点灯した LED が見えない場合は、キャプチャされていないことを認識できます。
キル スイッチの状態レポート
キル スイッチの状態は、CT_PRIVACY_CONTROL (UVC デバイスから発信される場合) またはKSPROPERTY_CAMERACONTROL_PRIVACY (AVStream または DMFT ドライバーから発信される場合) を介して報告する必要があります。 ISP が D3 から外れるたびに、カメラのキル スイッチの状態を報告する必要があります。
詳細は、プライバシー シャッター/スイッチ通知 を参照してください。
キル スイッチ動作の概要表
次の表は、カメラのキル スイッチを使用したカメラの期待される動作をまとめたものです。
| ISP の状態 | キル スイッチの状態 | 可視インジケーター LED | PC にストリーミングされたイメージ | 報告された CT_PRIVACY_CONTROL 状態 |
|---|---|---|---|---|
| アイドル/D3 | [ファイル名を指定して実行] | オフ* | 該当なし | オープン |
| アイドル/D3 | キル | オフ* | 該当なし | 終 |
| ストリーミング (任意のアプリ) | [ファイル名を指定して実行] | オン* | キャプチャされたセンサー イメージ | 始 |
| ストリーミング (任意のアプリ) | キル | オフ* | 合成された空のフレーム | 終 |
(*) インジケーター LED の要件カメラ詳細は、カメラ プライバシー シャッター LED の要件 と シャッター状態の切り替えメカニズム に関するページを参照してください。
シャッター/スイッチ イベントの ISV ガイダンス
プライバシー シャッターまたはキル スイッチを搭載したカメラがこのドキュメントのガイダンスに従うと、カメラのストリーミング時にシャッター/スイッチの状態が OS に報告されます。 カメラを使用しているアプリケーションは、シャッター状態の変化イベントを監視し、それに応じて応答することができます。たとえば、カメラがシャッターやスイッチによってブロックされていることを示す便利な通知を発信します。
詳細は、次の API を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示