Kameraschutzläden und Kill-Schalter
Dieser Artikel enthält Anleitungen zum Geräteentwurf für Privacy Shutters oder Kill Switches, Überlegungen zur Erkennung des Auslösezustands und darüber, wie die Blenden voraussichtlich mit den vorhandenen HLK-Anforderungen für Indikator-LEDs interagieren.
Allgemeine LED-Anforderungen
Unabhängig von Rollläden oder Kill-Schaltern erfordert HLK, dass eine sichtbare Anzeige-LED EINGESCHALTET ist, wenn der ISP Sensordaten erfasst. Wenn die Kamera für RGB-Kameras aktiv ist, muss eine einzelne sichtbare Wellenlängen-LED (z. B. weiß, grün, blau usw.) EINGESCHALTET sein:
Bei Kameras mit einem RGB+IR-Sensor kann dies komplexer sein, da die IR-Kamera eine Beleuchtungs-LED benötigt, und die Beleuchtungs-LED eine sichtbare Wellenlänge (850 nm) oder unsichtbare Wellenlänge (940 nm) verwenden kann. Darüber hinaus können Apps vom IR-Sensor selbst, dem RGB-Sensor selbst oder beides gleichzeitig streamen.
Designs, die einen IR-Beleuchtungsstrahler für sichtbare Wellenlängen verwenden, können die IR-Beleuchtungs-LED als sichtbare Anzeige-LED verwenden. Dies bedeutet, dass die HLK-Anforderungen erfüllt werden, wenn die IR-Kamera selbst eingeschaltet ist, indem die IR-Beleuchtungs-LED leuchtet:
Designs, die eine unsichtbare Wellenlängen-IR-Beleuchtung verwenden, müssen eine sichtbare Wellenlängen-LED verwenden, um anzugeben, wann die IR-Kamera aktiv ist, um die HLK-Anforderungen zu erfüllen. Es wird empfohlen, die LED der In-Use-Anzeige der Kamera gemeinsam zu verwenden, damit die gleiche sichtbare WELLENLÄNGEn-LED eingeschaltet wird, wenn der IR-Sensor und/oder der RGB-Sensor EINGESCHALTET ist:
Es wird empfohlen, dass alle Designs die reguläre LED für die In-Use-Anzeige einschalten, wenn die IR- oder RGB-Kamera verwendet wird, unabhängig davon, ob die IR-Beleuchtungs-LED eine sichtbare Wellenlänge verwendet oder nicht. Hier finden Sie die vollständige Tabelle der wichtigsten LED-Anforderungen:
| Stream Zustand | Sichtbare IR-LED (850 nm) | Unsichtbare IR-LED (940 nm) |
|---|---|---|
| Kamera aus | LEDs AUS | LEDs AUS |
| Nur RGB-Kamera auf | In-Use-Indikator EIN, IR-Beleuchtung AUS | In-Use-Indikator EIN, IR-Beleuchtung AUS |
| Nur IR-Kamera auf | In-Use-Indikator nicht erforderlich, aber empfohlen EIN | In-Use-Indikator ON, IR Illuminator ON |
| RGB- und IR-Kamera auf | In-Use-Indikator ON, IR Illuminator ON | In-Use-Indikator ON, IR Illuminator ON |
Hinweis
Die LED-Anforderungen können sich bei Designs mit Kamera-Sichtschutzläden oder Kamera-Kill-Schaltern unterscheiden. Informationen zu Kamera-Sichtschutzläden und HLK-LED-Anforderungen für Kameratöten finden Sie unter Anforderungen für Kameraschutzblende-LED-LED-Anforderungen.
Always-On-KI-Erfahrungen (z. B. kamerabasierte Menschliche Präsenz)
Bei Geräten, die always-on kamerabasierte KI-Features unterstützen, bei denen das KI-Silizium den Standard Kamerasensor teilt, unterscheiden sich die LED-Anforderungen, wenn das dedizierte Anwesenheitssilicium ausschließlich auf die Kamera zugreift. Weitere Informationen finden Sie im Whitepaper zur Anwesenheitserkennung im Microsoft Partner Center.
Hardware-Datenschutzsteuerelemente
Wenn Kameradesigns Hardware-Datenschutzsteuerelemente enthalten, gibt es zwei wichtige Grundsätze unserer Entwurfsanleitung:
Geräte mit Datenschutzkontrollen müssen eine konsistente Benutzerfreundlichkeit und Vertrauen in den Datenschutzstatus bieten:
- Sobald ein Kunde gelernt hat, wie der Auslöser auf dem Gerät aussieht und sich verhält, sollte dieses Wissen für jedes Gerät gelten, das er verwendet, das über einen Auslöser verfügt.
Unter keinen Umständen kann eine Kamera-Datenschutzkontrolle einen falschen Eindruck von Privatsphäre vermitteln:
- Geräte dürfen den Datenschutz nicht verfehlen, wenn es für den Kunden am wichtigsten ist. Wenn der Kamera-Privacy-Shutter geschlossen oder der Kamera-Kill-Schalter ausgeschaltet ist, erwarten Kunden, dass kein Bild aufgenommen werden kann, bis sie mit der physischen Steuerung interagieren, um die Datenschutzfunktion zu deaktivieren.
Typen von Steuerelementen
Es werden zwei Arten von Datenschutzkontrollen definiert: Kamera-Sichtschutzläden (mechanisch und elektromechanische) und Kamera-Kill-Schalter. Abhängig vom Geräteformfaktor, den Kostenzielen für die Stückliste und dem Preispunkt des Geräts kann ein OEM den Auslöser in einer dieser Formen implementieren. Eine wichtige Konstante für alle drei ist, dass sie auf physischer oder Hardwareebene handeln müssen, was bedeutet, dass keine Software beteiligt ist, da Software kompromittiert werden kann.
Mechanischer Kameraschutzverschluss
Mechanische Rollläden sind das einfachste Design, dies sind eine einfache gleitende Objektivabdeckung, die der Benutzer manuell betätigt, um entweder die Kamera zu blockieren oder nicht. Sie sind mit einem undurchsichtigen Material konzipiert, das das Objektiv beim Schließen vollständig blockiert. Dieses Design ist inhärent narrensicher in dem Sinne, dass es physisch nicht durch irgendeine Weise kompromittiert werden kann, mit Ausnahme des Gleitens des Benutzers.
Elektromechanischer Kamera-Sichtschutzverschluss
Elektromechanische Rollläden sind elektrisch gesteuerte mechanische Rollläden. Anstatt dass der Benutzer den Auslöser manuell öffnet oder schließt, wird der integrierte Verschluss als Reaktion auf das Drücken einer physischen Taste am Gerät geöffnet/geschlossen.
Hinweis
Diese Lösung erfordert zwar in der Regel Firmware, sollte aber von anderen Komponenten isoliert werden. Mit anderen Worten, der Auslöser und die Taste sollten keine Angriffsvektoren wie Kommunikationsbusse oder die Fähigkeit zur Umprogrammierung der Firmware haben. Der Entwurf muss eine Hardwareinteraktion erfordern und darf nicht über Software gesteuert werden.
Kamera-Kill-Schalter
Einige Geräte werden heute mit einer Kamera-Kill-Schalter-Funktion ausgeliefert, die das Kameragerät physisch vom System trennt, wenn es ausgeschaltet ist, und eine Hardwaresteuerung bereitstellt, um den Kamerazugriff zu blockieren, ohne dass ein physischer Verschluss zum Abdecken des Objektivs/Sensors erforderlich ist. Dies ist zwar robust gegen Angriffe, führt aber zu einer schlechten Benutzererfahrung. Wenn das Gerät entfernt wird, wenn der Schalter ausgeschaltet ist, kann das System nicht erkennen, dass das Gehäuse noch eine Kamera enthält, sondern dass es einfach ausgeschaltet ist. Dies ist aus UX-Perspektive problematisch, wenn die Kamera unbeabsichtigt von einem Benutzer ausgeschaltet wird, der den Schalter nicht kennt, da Anwendungen melden, dass keine Kameras verbunden sind. Es kann auch dazu führen, dass bestimmte Anwendungen abstürzen oder sich falsch verhalten, wenn die Kamera während der Verwendung entfernt wird oder angezeigt wird, während die App ausgeführt wird.
Entsprechend empfiehlt oder unterstützt Microsoft die Verwendung von Kameraabbruchschaltern, die die gesamte Kamera aus dem System entfernen. Stattdessen empfehlen wir eine von zwei Lösungen:
Ein physischer Auslöser, wie unter Mechanischer Kamera-Sichtschutzverschluss und Elektromechanischer Kamera-Sichtschutzverschluss beschrieben.
Ein Kill-Schalter, der den Sensor und nicht den ISP trennt und bewirkt, dass der ISP schwarze Frames synthetisiert.
Bei der zweiten Lösung wird die Kamera weiterhin im System angezeigt, und Apps können sie weiterhin verwenden. Der ISP reagiert auf alle Befehle (Streaming starten/beenden, DDIs wie Helligkeit oder Kontrast, Medientypänderungen usw.) normal, unabhängig davon, ob der Kill-Schalter aktiv ist oder nicht. Wenn der Kill-Schalter jedoch aktiviert ist, beendet der ISP die Erfassung realer Daten vom Sensor und synthetisiert und streamt stattdessen schwarze Frames, die alle aus sicht der Anwendung transparent sind.
Fensterläden mit mehreren Kameras auf einem Panel
Wenn Kunden Geräte mit Rollläden verwenden (z. B. Rollläden mit mehreren IR- und RGB-Kameras auf einem Panel), erwarten sie, dass die Privatsphäre vor unerwartetem Kamerazugriff geschützt ist, wenn der Auslöser geschlossen ist. Wenn Systeme über zwei Kameras auf demselben Panel verfügen, z. B. eine RGB- und IR-Kamera, die Windows Hello unterstützen, ist es wichtig, sicherzustellen, dass der Auslöser kein falsches Sicherheitsgefühl vermittelt. Es wird nicht erwartet, dass Kunden verstehen, dass es einen zweiten Kamerasensor für Windows Hello gibt, und einige Geräte verwenden einen einzelnen Sensor für RGB+IR. Aus diesem Grund muss der Auslöser alle Kameras auf dem Panel abdecken.
Sicherstellen, dass Rollläden und Kill-Schalter auf die IR-Kamera angewendet werden, ist von größter Bedeutung, da die IR-Kamera von Anwendungen zugänglich ist und relativ präzise Bilder der Szene erzeugt, wie unten gezeigt. Wenn der IR-Sensor nicht verschließen würde, wäre dies ein falsches Sicherheitsgefühl und ein Verstoß gegen das Vertrauen des Benutzers in den Datenschutz des Verschlusses.
Hinweis
Windows Hello Face erfordert sowohl eine RGB- als auch eine IR-Kamera. Wenn die RGB-Kamera verworren ist, funktioniert Windows Hello nicht ordnungsgemäß. Sowohl RGB- als auch IR-Streams werden verwendet, um Anti-Spoofing-Zählermaßnahmen zu aktivieren.
Konstruktionsanleitung für physische Verschlusse (mechanisch oder elektromechanische)
Wenn ein Kunde ein Gerät mit einem physischen Auslöser verwendet, gibt die Anwesenheit des Auslösers eine starke implizite Erwartung hinsichtlich des Datenschutzniveaus, das er bietet. Einfach ausgedrückt, die Benutzer erwarten, dass das Gerät vor unerwartetem Kamerazugriff geschützt ist, wenn das Gerät über einen Verschluss verfügt und der Auslöser geschlossen ist. Es ist entscheidend, dass die Implementierung des Features den impliziten Erwartungen entspricht, andernfalls verliert sie jegliches Vertrauen.
Darüber hinaus besteht das gesamte Konzept eines Privacy Shutter darin, eine Sicherheitsschicht zu bieten, die gegen jeden praktischen Softwareangriff gehärtet ist. Mit anderen Worten, wenn das Gerät über einen Auslöser verfügt und das System vollständig durch schadhafte Software kompromittiert wird, kann diese Software die Privatsphäre des Benutzers nicht gefährden. Um es einfach zu sagen: Die Erwartung ist, dass der Verschluss nur dann den Zustand ändern kann, wenn der Benutzer physisch mit der Hardwareauslösesteuerung auf dem Gerät interagiert.
Überlegungen zur mechanischen Konstruktion
Physische Rollläden, ob manuell oder elektromechanisch betätigt, bestehen voraussichtlich aus einem undurchsichtigen Material, das den Sensor im geschlossenen Zustand vollständig blockiert und mit bloßem Auge sichtbar ist:
Wie unter Shutters mit mehreren Kameras auf einem Panel beschrieben, müssen Geräte mit separater IR- und RGB-Kamera auf demselben Panel beide Sensoren gleichzeitig blockiert haben, wenn der Auslöser geschlossen ist. Gehen Sie von einem Dual-Sensor-Design wie folgt aus:
Wenn der Auslöser geschlossen ist, muss er den RGB-Sensor abdecken. Optional kann der IR-Sensor abgedeckt werden:
Hinweis
Wir unterstützen derzeit eine Ausnahme für Kameras, deren mechanische Verschlussdesigns die IR-Kamera nicht abdecken. Wenn ein physischer Verschluss die RGB-Kamera verdeckt, ist es akzeptabel, dass die ISP-Firmware die Bildausgabe von der IR-Kamera verwirft und durch ein synthetisiertes schwarzes Bild ersetzt. Wenn der IR-Sensor jedoch für die Anwesenheitserkennung verwendet wird, wird empfohlen, den IR-Sensor nicht abzudecken und sicherzustellen, dass der Anwesenheitssensor funktionsfähig ist. Weitere Informationen finden Sie im Whitepaper zur Anwesenheitserkennung im Microsoft Partner Center. Ein zukünftiges HLK-Update wird diese Ausnahme übernehmen und erfordert nur physische Verschlusse, um das RGB physisch zu verdecken, um die Stabilität der Lösung und einen besseren Schutz der Privatsphäre der Kunden zu gewährleisten.
Überlegungen zum Kameraverhalten
Wenn eine Kamera mit einem physischen Verschluss ausgestattet ist, muss die Kamera unabhängig vom Verschlusszustand normal weiter betrieben werden. Wenn eine App von der Kamera streamt, erfasst und überträgt sie auch dann weiterhin echte Sensordaten, wenn der Verschluss geschlossen ist. Eine vollständige Okklusion des Sensors durch einen geschlossenen Verschluss wird erwartet, um ein Bild zu erzeugen, das schwarz oder sehr nah dran ist.
OEMs können das Bild durch ein statisches Bild ersetzen, wenn der Verschluss geschlossen ist (z. B. ein Bild einer Kamera mit einem Schrägstrich). Dieses Image muss statisch sein und kann nicht von Software geändert werden, um sich vor Exploits zu schützen. Bei Geräten mit Privacy Shutters kann der Bildaustausch innerhalb des ISP oder innerhalb des Treibers erfolgen, obwohl ein Austausch innerhalb des ISP empfohlen wird, um die Notwendigkeit von DMFTs zu reduzieren und die Last auf das Hostgerät zu erhöhen.
Led-Anforderungen an den Kameraschutzverschluss
Die LED-Anforderungen müssen den anforderungen entsprechen, die für allgemeine LED-Anforderungen angegeben sind. Dies bedeutet, dass, wenn eine Kamera auf dem Panel eingeschaltet ist, eine led der sichtbaren Wellenlängenkamera in Gebrauch eingeschaltet bleiben muss, unabhängig davon, ob der Verschluss geöffnet oder geschlossen ist. Es ist jedoch akzeptabel, dass das physische Design des Verschlusses die LED verdeckt, wenn der Verschluss geschlossen ist. Die folgenden Diagramme veranschaulichen ein Szenario, in dem die Kamera aktiv streamingt:
Bei Designs, die sowohl eine IR- als auch eine RGB-Kamera aufweisen, möchten einige Hersteller möglicherweise die IR-Beleuchtungs-LED ausschalten, wenn die IR-Kamera verwendet wird, während der Verschluss geschlossen ist. Wir empfehlen davon ab, da es zusätzliche Komplexität für wenig Wert hinzufügt. Die IR-Kamera ist nur aktiv, wenn Windows Hello ausgeführt wird, und Windows Hello zeigt während dieser Zeit eine Meldung an, dass sie versucht, Sie anzumelden, aber der Verschluss geschlossen ist. Weitere Informationen finden Sie unter Kill switch-Implementierung .
Wenn jedoch eine 840 nm (sichtbare) IR-Beleuchtungs-LED nicht die einzige In-Use-Anzeige-LED für die IR-Kamera ist (z. B. wird eine normale sichtbare weiß/grün/blaue LED beleuchtet, wenn die IR-Kamera aktiv ist), kann ein Design die IR-Beleuchtungs-LED ausgeschaltet, wenn der Verschluss geschlossen ist.
Umschaltungsmechanismen für den Verschlusszustand
Geräte, die Datenschutzverschlusse implementieren, dürfen keine Softwaresteuerung des Verschlusses zulassen und dürfen den Verschluss nur öffnen oder schließen, wenn der Benutzer explizit mit dem Verschlusssteuerelement interagiert. Diese Verschlusssteuerung kann ein mechanischer Schieberegler oder eine physische Taste sein, die einen elektromechanischen Verschluss betätigt. Keine Software kann den Verschlussstatus ändern, auch wenn ein Hardwaresteuerelement die Software außer Kraft setzen und den Verschluss geschlossen halten kann, da ein geschlossener Verschluss nicht immer bedeutet, dass die Datenschutzsteuerung aktiviert ist. Ebenso darf der Verschluss eine App mit der Kamera aus dem gleichen Grund nicht öffnen oder schließen. Wenn der Benutzer auf das Gerät blickt und sieht, dass der Verschluss geschlossen ist, muss er eindeutig ableiten können, dass seine Privatsphäre geschützt ist, bis er physische Maßnahmen zum Öffnen des Verschlusses ergreift.
Erkennung und Berichterstellung des Verschlusszustands
Viele der Probleme mit In-Market-Kamera-Datenschutzdesigns ergeben sich aus Situationen, in denen ein Benutzer versehentlich den Verschluss schließt und nicht herausfinden kann, warum seine Kamera ein leeres Bild erzeugt oder nicht funktioniert. Dementsprechend basiert ein wichtiger Teil des Windows-Datenschutzverschlussfeatures darauf, dass die Kamera ihren Verschlussstatus zuverlässig melden kann. Mit diesen Informationen können Anwendungen den Benutzer darüber informieren, dass der Verschluss geschlossen ist, damit er entsprechend reagieren kann. Änderungen des Verschlusszustands sollten erkannt und so bald wie möglich nach dem Ereignis gemeldet werden.
Es werden zwei Methoden zum Erfassen des Verschlusszustands vorgeschlagen: Physische Sensoren und firmwarebasierte Erkennung. Beide Methoden melden den erkannten Verschlusszustand über CT_PRIVACY_CONTROL , wenn sie von einem UVC-Gerät stammen, oder KSPROPERTY_CAMERACONTROL_PRIVACY , wenn sie von einem AVStream- oder DMFT-Treiber stammen.
Weitere Informationen finden Sie unter Benachrichtigung zum Datenschutzauslöser .
Physischer Zustandserkennungssensor
Der Verschlusszustand kann mit einem physischen Sensor erkannt werden, der erkennen kann, ob der Verschluss geöffnet oder geschlossen wird. Physische Sensoren können den Verschlusszustand deterministisch melden und können eine zuverlässigere Erfahrung bieten. Microsoft hat keine spezifischen Anleitungen zu Sensordesigns oder spezifischen Empfehlungen für Sensortechnologie zur Verfügung.
ISP Firmware-basierte Zustandserkennung
Einige Designs entscheiden sich möglicherweise dafür, einen physischen Verschluss zu überspringen und stattdessen die Firmware innerhalb des ISP zu verwenden, um das Bild zu verarbeiten und den abgeleiteten Verschlusszustand zu melden. Eine solche Lösung würde das erfasste Bild in der Firmware analysieren und mit einem Schwellenwert vergleichen, um festzustellen, ob der Verschluss geschlossen zu sein scheint. Dies ist eine kostengünstige Lösung, da sie keine neuen Teile erfordert und auch Dinge wie Band über einem Sensor erkennen kann. Bei der Auswahl eines solchen Entwurfs gibt es jedoch zwei wichtige Überlegungen:
Der Entwurf kann fälschlicherweise einen geschlossenen Verschluss in dunklen Umgebungen melden. Es wird jedoch erwartet, dass dies ein minimales Risiko/Problem ist, da die Kamera in einer so schlechten Lichtumgebung sowieso nicht verwendbar wäre.
Diese Methode verhindert, dass Apps genaue Sensorzustandsdaten abfragen können, bis sie von der Kamera gestreamt werden, sofern der ISP nicht in der Lage ist, regelmäßig vom Sensor zu samplingn.
Der zweite Aspekt oben stellt eine Herausforderung dar. Wenn die Kamera den Verschlusszustand nicht meldet, wenn sie nicht gestreamt wird, aber eine App geschrieben wurde, um den Verschlusszustand vor dem Streaming zu überprüfen und darauf zu reagieren, können schlechte Dinge passieren. Als Reaktion auf das Feedback, das wir von Partnern erhalten haben, wurde diese Anforderung gelockert. Wir aktualisieren auch die API-Dokumentation, um Softwareentwicklern davon abzuraten, Entscheidungen basierend auf dem gemeldeten Verschlussstatus zu treffen, wenn kein Streaming erfolgt. Beispielsweise raten wir App-Entwicklern ausdrücklich davon ab, das Einschalten der Kamera zu verbieten, wenn der Verschluss meldet, dass sie geschlossen ist.
Um das Risiko von Kompatibilitätsproblemen mit Apps zu vermeiden, die sich nicht an diese Empfehlung halten, sollten Kameras, die den Verschlusszustand nicht erkennen können, wenn sie nicht streamingn, melden, dass der Verschluss geöffnet ist, wenn kein Streaming erfolgt. Andernfalls, wenn die Kamera den Verschlusszustand erkennen kann, wenn sie nicht gestreamt wird, wird erwartet, dass sie den Verschlusszustand erkennt und meldet, wenn er sich nicht in D3 befindet.
Hinweis
Bildanalysebasierte Verschlusserkennungsalgorithmen sollten immer in der Firmware und nicht in einem Treiber implementiert werden, um die CPU-Auslastung zu vermeiden und maximale Stabilität zu gewährleisten.
Im Folgenden finden Sie ein Diagramm, das das erwartete Verhalten für ein Gerät mit einem Kamera-Datenschutzverschluss veranschaulicht:
Übersichtstabelle des Kamera-Datenschutzverschlussverhaltens
In der folgenden Tabelle wurde das erwartete Verhalten einer Kamera mit einem Kameraschutzverschluss (manuell oder elektromechanisch) zusammengefasst:
| ISP-Status | Verschlusszustand | Led der sichtbaren Anzeige | Bild, das auf den PC gestreamt wird | Gemeldeter CT_PRIVACY_CONTROL Zustand |
|---|---|---|---|---|
| Leerlauf/D3 | Geöffnet | Aus* | – | Geöffnet |
| Leerlauf/D3 | Geschlossen | Aus* | – | Geöffnet** |
| Streaming (beliebige Apps) | Geöffnet | Auf* | Erfasstes Sensorbild | Geöffnet |
| Streaming (beliebige Apps) | Geschlossen | Auf* | Erfasstes Sensorbild | Geschlossen |
(*) Ausführliche Informationen zu den Led-Anforderungen der Anzeige-LED finden Sie unter Anforderungen an den Kameraschutzverschluss undUmschaltermechanismen für den Verschlusszustand .
(**) Ausführliche Informationen finden Sie unter Erkennung und Berichterstellung des Verschlusszustands . In einigen Szenarien wird der Verschlusszustand auch dann aktualisiert, wenn er nicht gestreamt wird.
Entwurfsleitfaden zum Beenden des Schalters
Wenn ein Kunde ein Gerät mit einem Kill-Schalter verwendet, vertraut er einem Hardwareswitch, um sich robust vor anwendungen zu schützen, die versuchen, sein Image zu erfassen. Einfach ausgedrückt, die Benutzer erwarten, dass meine Privatsphäre vor unerwartetem Kamerazugriff geschützt ist, wenn mein Gerät über einen Kill-Schalter verfügt und der Kill-Schalter aktiviert ist. Es ist entscheidend, dass die Implementierung des Features den impliziten Erwartungen gerecht wird, andernfalls verliert sie jegliches Vertrauen.
Darüber hinaus besteht das gesamte Konzept eines Kill-Switches darin, eine Sicherheitsebene bereitzustellen, die gegen jeden praktischen Softwareangriff gehärtet ist. Wenn das Gerät über einen Kill Switch verfügt und das System vollständig durch Schadsoftware kompromittiert wird, kann diese Software den Kill-Schalter nicht außer Kraft setzen und die Privatsphäre des Benutzers gefährden. Einfach ausgedrückt, ist die Erwartung, dass * der Kill-Schalter nur durch den Benutzer, der physisch mit dem Gerät interagiert, aktiviert/deaktiviert werden kann.
Im Vergleich zu Privacy Shutter-Designs sind Kill-Schalter komplexer und mit mehr Herausforderungen verbunden, um vertrauen zu können. Dies liegt daran, dass sie das gleiche Maß an Stabilität haben (ein physischer Schalter wird erwartet, dass er in allen Szenarien einwandfrei funktioniert), aber sie bieten nicht die Gewissheit, dass ein physischer Verschluss über der Linse bietet. Dies bedeutet, dass Geräte, die Kill-Switches anbieten, eine konsistente, klare und zuverlässige Erfahrung erzeugen müssen.
Kill Switch-Funktionalität
Kill Switches funktionieren, indem die ISP-Firmware aufgefordert wird, die Erfassung vom Sensor zu beenden und stattdessen ein schwarzes Bild zu synthetisieren. Auf diese Weise ist die Kamera aus Sicht der Anwendungen weiterhin verfügbar und funktionsfähig, aber es gibt keine echten Sensordaten, die an das Hostbetriebssystem übertragen werden, wenn der Kill-Schalter aktiv ist. Ein robuster Entwurf würde wie folgt funktionieren:
Physisches Signal vom Switch stellt eine Verbindung mit einer GPIO auf dem ISP her, um anzugeben, ob der Switch aktiv ist oder nicht
Wenn der Kill-Schalter aktiv ist, führt der ISP Folgendes aus:
Trennt den Sensor elektrisch
Beginnt mit der Synthetisierung schwarzer Frames, um echte Frames aus dem getrennten Sensor zu ersetzen
Meldet, dass der Auslöser über die Benachrichtigungsfunktion zum Datenschutz geschlossen wird.
In der Praxis ist ISP-Silizium, das diese vollständige Erfahrung unterstützt, einschließlich einer elektrischen Trennung des Sensors, wenn der Kill-Schalter GPIO aktiv ist, noch nicht auf dem Markt verfügbar. Entsprechend erfordern aktuelle Designs eine Änderung von Schritt 2a oben zu "Beenden des Sensors oder Verwerfen der Sensordaten innerhalb der Firmware". Wir planen, mit ISP-Anbietern zusammenzuarbeiten, um den Bedarf an dieser Unterkunft in zukünftigem Silicon zu verringern.
Hinweis
Es ist wichtig, dass die Kill-Switch-Funktionalität in der ISP-Firmware implementiert wird und nicht in einem Treiber, der auf dem Hostbetriebssystem ausgeführt wird. Echte Bilddaten vom Sensor dürfen nicht in das Betriebssystem übertragen werden, wenn sich der Kill-Schalter im "Kill"-Zustand befindet.
Wie bei Privacy Shutters können OEMs das Bild durch ein statisches Bild ersetzen, wenn sich der Kill Switch im Zustand "kill" befindet. Der Imageaustausch kann innerhalb des ISP oder innerhalb des Treibers erfolgen, obwohl ein Austausch innerhalb des ISP empfohlen wird, um die Notwendigkeit von DMFTs zu reduzieren und dem Hostgerät Last hinzuzufügen. Wenn der Imageaustausch im Treiber durchgeführt wird, beachten Sie die Anforderung, dass echte Bilddaten nicht in das Betriebssystem übertragen werden, wenn sich der Kill-Switch im Zustand "kill" befindet.
Switchimplementierung beenden
Der Zustand des Kill-Schalters darf nicht softwaregesteuert sein, andernfalls könnte eine böswillige Anwendung das Steuerelement schreiben, um den Kill Switch zu aktivieren oder zu deaktivieren. Sie sollten durch einen Switch gesteuert werden, der mit einer GPIO auf dem ISP verbunden ist.
Es ist wichtig, dass die Kamera weiterhin im System angezeigt wird und Apps weiterhin von ihr streamen können. Das Bild wird nur schwarz. Frames werden weiterhin an das Betriebssystem übermittelt, und die Kamera reagiert weiterhin auf Steuerelemente. Apps sind sich nicht bewusst, dass sich der Switch im Zustand "kill" befindet, es sei denn, die App verwendet die CameraOcclusionInfo-APIs . Dies ermöglicht es, die Kamera über eine Hardwaresteuerung zu deaktivieren, ohne verwirrende "Kamera nicht gefunden"-Meldungen einzugeben oder zu riskieren, dass bestimmte Anwendungen abstürzen, wenn der Schalter umgedreht wird.
Wie unter Shutters mit mehreren Kameras auf einem Panel beschrieben, müssen Geräte mit separaten IR- und RGB-Kameras auf demselben Panel beide Sensoren gleichzeitig deaktiviert haben, wenn der Kill-Schalter aktiviert wird.
HLK LED-Anforderungen
HLK erfordert, dass die Anzeige-LED eingeschaltet ist, wenn der ISP Sensordaten erfasst. Das Aktivieren des Kill-Schalters bedeutet, dass der ISP die Erfassung realer Daten vom Sensor beenden muss, sodass die LED auch mit dem Kill-Schalter ausgeschaltet wird. Dadurch werden Verwirrungen oder Vertrauensverletzungen vermieden. Wenn der Kunde eine Leuchtanzeige oder IR-Beleuchtungs-LED sieht, weiß er, dass die Software derzeit sein Bild erfasst, und wenn er keine beleuchtete LED sieht, weiß er, dass sie nicht erfasst werden.
Berichterstellung zum Beenden des Schalterzustands
Der Zustand des Kill-Switches sollte über CT_PRIVACY_CONTROL (sofern von einem UVC-Gerät stammend) oder KSPROPERTY_CAMERACONTROL_PRIVACY (wenn von einem AVStream- oder DMFT-Treiber stammen) gemeldet werden. Der Zustand des Kamera-Kill-Schalters sollte immer dann gemeldet werden, wenn der ISP außerhalb von D3 ist.
Weitere Informationen finden Sie unter Benachrichtigung zum Auslösen/Wechseln des Datenschutzes .
Zusammenfassungstabelle für das Verhalten des Kill-Switches
In der folgenden Tabelle wurde das erwartete Verhalten einer Kamera mit einem Kamera-Kill-Schalter zusammengefasst:
| ISP-Status | Zustand des Schalters beenden | Sichtbare Anzeige-LED | Bild, das auf den PC gestreamt wird | Gemeldeter CT_PRIVACY_CONTROL Zustand |
|---|---|---|---|---|
| Leerlauf/D3 | Ausführen | Aus* | – | Öffnen |
| Leerlauf/D3 | Beenden | Aus* | – | Schließen |
| Streaming (beliebige App) | Ausführen | Auf* | Erfasstes Sensorbild | Öffnen |
| Streaming (beliebige App) | Beenden | Aus* | Synthetisierte leere Frames | Schließen |
(*) Weitere Informationen zu den LED-Anforderungen der Anzeige finden Sie unter Anforderungen für den Kamera-Datenschutzverschluss und Verschlusszustands-Umschalter .
ISV-Anleitung für Auslöse-/Umschaltereignisse
Wenn eine Kamera mit einem Aus- oder Kill-Schalter die Anleitung in dieser Dokumentation befolgt, wird der Auslöser-/Schalterzustand beim Streaming der Kamera an das Betriebssystem gemeldet. Anwendungen, die die Kamera verwenden, können dann Ereignisse zur Änderung des Auslösezustands überwachen und entsprechend reagieren, z. B. indem sie einen hilfreichen Hinweis erstellen, dass die Kamera durch einen Auslöser oder Schalter blockiert wird.
Weitere Informationen finden Sie in den folgenden APIs: