Ten post jest napisany “wokół” mojej publikacji naukowej (w International Workshop on Privacy Engineering, w 2020 - czyli wirtualnie) poświęconego ocenie prywatności w standardach internetowych. To element w serii moich publikacji w tej dziedzinie (poprzednia to np. Nie zawiera baterii. Oceny Prywatności w Organizacjach Standaryzacyjnych (W3C)). Zwracam uwagę na zagrożenia dla bezpieczeństwa i prywatności, nacisk kładę jednak na studium przypadku w projektowaniu standaryzacji sieci. W tym przypadku chodzi o to „jak może działać prywatność na poziomie projektowania (Privacy by Design)”. Ta praca miała pozytywny wpływ na specyfikację i wdrożenia.

Chodzi o Ambient Light Sensor - funkcję (API) przeglądarki udostępniające dane z czujnika światła. W skrócie, jakie były efekty tej pracy?

• Szczęśliwie, standard internetowy W3C został poprawiony, ulepszony.
• Przeglądarka Firefox usunęła przestarzałą implementację i najwyraźniej nie implementuje tej funkcji ze względu na prywatność.
• Apple / WebKit / Safari nie implementuje funkcji czujnika światła ze względu na prywatność (a także umieszcza tę funkcję na oficjalnej liście niedozwolonych - ze względu na prywatność).
• Przeglądarka Chrome kontynuuje  implementację, gdzie stosuje określone strategie: odczyt czujnika jest mniej precyzyjny i z niższą częstotliwością (strategia minimalizacji: na przykład zaokrąglenie dokładności odczytu czujnika do najbliższej wielokrotności 50)
• Komitet Konsultacyjny Konwencji Rady Europy (108) o ochronie osób w związku z automatycznym przetwarzaniem danych osobowych usłyszał ode mnie o niektórych zagrożeniach związanych z nowoczesnymi technologiami
  

Rzeczona publikacja badawcza jest więc studium przypadku w inżynierii prywatności i ocenie wpływu na prywatność, z przełożeniem na realny wpływ.

Czujniki światła otoczenia w Twoich urządzeniach i prywatność

Smartfony i niektóre notebooki są wyposażone w czujniki światła. Mogą one usprawnić niektóre aspekty używania, w tym efektywność energetyczną.  Ambient Light Sensor API (wg standardu W3C) umożliwia przeglądarce internetowej wykorzystanie możliwości takiego urządzenia w celu uzyskania dostępu (z poziomu odwiedzanej przez użytkownika strony internetowej) do warunków oświetlenia w środowisku użytkownika, podobnie jak to jest w aplikacjach na smartfony.

Czujniki światła w smartfonach mogą mieć wpływ na prywatność. Kilka lat temu wskazywałem na takie ryzyka wycieków i profilowania (analiza prywatności czujników światła otoczenia, dodatkowe zagrożenia bezpieczeństwa i prywatności czujników światła).

Wykazano też ryzyko kradzieży danych (tj. lista odwiedzonych stron internetowych, bankowy kod PIN w różnych kontekstach, itp.) z przeglądarek internetowych (jak np. wykradanie wrażliwych danych użytkownika za pomocą W3C Ambient Light Sensor API). Ten konkretny atak był demonstracją raczej nieprzemyślanego, nieprzewidzianego i nieoczekiwanego ryzyka, ostatecznie demonstrując możliwość ominięcia fundamentalnego modelu bezpieczeństwa i prywatności web.

Historia prywatności czujnika światła otoczenia

Ta moja praca jest długoterminowa, zacząłem w 2016 roku. Ta historia to wiele dyskusji, ale także testów i demonstracji. W skrócie tak mogę to podsumować (porządek “chronologiczny” zajścia wydarzenia):

• Wstępne plany implementacji / standaryzacji funkcji.
• Wskazane kwestie bezpieczeństwa / prywatności; idziemy do przodu i dokumentujemy problemy.
• W 2017 roku  deweloperzy (z Chrome) sugerują chęć usunięcia monitu przeglądarki internetowej o zgodę na dostęp do funkcji (proszenie użytkownika o zgodę na użycie czujnika światła było początkowym planem), udostępniając go wszystkim stronom internetowym bez interakcji i wiedzy użytkownika. Czy to jest OK?
• Nie całkiem. Bo pokazujemy demonstrację możliwości wykradania danych za pomocą czujnika światła.
• Sprawa idzie dalej z ciekawymi zwrotami akcji (tu pomijam!).
• Impakt na dzień dzisiejszy: (1) aktualizacja standardu, (2) dwóch dostawców przeglądarek internetowych najwyraźniej nie implementują tej funkcji, (3) jeden dostawca przeglądarki wdrażający zalecenia dotyczące bezpieczeństwa / prywatności zawarte w zaktualizowanym standardzie.
  

