Jawność źródeł oprogramowania, od którego zależy sytuacja prawna

Obok dyskusji na temat ewentualnej odpowiedzialności producenta oprogramowania coraz bardziej aktualnym problemem jest możliwość audytowania działania oprogramowania wykorzystywanego przez biegłych lub takiego, z którego mają wynikać potem jakieś prawne konsekwencje. Nie mogę się powołać na konkretne źródło, ponieważ temat ten wciąż nie doczekał się dostatecznej dokumentacji, ale słyszałem o przypadkach, w których efekt działania programu wykorzystywanego przy odtwarzaniu kolizji pojazdów sugerował, że kolizja nastąpiła np. 4 metry pod ziemią (chociaż można było gołym okiem zobaczyć, że kolizja miała miejsce na skrzyżowaniu; o tym problemie pisałem w tekście Problem automatyzacji prawa w przypadku kolizji drogowych w 2007 roku). Teraz zaś temat powraca przy okazji audytu oprogramowania wykorzystywanego w urządzeniach do badania stężenia alkoholu.

Można chyba już pokusić się o wskazanie pewnego "klasycznego modelu podejścia" do problemu: producent oprogramowania wykorzystywanego w tego typu sytuacjach (od których np. zależy jakieś prawo - niezależnie od tego, czy będzie to oprogramowanie "wyborcze" (por. dział wybory), służące do analizy powypadkowej przy kolizjach drogowych, czy innego oprogramowania) powołuje się na tajemnicę przedsiębiorstwa (ew. tajemnicę handlową) i odmawia ujawnienia źródeł oprogramowania, co pozwoliłoby sprawdzić wykorzystywane algorytmy i zweryfikować ich wyniki.

Notatkę tę pragnę poświęcić wpisowi w blogu Bruce-a Schneiera pt. Software Problems with a Breath Alcohol Detector, w której odnosi się on do ustaleń związanych z audytem oprogramowania w sprawie State v. Chun. Dwa lata zajęło obronie uzyskanie dostępu do kodu źródłowego oprogramowania wykorzystywanego w urządzeniu Alcotest 7110 MKIII-C. Udało się to wreszcie, a wyniki audytu stosowanego alkotestu wskazały na szereg, 19,400 "potencjalnych błędów" kodu (potential errors).

Zachęcam do lektury podlinkowanych materiałów.

Opcje przeglądania komentarzy

Wybierz sposób przeglądania komentarzy oraz kliknij "Zachowaj ustawienia", by aktywować zmiany.

Ciekawa laktura

Specjalistą od programowania mikro-kontrolerów nie jestem, ale sądzę iż firma, która pisała ten soft mogła by się wybronić ze sporej ilości rzekomych "błędów".

Nawet oprogramowanie "dobrze" zaprojektowane może zawierć błędy wliczając w to błędy architektoniczne.

Co do konsekwencji działania takiego oprogramowania, to jest to kwestia pewnych standardów. Zamawiający oprogramowanie (wraz z urządzeniem) powonień być świadom jakie normy takie oprogramowanie musi spełniać i jakie certyfikaty/audyty posiadać. Alkomat to jeszcze nie jest tak groźne urządzenie jak urządzenia, które sterują niebezpiecznymi procesami jak:
- elektrownie atomowe
- zakłady chemiczne
- aparaty rentgenowskie oraz tomografy

Czytałem kiedyś o tomografach, które uśmiercały nadmiernie naświetlając "stałych klientów". Z życia natomiast najczęściej miałem do czynienia z maszynami odlewniczymi i słyszałem historie od naocznych świadków, jak maszyna zamknęła w sobie operatora lub wystrzeliła przy otwartej formie. To ostatnie może być bardzo niebezpieczne bo to tak jakby strzelać ciekłym metalem (prędkości wylotowe dochodzą do 50m/s) a jak mamy do czynienia z magnezem wówczas są to bardzo niebezpieczne sytuacje.

Problem można też rozwiązać stosując odpowiednie technologie oprogramowywania, oprogramowanie sterowników PLC jest z natury bardziej bezpieczne bo jest mniej "błędogenne", choć też zawiera błędy. Ciekawą alternatywą dla oprogramowania mission critical jest projekt COSA.

