Zasłony prywatności aparatu i wyłączniki bezpieczeństwa

Ten artykuł zawiera wytyczne projektowania urządzeń dla okiennic prywatności lub przełączników awaryjnych, zagadnienia dotyczące wykrywania stanu okiennic oraz jak oczekuje się, że okiennice będą współpracować z istniejącymi wymaganiami HLK dotyczącymi diod LED wskaźnika.

Typowe wymagania dotyczące diody LED

Niezależnie od okiennic lub wyłączników bezpieczeństwa, HLK wymaga, aby widoczny wskaźnik LED był włączony, podczas gdy ISP przechwytuje dane z czujników. W przypadku kamer RGB, jeśli kamera jest aktywna, jedna widoczna długość fali LED (na przykład biała, zielona, niebieska itd.) musi być włączona:

W przypadku kamer z czujnikiem RGB+IR może to być bardziej złożone, ponieważ kamera IR wymaga diody LED oświetlenia, a dioda LED oświetlenia może używać widocznej fali (850 nm) lub niewidzialnej fali (940 nm). Ponadto aplikacje mogą przesyłać strumieniowo wyłącznie z czujnika IR, wyłącznie z czujnika RGB lub z obu tych czujników jednocześnie.

Projekty z podświetleniem podczerwieni o widocznej długości fali mogą zdecydować się na użycie diody LED podświetlenia IR jako widocznego wskaźnika LED. Oznacza to, że jeśli kamera IR jest włączona sama, wymagania HLK są spełnione przez zaświecenie diody LED IR.

Projekty korzystające z niewidzialnej fali światła IR muszą używać widocznej fali LED, aby wskazać, kiedy kamera IR jest aktywna, aby spełnić wymagania HLK. Zalecamy wykorzystanie diody LED wskaźnika użycia kamery, aby ta sama dioda LED o widzialnej długości fali włączała się, gdy czujnik IR i/lub czujnik RGB są włączone.

Zalecamy, aby wszystkie projekty włączały zwykłą diodę LED wskaźnika w użyciu, gdy jest używana kamera IR lub RGB, niezależnie od tego, czy dioda LED IR używa widzialnej długości fali, czy nie. Oto pełna tabela podstawowych wymagań dotyczących diod LED:

Zawsze aktywne doświadczenia SI (na przykład obecność człowieka wykrywana przez kamerę)

W przypadku urządzeń obsługujących cały czas aktywne funkcje sztucznej inteligencji opartej na aparacie, gdzie moduł AI korzysta z głównego czujnika kamery, wymagania dotyczące diody LED różnią się, gdy dedykowany moduł obecności ma wyłączny dostęp do aparatu. Aby uzyskać szczegółowe informacje, zobacz oficjalny dokument dotyczący wykrywania obecności w Centrum partnerskim firmy Microsoft.

Sprzętowe mechanizmy kontroli prywatności

Gdy projekty aparatów obejmują mechanizmy kontroli prywatności sprzętu, istnieją dwa kluczowe zestawy naszych wskazówek projektowych:

1. Urządzenia z mechanizmami kontroli prywatności muszą zapewnić spójne środowisko użytkownika i zaufanie do stanu prywatności:

   • Gdy klient dowie się, jak migawka na urządzeniu wygląda i zachowuje się, ta wiedza powinna być stosowana do dowolnego urządzenia, które używa migawki.

2. W żadnym wypadku kontrola prywatności aparatu nie może sprawiać fałszywego wrażenia z prywatności:

   • Urządzenia muszą zapewniać prywatność, gdy jest to najważniejsze dla klienta. Jeśli migawka prywatności aparatu jest zamknięta lub wyłącznik aparatu jest wyłączony, klienci oczekują, że obraz nie może zostać przechwycony, dopóki nie wejdą w interakcję z fizycznym przełącznikiem, aby wyłączyć funkcję prywatności.

Typy kontrolek