Czy to jest koniec? Nie sądzę, ale nadszedł czas, aby podsumować część mojej pracy. Chciałbym również wyciągnąć kilka wniosków, tak jak to robiłem to wcześniej.

Wnioski typu Big Picture

Rozpatrywanie ryzyka w szerokim znaczeniu

Wszyscy wiemy, że zagrożenia często wynikają w związku z typowymi problemami web (tj. cross-site scripting, cross-site request forgery, różne interakcje między kontekstami zawartości przeglądanych stron itd.). Możemy postrzegać zagrożenia poprzez te dobrze znane problemy, tak patrząc na nowe funkcje. Jednak w niektórych przypadkach być może  warto zastosować podejście mniej szablonowe. Tak na marginesie, kto by się w ogóle spodziewał wycieku danych poprzez czujnik światła?

Rola demonstracji w celu pokazania jasnego przypadku i pobudzenia dyskusji

W dziedzinie inżynierii bezpieczeństwa rola demonstracji proof of concept jest dobrze znana. Z pewnością demonstracje ryzyka/ataków kształtują dyskusję, ustawiając je w kategoriach obiektywnych. Czasem narzeka się, że brakuje takiego podejścia podczas omawiania ryzyk i zagrożeń prywatności.

Zarówno w inżynierii bezpieczeństwa, ale dziś także w przypadku technologii prywatności (i inżynierii prywatności) to żądanie „zademonstrowania problemu” może nawet w pewnym stopniu przyczynić się do kwestionowania, czy ryzyko w ogóle istnieje. Do czasu, gdy ktoś faktycznie je zademonstruje (powinniśmy starać się uniknąć tej pułapki; żądanie demonstracji problemu może także nie być dobrze dostosowane do wszystkich aspektów zagrożeń prywatności).

To złożone zagadnienie, ale nie ma wątpliwości, że rzeczywiste wykazanie zagrożeń jest pomocne i że często brakuje nam wiarygodnych i rozsądnych przykładów zagrożeń prywatności. W szczególności w przypadku zagrożeń dla bezpieczeństwa i prywatności czujnika światła, pokaz “demonstracja” (proof of concept) wydatnie pomógł ułożyć dyskusję (czasami można to pokazać na różne sposoby).

Powinniśmy jednak zaakceptować fakt, że nie zawsze będzie możliwe zarysowanie  uniwersalnej, wyraźnej i możliwej do pokazania demonstracji.

Kwestie ryzyka i korzyści związane z nowymi funkcjami

Taka analiza to chociażby postawienie kilku pytań. Czy warto ryzykować rozszerzenie funkcji? Jakie jest ryzyko? Co zyskujemy, a co tracimy? Jeśli funkcja nie przynosi korzyści, dlaczego chcemy ją wdrożyć? Czy przeprowadzono ocenę proporcjonalności (analiza ryzyka / korzyści)? Jeśli tak, w jaki sposób wynik został przeniesiony do fazy projektowania i rozwoju?

Podsumowanie

W rezultacie funkcja poddana została naprawdę solidnej ocenie bezpieczeństwa i prywatności, z pewnym konkretnym wpływem na decyzje podejmowane na poziomie standaryzacji i implementacji (przeglądarki internetowe). To z korzyścią dla wszystkich.

Bo każda wrażliwa lub potencjalnie wrażliwa funkcja powinna zawsze podlegać przeglądowi / ocenie zarówno pod kątem bezpieczeństwa, jak i prywatności, na standardowych zasadach. Chociaż zgadzam się, że projektowanie, tworzenie architektury lub zmiana architektury systemów są czasami trudne (i mogą pochłaniać czas i zasoby), to także miejsce, w którym znajdują się interesujące wyzwania. Bo projektowanie systemów z wykorzystaniem Privacy by Design może stanowić pewne wyzwanie, ale jest także ciekawe.

I to mój mały wkład w budowę wiedzy w dziedzinie Privacy by Design, z praktycznym przełożeniem ;-)


Podobał Ci się ten wpis/analiza? Jakieś pytania, uwagi lub oferty? Zapraszam do kontaktu: me@lukaszolejnik.com