Nie wiem jak wygląda sprawa przy elektrowniach i tego typu instalacjach, w pozostałych przypadkach jest najczęściej tak, iż w przypadku błędu oprogramowania jest ono sprawdzane czy faktycznie "awaria" wynikała z błędu w oprogramowaniu.

Pozdrawiam
Anonimowy tchórz - programista

W tym artykule opisałem

kravietz's picture

W tym artykule opisałem kilka technik, które są w praktyce stosowane do produkcji oprogramowania o wysokiej poprawności działania.

Zdecydowanie przestrzegam natomiast przed typowo inżynierskim podejściem polegającym na odnalezieniu jakiejś specyficznej techniki ("a bo jest przecież Common Criteria") i rzuceniu się do jej wdrażania bez uprzedniej analizy biznesowej.

Każda z wymienionych technik prowadzi do zwiększenia bezpieczeństwa oprogramowania, ale drastycznie podnosi koszty jego wyprodukowania oraz późniejszego wprowadzenia dowolnej zmiany.

Właściwym krokiem, który należy wykonać zanim podejmie się decyzję o wykorzystaniu jednej z tych technik jest analiza ryzyka oraz analiza kosztów i zysków. Obie te techniki powinny doprowadzić do odpowiedzi na pytania:

  • Jaka jest skala problemu? Jaki jest koszt tolerowania problemu?
  • Jaki jest koszt jego naprawienia? Czy nie jest on przypadkiem wyższy od kosztu jego tolerowania?
  • Jaki jest koszt jego obejścia (np. ubezpieczeniem, procedurą odwoławczą)?

W niektórych przypadkach nawet koszt obejścia problemu będzie znacznie wyższy niż koszt jego tolerowania. Racjonalna analiza ryzyka daje w tym przypadku odpowiedź całkowicie niestety niezgodną z intuicją i potocznie rozumianą "sprawiedliwością społeczną".

Dlatego tak często dochodzi do tworzenia "rozwiązań" mających w rzeczywistości charakter nadregulacji i inflacji prawa i to pomimo że znaczna część dowodów na istnienie problemu ma charakter anegdotyczny.

--
Podpis elektroniczny i bezpieczeństwo IT
http://ipsec.pl/

laboratoria akredytwane...

Laboratoria akredytowane zgodnie z norma ISO/IEC 17025 mają obowiązek "certyfikowania" używanego oprogramowania. Sytuacja (w praktyce) jest bardzo trudna, bo z jednej strony w powszechnym użyciu jest niewolne od błędów oprogramowanie biurowe, a z drugiej: praktycznie każde urządzenie pomiarowe dziś to komputer z odpowiednim oprogramowaniem.

Na seminarium poświęconym różnym problemom certyfikacji laboratoriów badawczych przedstawiciel firmy HP (potężnego niegdyś producenta sprzętu pomiarowego) opisywał jak z prośbą o udostępnienie kodu źródłowego (w związku z audytem) zgłosił się przedstawiciel dużej firmy farmaceutycznej, kupujący w HP spore ilości sprzętu pomiarowego.

Na wysokim szczeblu zapadła decyzja pokazania kodu źródłowego. Zawieziono audytora i przedstawiciela laboratorium do ognioodpornego archiwum i pokazano im kupkę papieru -- wydruk oprogramowania inkryminowanego urządzenia.

Na zakończenie przedstawiciel powiedział, że i tak była to akcja wyjątkowa i w praktyce nie można liczyć na dostęp do kodów źródłowych oprogramowania.

Z drugiej strony polityka Microsoftu jest bodaj taka, że po podpisaniu odpowiedniej umowy i uiszczeniu właściwej opłaty (partnerzy?) można mieć dostęp do kodów źródłowych.

Ze strony trzeciej popatrzmy na dwa urządzenia pomiarowe: jedno skomputeryzowane, a drugie klasyczne (wykorzystujące jakieś zjawisko fizyczne do oszacowania wielkości mierzonej). Sytuacja prawna (że tak powiem) obu aparatów musi być identyczna! Jeżeli oba te urządzenia służą do prowadzenia pomiarów od których coś zależy, muszą mieć odpowiedni certyfikat producenta, a użytkownik ma obowiązek kalibrowania go co najmniej trzy razy dziennie (zalecenia dla laboratoriów): na początku pracy, w środku dnia i pod koniec dnia pracy.