Zdefiniowano dwie formy kontroli prywatności: osłony prywatności kamery (mechaniczne i elektromechaniczne) oraz wyłączniki kamery. W zależności od formatu urządzenia, celów kosztowych BOM i poziomu cenowego urządzenia, OEM może zdecydować się na zaimplementowanie migawki w dowolnej z tych form. Ważną stałą we wszystkich trzech przypadkach jest to, że muszą działać na poziomie fizycznym lub sprzętowym, co oznacza, że nie jest używane żadne oprogramowanie, ponieważ oprogramowanie może zostać zhakowane.

Mechaniczna zasłona prywatności kamerki

Migawki mechaniczne są najprostszym projektem, są to prosta osłona obiektywu przesuwnego, którą użytkownik ręcznie uruchamia, aby zablokować aparat lub nie. Są one zaprojektowane przy użyciu nieprzezroczystego materiału, który w pełni blokuje obiektyw po zamknięciu. Ten projekt jest z natury odporny na błędy w sensie, że fizycznie nie można go złamać, aby otworzyć w żaden sposób, z wyjątkiem użytkownika przesuwającego je.

Elektromechaniczna migawka prywatności kamery

Okiennice elektromechaniczne to mechaniczne okiennice sterowane elektrycznie. Zamiast ręcznie otwierać lub zamykać migawkę, zintegrowana migawka otwiera/zamyka się w odpowiedzi na naciśnięcie przycisku fizycznego na urządzeniu.

Wyłączniki bezpieczeństwa kamery

Niektóre urządzenia są obecnie dostarczane z funkcją wyłącznika kamery, która fizycznie odłącza aparat od systemu, gdy jest wyłączona, zapewniając sprzętową kontrolę umożliwiającą zablokowanie dostępu do aparatu bez konieczności użycia fizycznej przesłony do zakrycia obiektywu lub czujnika. Chociaż jest to niezawodne w stosunku do ataków, tworzy słabe środowisko użytkownika. Usuwając urządzenie po wyłączeniu przełącznika, system nie może stwierdzić, że obudowa nadal ma w nim kamerę, ale że jest wyłączona. Jest to problematyczne z perspektywy UX, jeśli aparat zostaje przypadkowo wyłączony przez użytkownika nieświadomego obecności przełącznika, ponieważ aplikacje zgłaszają, że nie ma podłączonej kamery. Może również spowodować awarię lub niewłaściwe zachowanie niektórych aplikacji, jeśli aparat zostanie usunięty podczas korzystania lub pojawi się podczas działania aplikacji.

W związku z tym firma Microsoft nie zaleca ani nie wspiera stosowania wyłączników kamery, które powodują całkowite wyłączenie kamery z systemu. Zamiast tego zalecamy jedno z dwóch rozwiązań:

1. Fizyczna przesłona, zgodnie z opisem w mechanicznej przesłonie prywatności aparatu i elektromechanicznej przesłonie prywatności kamery.

2. Przełącznik kill, który odłącza czujnik, a nie usługodawcę internetowego i powoduje, że usługodawca internetowy syntetyzuje czarne ramki.

W przypadku drugiego rozwiązania aparat nadal pojawia się w systemie, a aplikacje mogą nadal z niego korzystać. ISP odpowiada na wszystkie polecenia (uruchamianie/zatrzymywanie przesyłania strumieniowego, DDI jak dotyczące jasności lub kontrastu, zmiany typu nośnika itd.) normalnie, niezależnie od tego, czy wyłącznik awaryjny jest aktywny, czy nie. Jednak po aktywowaniu wyłącznika bezpieczeństwa usługodawca zatrzymuje przechwytywanie prawdziwych danych z czujnika, a zamiast tego syntetyzuje i przesyła strumieniowo czarne ramki, co pozostaje niewidoczne dla aplikacji.

Migawki z wieloma kamerami na panelu