Wyobrażam sobie, że kalibrowanie elektronicznego alkomatu jest sprawą skomplikowaną. Stąd orzeczenie alkomatu nie jest werdyktem ostatecznym i można domagać się bardziej obiektywnego badania...

Mówimy o powszechnym użyciu

Wojtku,
tylko że na kazdym wydruku z takiego alkomatu powinno być napisane, ze wynik jest przybliżony, aby "pacjent" o tym wiedział i mógł podjąć odpowiednie czynności prawne. Jestem przekonany, że tylko niewielki odsetek społeczeństwa zdaje sobie sprawę z mechanizmu działania elektronicznego alkomatu, a pokazany sposób pomiaru jest na dodatek w/g mnie mocno kontrowersyjny.

może trochę zbyt ogólnie podejdę do problemu,

3.14159otReG's picture

ale mnie korci.

Skala ludzkiego zaufania do zaawansowanych urządzeń jest tym większa, im większy jest brak elementarnej wiedzy z jednej strony o istnieniu dziedziny zwanej epistemologią, najbardziej życiowej dziedziny filozofii, a z drugiej strony, wręcz "agnostycznemu" rozwinięciu teorii poznania we współczesnych naukach ścisłych, w postaci choćby nieoznaczoności Heisenberga.

To przecież jasne, że zanim podejmiemy czynności poznawcze winniśmy uświadomić sobie, jakie możliwosci poznawcze posiadamy, a wybór postaw wykracza daleko poza powszechne: koń jaki jest, każdy widzi. Wystarczy zapytać, czy aby narzędzie obserwacji nie zmienia obserwowanej rzeczywistości, aby dojść do muru niepewności własnych przeświadczeń o świecie.

Mam ledwie świadmość istnienia tych kwestii, a mimo to jestem w stanie, jak mi sie wydaje, wyprowadzić pewne konsekwencje w odniesieniu do nieomylności protez, jakimi próbujemy naprawić nasze ograniczenia biologiczne.

A jak to się ma do odpowiedzialności tworcy oprogramowania? Ano tak, że wobec jednoznaczej możliwości błędu cena jest wynikiem kalkulacji ryzyk. Im mniejsza świadomość uzytkowników, tym mniejsze ryzyko producenta i wieksza łatwość odnalezienia popytu, również po stronie aparatu poszukującego skutecznych ścieżek wykonywania sprawiedliwości.

Im jednak większa świadomość, tym rozsądniejszy wybór protez i ich racjonalne używanie w zastosowaniach krytycznych, szczególnie tych dla ludzkiego życia.

Jak zwykle jestem nie precyzyjny. Ale prościej nie umiem.
____________
3,14159otR3G

Argument, że w

kravietz's picture

Argument, że w oprogramowaniu do badania stężenia alkoholu we krwi wykryto 20 tys. błędów jest argumentem demagogicznym. Oczywiście, nie dziwię się, że wykorzystano go w sądzie.

Największym problemem podczas analizy kodu źródłowego - czym zajmuję się na codzień - jest właśnie ogromna liczba "błędów" jakimi zasypują badacza narzędzia, do tego celu stworzone. 99% tych "błędów" to błędy, które w piśmiennictwie określilibyśmy błędami indentacji czy stylistycznymi ale nie mającymi wpływu na finalny wynik programu.

Darmowe narzędzia dla średniej wielkości programu potrafią wyrzucić np. 5000 błędów pomimo, że do jego funkcjonowania nikt nie ma zarzutów. Z tego można potem ręcznie wyłuskać 2-3 błędy mające wpływ na funkcjonowanie programu.

To już lepiej dać sobie spokój z audytem i przygotować dobry scenariusz testowy (patrz Test-driven development). W ten sposób zresztą bada się poprawność działania większość urządzeń diagnostycznych - robi się to od wieków i nazywa się to kalibracją. Kalibracja termometru rtęciowego niewiele różni się od kalibracji termometru elektronicznego, tyle że zamiast wysokości słupka rtęci kalibruje się napięcie czy jakiś inny parametr elektryczny.