Gdy klienci korzystają z urządzeń z migawkami (na przykład okiennice z wieloma kamerami IR i RGB na panelu), spodziewają się, że jeśli migawka jest zamknięta, prywatność jest chroniona przed nieoczekiwanym dostępem do aparatu. Jeśli systemy mają dwie kamery na tym samym panelu, takie jak kamera RGB i IR do obsługi funkcji Windows Hello, ważne jest, aby upewnić się, że migawka nie daje fałszywego poczucia bezpieczeństwa. Klienci nie muszą rozumieć, że może istnieć drugi czujnik aparatu dla Windows Hello, a niektóre urządzenia używają jednego czujnika dla RGB+IR. W związku z tym migawka musi pokrywać wszystkie kamery na panelu.

Zapewnienie, że migawki i wyłączniki bezpieczeństwa mają zastosowanie do kamery IR jest niezwykle ważne, ponieważ kamera IR może być dostępna przez aplikacje i produkować obrazy sceny o stosunkowo wysoką jakość, co przedstawiono poniżej. Brak zasłonięcia czujnika IR stanowi fałszywe poczucie bezpieczeństwa i naruszenie zaufania użytkownika do wartości prywatności migawki.

Wskazówki dotyczące projektowania migawki fizycznej (mechaniczne lub elektromechaniczne)

Gdy klient korzysta z urządzenia z migawką fizyczną, obecność migawki daje silne dorozumiane oczekiwania dotyczące poziomu prywatności, który zapewnia. Mówiąc po prostu, że oczekiwanie użytkownika polega na tym, że jeśli urządzenie ma migawkę, a migawka jest zamknięta, są one chronione przed nieoczekiwanym dostępem do aparatu. Ważne jest, aby implementacja funkcji spełniała niewypowiedziane oczekiwania, w przeciwnym razie traci wszelkie zaufanie.

Ponadto cała koncepcja zasłonki prywatności polega na zapewnieniu warstwy zabezpieczającej, która jest odporna na wszelkie praktyczne ataki oprogramowania. Innymi słowy, jeśli urządzenie ma migawkę, a system jest w pełni naruszony przez złośliwe oprogramowanie, to oprogramowanie nie może naruszyć prywatności użytkownika. Ponownie, mówiąc po prostu, oczekiwanie polega na tym, że migawka może zmienić stan tylko wtedy, gdy użytkownik fizycznie wchodzi w interakcję z kontrolką migawki sprzętowej na urządzeniu.

Zagadnienia dotyczące projektowania mechanicznego

Oczekuje się, że migawki fizyczne, zarówno ręcznie, jak i elektromechanicznie działające, mają być wykonane z nieprzezroczystego materiału, który w pełni blokuje czujnik po zamknięciu i jest widoczny nago oka:

Jak opisano w przesłonach z wieloma kamerami na panelu, urządzenia z oddzielnymi kamerami IR i RGB zlokalizowanymi na tym samym panelu muszą mieć oba czujniki zablokowane jednocześnie po zamknięciu przesłony. Załóżmy, że projekt z dwoma czujnikami wygląda następująco:

Gdy migawka jest zamknięta, musi zasłaniać czujnik RGB, opcjonalne jest zakrycie czujnika IR.

Zagadnienia dotyczące zachowania kamery

Gdy aparat jest wyposażony w migawkę fizyczną, aparat musi działać normalnie niezależnie od stanu migawki. Jeśli aplikacja jest przesyłana strumieniowo z aparatu, kontynuuje przechwytywanie i przesyłanie rzeczywistych danych czujnika, nawet jeśli migawka jest zamknięta. Oczekuje się, że pełna okluzja czujnika przez zamkniętą migawkę będzie produkować obraz, który jest czarny lub bardzo zbliżony do czarnego.

Producenci OEM mogą zastąpić obraz statycznym obrazem, gdy migawka zostanie zamknięta (na przykład obraz aparatu z ukośnikiem). Ten obraz musi być statyczny i nie można go zmienić z oprogramowania w celu ochrony przed programami wykorzystującymi luki w zabezpieczeniach. W przypadku urządzeń z migawkami prywatności wymiana obrazu może nastąpić w ISP (Image Signal Processor) lub w sterowniku, chociaż zalecana jest wymiana w ISP, aby zmniejszyć potrzebę DMFTs i zwiększyć obciążenie dla urządzenia hosta.

Wymagania dotyczące osłony prywatności LED dla aparatu

Wymagania dotyczące diody LED muszą być zgodne z wymaganiami określonymi typowymi wymaganiami dotyczącymi diod LED. Oznacza to, że jeśli jakakolwiek kamera na panelu jest włączona, dioda LED sygnalizująca użycie kamery w widzialnym spektrum fal musi pozostać włączona, niezależnie od tego, czy migawka jest otwarta, czy zamknięta. Jednak jest dopuszczalne, aby fizyczna konstrukcja migawki pokrywała diodę LED, gdy migawka jest zamknięta. Na poniższych diagramach przedstawiono scenariusz, gdy kamera aktywnie przesyła strumieniowo:

W przypadku projektów wyposażonych zarówno w aparat IR, jak i RGB, niektórzy producenci mogą chcieć wyłączyć diodę LED oświetlenia IR, jeśli aparat IR jest używany podczas zamykania migawki. Nie zalecamy tego, ponieważ dodaje to złożoności, która daje niewielką wartość; Aparat IR będzie aktywny tylko wtedy, gdy funkcja Windows Hello jest uruchomiona, a wtedy Windows Hello wyświetla komunikat, że próbuje cię zalogować, ale migawka jest zamknięta. Aby uzyskać szczegółowe informacje, zobacz Implementacja wyłącznika awaryjnego.

Jeśli jednak dioda LED 840 nm (podczerwona) nie jest jedyną diodą LED wskaźnika w użyciu dla kamery IR (na przykład normalna widoczna biała/zielona/niebieska dioda LED świeci się, gdy kamera IR jest aktywna), wówczas projekt może wyłączyć diodę LED podczerwieni po zamknięciu migawki.

Mechanizmy przełączania stanu migawki

Urządzenia, które implementują migawki prywatności, nie mogą zezwalać na żadną formę kontroli oprogramowania migawki i muszą otwierać lub zamykać migawkę tylko w odpowiedzi na jawną interakcję użytkownika z kontrolką migawki. Sterownik migawki może być suwakiem mechanicznym lub fizycznym przyciskiem, który uruchamia migawkę elektromechaniczną. Żadne oprogramowanie nie może zmienić stanu migawki, nawet jeśli kontrola sprzętowa może zastąpić oprogramowanie i zachować zamkniętą migawkę, ponieważ zamknięta migawka nie zawsze oznacza, że kontrola prywatności jest włączona. Podobnie migawka może się nie otwierać ani zamykać, gdy aplikacja korzysta z aparatu, z tego samego powodu. Podsumowując, jeśli użytkownik patrzy na urządzenie i widzi, że migawka jest zamknięta, musi być w stanie jednoznacznie wywnioskować, że ich prywatność jest chroniona, dopóki nie podejmą działań fizycznych, aby otworzyć migawkę.

Wykrywanie stanu migawki i raportowanie

Wiele problemów z projektami prywatności aparatów na rynku wynika z sytuacji, w których użytkownik przypadkowo zamyka migawkę i nie może dowiedzieć się, dlaczego ich aparat produkuje pusty obraz lub nie działa. W związku z tym kluczowy element funkcji przesłony prywatności w systemie Windows polega na tym, że aparat musi być w stanie niezawodnie zgłosić stan tej przesłony. Dzięki tym informacjom aplikacje mogą poinformować użytkownika, że migawka jest zamknięta, aby odpowiednio reagować. Zmiany stanu migawki powinny być wykrywane i zgłaszane tak szybko, jak to możliwe po wystąpieniu zdarzenia.

Dwie metody są proponowane do wykrywania stanu migawki, czujników fizycznych i wykrywania opartego na oprogramowaniu układowym. Obie metody zgłaszają wykryty stan migawki przez CT_PRIVACY_CONTROL, jeśli pochodzi z urządzenia UVC, lub KSPROPERTY_CAMERACONTROL_PRIVACY, jeśli pochodzi ze sterownika AVStream lub DMFT.

Aby uzyskać więcej informacji, zobacz Powiadomienie o osłonie prywatności.