W pełni natomiast zgadzam się, że kod źródłowy urządzeń, od których zależy ludzki los (systemy eksperckie w sądach, e-voting itd) powinien być poddawany niezależnemu audytowi. Problem z tym postulatem polega z kolei na tym, że nie ma ludzi ani firm, którzy potrafią to zrobić dla administracji publicznej. Rynek ludzi posiadających takie kompetencje i rynek wygrywaczy przetargów to zbiory rozłączne.

Rok temu z kolegami zaśmiewaliśmy się ogłoszeniem rekrutacyjnym jednego z wiodących producentów oprogramowania dla administracji publicznej w Polsce, który w serwisie rekrutacyjnym opublikował taki anons: "firma C. poszukuje studentów ostatnich lat na stanowisko starszego analityka bezpieczeństwa kodu źródłowego". Pewnie potrzebowali do przetargu, ale ten przykład wiele mówi o tym rynku w tym kraju.

Podsumowując, bardzo proszę kolegów prawników o wielką ostrożność w formułowaniu postulatów, które będą później przekuwane na przepisy. W szczególności należy unikać pochopnych wniosków, które doprowadziły na przykład Komisję Europejską do szafowania poronionymi pomysłami na żądanie gwarancji od producentów oprogramowania.

Jeśli ktoś chciałby ten temat zgłębić, to możemy się w jakimś dogodnym terminie spotkać na telekonferencji (mam taką dla stowarzyszenia od koni kabardyńskich), gdzie postaram się opowiedzieć parę słów jak to wygląda od strony tworzenia oprogramowania.

--
Podpis elektroniczny i bezpieczeństwo IT
http://ipsec.pl/

Heh, miałem do czynienia z

Heh, miałem do czynienia z oprogramowaniem poduszek powietrznych.
1) klient żąda źródeł - jest to wpisane do umowy,
2) MISRA-C, OSEK itd. - wszystko to po to, żeby później w kodzie zobaczyć
#define ONE 1
Co prawda w narzędziu sprawdzającym nie generuje to błędu tak, jak
void func(int *c)
{
if(!c) return;
//do something
}

ale co tam... W końcu istotne są procedury, nie zdrowy rozsądek. "Doświadczeni" programiści - nie polscy - nie byli w stanie zrozumieć, dlaczego to pierwsze mi się nie podoba, a do drugiego nie mam zastrzeżeń.
To kod poduszki. Co się dzieje w kodzie alkomatu? Może lepiej nie wiedzieć?
Jaki wniosek z tego wyciągam? Ano taki, że firma może by się i wybroniła, ale istotne jest, kto sprawdzałby kod. Sztuczna inteligencja, czy naturalna (nie mylić z biologiczną).

Piotr VaGla Waglowski

VaGla
Piotr VaGla Waglowski - prawnik, publicysta i webmaster, autor serwisu VaGla.pl Prawo i Internet. Członek Rady ds Cyfryzacji przy Ministrze Cyfryzacji, ekspert w Departamencie Oceny Ryzyka Regulacyjnego Ministerstwa Rozwoju, felietonista miesięcznika "IT w Administracji" (wcześniej również felietonista miesięcznika "Gazeta Bankowa" i tygodnika "Wprost"). Uczestniczył w pracach Obywatelskiego Forum Legislacji, działającego przy Fundacji im. Stefana Batorego w ramach programu Odpowiedzialne Państwo. W 1995 założył pierwszą w internecie listę dyskusyjną na temat prawa w języku polskim, Członek Założyciel Internet Society Poland, pełnił funkcję Członka Zarządu ISOC Polska i Członka Rady Polskiej Izby Informatyki i Telekomunikacji. Był również Członkiem Rady Informatyzacji przy MSWiA, członkiem Zespołu ds. otwartych danych i zasobów przy Komitecie Rady Ministrów do spraw Cyfryzacji oraz Doradcą społecznym Prezesa Urzędu Komunikacji Elektronicznej ds. funkcjonowania rynku mediów w szczególności w zakresie neutralności sieci. W latach 2009-2014 Zastępca Przewodniczącego Rady Fundacji Nowoczesna Polska, w tym czasie był również Członkiem Rady Programowej Fundacji Panoptykon. Więcej >>