Czujnik wykrywania stanu fizycznego

Stan migawki można wykryć za pomocą czujnika fizycznego, który może wykryć, czy migawka jest otwarta, czy zamknięta. Fizyczne czujniki mogą pewnie raportować stan migawki i mogą zapewnić bardziej niezawodne doświadczenie. Firma Microsoft nie ma żadnych konkretnych wskazówek dotyczących projektów czujników ani konkretnych zaleceń dotyczących technologii czujników.

Wykrywanie stanu opartego na oprogramowaniu układowym ISP

Niektóre projekty mogą zdecydować się pominąć fizyczną migawkę, a zamiast tego wykorzystać oprogramowanie układowe wewnątrz ISP do przetwarzania obrazu i raportowania wnioskowanego stanu migawki. Takie rozwiązanie analizuje przechwycony obraz w oprogramowaniu układowym i porównuje go z progiem, aby ustalić, czy migawka wydaje się być zamknięta. Jest to rozwiązanie o niskich kosztach, ponieważ nie wymaga żadnych nowych części i jest również w stanie wykrywać takie elementy jak taśma przez czujnik. Podczas wybierania takiego projektu należy jednak wziąć pod uwagę dwie ważne kwestie:

1. projekt może błędnie zgłaszać zamkniętą migawkę w ciemnych środowiskach. Oczekuje się jednak, że będzie to minimalne ryzyko/problem, ponieważ aparat i tak nie byłby używalny w tak słabo oświetlonym środowisku.

2. O ile Procesor Sygnałów Obrazowych (ISP) nie jest w stanie okresowo pobierać próbek z czujnika, gdy nie jest on w trybie D3, ta metoda uniemożliwia aplikacjom uzyskanie dokładnych danych o stanie czujnika, aż do momentu rozpoczęcia przesyłania strumieniowego z kamery.

Druga kwestia powyżej stanowi wyzwanie. Jeśli aparat nie zgłosi stanu migawki, gdy nie jest transmitowany strumieniowo, ale aplikacja została napisana, aby sprawdzić i reagować na stan migawki przed przesyłaniem strumieniowym, mogą się zdarzyć niepożądane skutki. W odpowiedzi na opinie, które otrzymaliśmy od partnerów, wymóg ten został złagodzony. Aktualizujemy również dokumentację interfejsu API, aby przestrzegać deweloperów oprogramowania przed podejmowaniem decyzji na podstawie stanu migawki aparatu zgłaszanego, gdy transmisja nie jest aktywna. Na przykład stanowczo odradzimy deweloperom aplikacji uniemożliwianie włączenia aparatu, jeśli migawka zgłasza, że jest zamknięta.

Aby uniknąć ryzyka problemów ze zgodnością z aplikacjami, które nie są zgodne z tą radą, aparaty fotograficzne, które nie mogą wykryć stanu migawki, kiedy nie przesyła się strumieniowo, powinny zgłaszać, że migawka jest OTWARTA, gdy nie przesyła się strumieniowo. Inaczej, jeśli aparat może wykrywać stan migawki, gdy nie jest w streamingu, powinien wykrywać i zgłaszać stan migawki w dowolnym momencie, gdy nie jest w D3.

Oto diagram ilustrujący oczekiwane zachowanie urządzenia z migawką prywatności aparatu:

Tabela podsumowania zachowania przesłony prywatności aparatu

W poniższej tabeli podsumowano oczekiwane zachowanie aparatu z migawką prywatności aparatu (ręczna lub elektromechaniczna):

(*) Aby uzyskać szczegółowe informacje dotyczące wymagań dotyczących diod LED wskaźnika, zobacz Wymagania dotyczące diod LED w zasłonach kamery i Mechanizmy przełączania stanu zasłony.

(**) Zobacz Wykrywanie stanu migawki i raportowanie , aby uzyskać szczegółowe informacje, w niektórych scenariuszach stan migawki będzie nadal aktualizowany, gdy nie jest przesyłany strumieniowo.

Wskazówki dotyczące projektowania przełącznika kill

Gdy klient używa urządzenia z wyłącznikiem awaryjnym, pokłada zaufanie w przełączniku sprzętowym, aby niezawodnie chronić przed wszelkimi aplikacjami próbującymi uchwycić obraz. Mówiąc prosto, oczekiwanie użytkownika polega na tym, że jeśli moje urządzenie ma wyłącznik awaryjny i ten wyłącznik jest aktywowany, moja prywatność jest chroniona przed nieoczekiwanym dostępem do aparatu. Ważne jest, aby implementacja funkcji spełniała niewypowiedziane oczekiwania, w przeciwnym razie traci wszelkie zaufanie.

Ponadto cała koncepcja przełącznika awaryjnego polega na zapewnieniu warstwy zabezpieczeń, która jest wzmocniona przed każdym praktycznym atakiem na poziomie oprogramowania. Jeśli urządzenie ma przełącznik kill i system jest w pełni naruszony przez złośliwe oprogramowanie, to oprogramowanie nie może zastąpić przełącznika kill i naruszyć prywatności użytkownika. Po prostu oczekuje się, że przełącznik awaryjny można aktywować lub dezaktywować tylko gdy użytkownik fizycznie wejdzie w interakcję z urządzeniem.

W porównaniu z zatyczkami prywatności, wyłączniki awaryjne są bardziej złożone i niosą ze sobą większe wyzwania związane ze zdobyciem zaufania. Dzieje się tak dlatego, że mają taki sam poziom oczekiwania na niezawodność (oczekuje się, że przełącznik fizyczny będzie działać bezbłędnie we wszystkich scenariuszach), ale nie zapewniają zapewnienia, że migawka fizyczna na obiektywie zapewnia. Oznacza to, że urządzenia, które oferują przełączniki awaryjne, muszą zapewnić spójne, jasne i niezawodne doświadczenie użytkownika.

Funkcjonalność kill switcha

Przełączniki awaryjne działają, nakazując oprogramowaniu układowemu ISP, aby zatrzymało przechwytywanie z czujnika i zamiast tego syntetyzowało czarny obraz. Dzięki temu kamera pozostaje dostępna i funkcjonalna dla aplikacji, ale nie są przesyłane żadne rzeczywiste dane czujnika do systemu operacyjnego gospodarza, gdy wyłącznik bezpieczeństwa jest aktywny. Niezawodny projekt będzie działać w następujący sposób:

1. Sygnał fizyczny z przełącznika łączy się z GPIO w ISP, aby wskazać, czy przełącznik jest aktywny, czy nie.

2. Gdy przełącznik awaryjny jest aktywny, dostawca usług internetowych (ISP):

   1. Elektrycznie odłącza czujnik

   2. Rozpoczyna syntezowanie czarnych ramek, aby zastąpić rzeczywiste ramki pochodzące z odłączonego czujnika.

   3. Raporty o zamknięciu zasłonki prywatności za pośrednictwem funkcji powiadomienia o zasłonce prywatności

W praktyce, krzem ISP, który obsługuje to pełne doświadczenie, w tym odłączenie elektryczne czujnika, gdy przełącznik bezpieczeństwa jest aktywny, nie jest jeszcze dostępny na rynku. W związku z tym bieżące projekty wymagają modyfikacji kroku 2a powyżej, aby "Zatrzymać czujnik lub odrzucić dane czujnika w oprogramowaniu układowym". Planujemy współpracować z dostawcami ISP, aby ograniczyć konieczność tego rozwiązania w przyszłych układach krzemowych.

Podobnie jak w przypadku zasłon prywatności, OEM-y mogą zastąpić obraz statycznym obrazem, gdy wyłącznik awaryjny jest w stanie "kill". Zamiana obrazu może wystąpić w procesorze obrazu (ISP) lub w sterowniku, chociaż zalecane jest zastąpienie w procesorze obrazu (ISP), aby zmniejszyć potrzebę DMFTs i dodać obciążenie do urządzenia hosta. W przypadku gdy zamiana obrazu jest wykonywana w sterowniku, należy pamiętać, że rzeczywiste dane obrazu nie są przesyłane do systemu operacyjnego, gdy wyłącznik awaryjny znajduje się w stanie „wyłączonym”.

Implementacja przełącznika kill

Stan przełącznika kill nie może być kontrolowany przez oprogramowanie, ponieważ złośliwa aplikacja może zapisać kontrolkę w celu aktywowania lub dezaktywowania przełącznika kill. Powinny być kontrolowane przez przełącznik podłączony do GPIO na ISP.

Ważne jest, aby gdy wyłączniki bezpieczeństwa kamer są wyłączone, kamera nadal pojawia się w systemie i aplikacje mogą nadal przesyłać z niej strumieniowo, przy czym obraz po prostu robi się czarny. Ramki są nadal dostarczane do systemu operacyjnego, a kamera nadal reaguje na sterowanie; aplikacje nie wiedzą, że przełącznik znajduje się w stanie "kill," chyba że aplikacja korzysta z interfejsów API CameraOcclusionInfo. Dzięki temu aparat może być wyłączony za pośrednictwem sterowania sprzętem bez wprowadzania mylących komunikatów "nie znaleziono aparatu" lub ryzyka awarii niektórych aplikacji podczas przerzucania przełącznika.

Jak opisano w przesłonach z wieloma kamerami na panelu, urządzenia z oddzielnymi kamerami IR i RGB na tym samym panelu muszą mieć oba czujniki wyłączone równocześnie po aktywowaniu wyłącznika bezpieczeństwa.

Wymagania dotyczące diody LED HLK

HLK wymaga, aby wskaźnik LED był włączony, gdy ISP zbiera dane czujnikowe. Aktywowanie przełącznika kill oznacza, że dostawca usług internetowych (ISP) musi zatrzymać przechwytywanie rzeczywistych danych z czujnika, więc dioda LED również ma się wyłączyć z przełącznikiem kill. Pozwala to uniknąć nieporozumień lub utraty zaufania. Jeśli klient widzi zapaloną diodę wskaźnika lub diodę LED IR, wie, że oprogramowanie aktualnie rejestruje jego wizerunek, a jeśli nie widać zapalonej diody LED, wie, że nie jest rejestrowany.

Zabij raportowanie stanu przełącznika

Stan wyłącznika bezpieczeństwa należy zgłaszać za pośrednictwem CT_PRIVACY_CONTROL (jeśli pochodzi z urządzenia UVC) lub KSPROPERTY_CAMERACONTROL_PRIVACY (jeśli pochodzi z sterownika AVStream lub DMFT). Stan wyłącznika aparatu powinien być zgłaszany za każdym razem, gdy procesor sygnałów obrazu jest poza trybem D3.

Aby uzyskać więcej informacji, zobacz Powiadomienie o zasłonie/przełączniku prywatności.

Tabela podsumowania zachowania wyłącznika awaryjnego

W poniższej tabeli podsumowano oczekiwane działanie kamery z przełącznikiem wyłączającym kamerę:

(*) Aby uzyskać szczegółowe informacje dotyczące wymagań dotyczących diod LED wskaźnika, zobacz Wymagania dotyczące diod LED w zasłonach kamery i Mechanizmy przełączania stanu zasłony.

Wskazówki niezależnego dostawcy oprogramowania dotyczące zdarzeń migawki/przełącznika

Gdy kamera z zasłoną prywatności lub wyłącznikiem awaryjnym postępuje zgodnie ze wskazówkami w tej dokumentacji, stan zasłony/przełącznika jest zgłaszany do systemu operacyjnego, gdy kamera transmituje strumieniowo. Aplikacje korzystające z aparatu mogą następnie monitorować zdarzenia zmiany stanu migawki i odpowiednio reagować, na przykład poprzez stworzenie przydatnego powiadomienia, że aparat jest zablokowany przez migawkę lub przełącznik.

Aby uzyskać więcej informacji, zobacz następujące interfejsy API:

Klasa CameraOcclusionInfo

Klasa CameraOcclusionState

Właściwość VideoDeviceController.CameraOcclusionInfo