O obsłudze sytuacji wyjątkowych słów kilka

Podczas jednej z niedawnych rozmów rekrutacyjnych (w sumie to chyba lubię na nie chodzić – często są dość inspirujące 🙂 ) spotkałem się z ciekawym pytaniem – “Jakie są negatywne konsekwencje stosowania konstrukcji try-catch?” Oczywiście zbyt wiele klawiatur zjadłem, by w ciemno walnąć głupotą, że są wyłącznie same zalety. Pominę co wtedy dokładnie odpowiedziałem, ale moja własna odpowiedź skłoniła mnie by jeszcze trochę pod tym kątem pogrzebać…

Trochę postów, trochę artykułów, sprawdzenie treści kilku książek. Wygląda na to, że ten teren nie jest jeszcze zbyt dokładnie spenetrowany… Mam swoją tezę do udowaodnienia – że jeśli już się decydujemy na przechwytywanie wyjątków to czeka nas ogromna ilość planowania i pracy. Tym artykułem postaram się ją udowodnić oraz podać kilka wskazówek jak można by zabrać się do realizacji tego zadania, o czym może warto pomyśleć z wyprzedzeniem.

Jednak na początek trochę rozważań teoretycznych i to zaczynając od poziomu bardziej abstrakcyjnego. Autor (Patrick Cauldwell) książki „Code Leader” (Amazon.com) dość jasno formułuje zasadę prezentowania sytuacji wyjątkowych użytkownikowi:

Errors should only be handed off to the user if there is something that the user can do to correct the problem, and that needs to be clearly communicated. (…) It is vitally important to make your error messages to the user actionable. If an error message doesn’t tell the user how to correct the problem, then there is no point in showing the user an error message.

Oczywiście po takim oświadczeniu natychmiast powinna nastąpić gorąca debata wśród architektów i programistów:

  • które błędy prezentować?
  • co robić z błędami których nie prezentujemy?
  • co zrobić z samą aplikacją po prezentacji błędu? Zwłaszcza z przetwarzanymi danymi?
  • które sytuacje to faktyczne wyjątki, a które to łatwe do przewidzenia sytuacje nieprawidłowości?
  • które błędy – ostatecznie – należy uznać za krytyczne i zagrażające porządkowi publicznemu?

Continue reading O obsłudze sytuacji wyjątkowych słów kilka

[Od rzeczy] Dziwna reklama

Otóż dotarło do mnie takie coś (jakość oryginalna):

Oryginalna treść reklamy

Reklama jak reklama, tablet jak to tablet ze średniej półki – poznęcam się nad nim dalej – ale mnie w pierwszej kolejności zastanowiła rola modelki na zdjęciu. Przyjrzyjmy się Pani bliżej – strona producenta dostarcza obrazek w dużo lepszej jakości:

Girl_from_advert_original

Nie mam pojęcia kto i dlaczego zatwierdził ten obrazek – dziewczyna jest nawet ładna ale (przynajmniej w wersji z mailingu) strasznie chuda. Chciałoby się powiedzieć – zabiedzona. To jakaś analogia do biedy reklamowanego sprzętu czy co? A do tego wygląda jakby została mocno uderzona w lewy policzek – sina skóra, oko odpadnięte i lekko zezujące w bok, jakby spuchnięta i ściągnięta połówka ust… Hmmm, czyżby reklama możliwych bojowych zastosowań sprzętu?…

Ale do rzeczy – Czy możliwa jest aż taka asymetria twarzy? Niemalże ma się wrażenie, że została sklejona z dwóch rożnych osób… Zobaczmy…

Dziewczyna z reklamy - porównanie asymetrii

Huh! – niemal zupełnie dwie rożne osoby, dwa rożne zdjęcia, inny układ świateł – co najmniej jak dwie siostry.
Mam nadzieje, że to tylko graficy / fotograf spartolili światła i robotę i coś namieszali. Oraz, że ta ładna dziewczyna na co dzień tak nie wygląda… Szkoda by było…


Wracając do samego sprzętu (Sorry, ale oryginalne formatowanie to jakieś masakryczne zabawy DIVami, więc cytuję po mojemu)…

Continue reading [Od rzeczy] Dziwna reklama

Dane wrażliwe

Dane osobowe to szeroki temat, jakkolwiek szeroko lub wąsko rozumiany – dla wielu wrażliwych jest to temat bardzo drażliwy. Jednak niezależnie od tego jak bardzo dana osoba przejmuje się bezpieczeństwem czy poufnością danych powierzonych innym podmiotom (świadomie czy nie) to jednak ustawa na każdego administratora danych osobowych nakłada obowiązek takiego ich przetwarzania, przechowywania i transmitowania by ich spójność i bezpieczeństwo były gwarantowane (i zgodne z ustawą – bla, bla, bla).

Część danych pozwala na jednoznaczną identyfikację osoby (lub podmiotu), której dotyczą. Są to unikalne identyfikatory typu PESEl, NIP, czy REGON. Mniej oczywiste są identyfikatory typu nazwa / imię i nazwisko – które w skali globalnej wcale nie muszą być unikalne. Podobnie poszczególne fragmenty adresu zamieszkania / korespondencyjnego nie muszą precyzyjnie wskazywać konkretnej osoby lub grupy osób (pomijając nawet zmienność i rozbieżność takich danych w czasie – ludzie i firmy często zmieniają miejsce zamieszkania / prowadzenia działalności– także jeden adres może być współdzielony przez wiele podmiotów) ale już w połączeniu z imieniem i nazwiskiem lub datą urodzenia mogą zawęzić zbiór potencjalnych osób do jednego człowieka.

A nawet jeśli nie – to wskazanie konkretnej grupy osób (np. rodziny) może już być odebrane jako pogwałcenie prywatności. Należy bardzo uważać przy łączeniu danych – może się zdarzyć, że połączenie częściowo zamaskowanego adresu (np. do poziomu nazwy ulicy, ale już bez numerów mieszkań) z samym tylko faktem posiadania ubezpieczenia medycznego w konkretnej firmie może precyzyjnie identyfikować konkretną osobę! (A najprawdopodobniej nazwa firmy ubezpieczeniowej nie będzie podlegać anonimizacji, ze względu na wymagania biznesowe systemu testowego…)

Oczywiście, jeżeli wiemy, że dane w całej bazie zostały zanonimizowane wówczas wiemy, że wszelkie próby statystycznego zestawiania poszczególnych elementów nie mają wielkiego sensu. Pod warunkiem wszakże, że poziom anonimizacji jest wystarczający. Wydaje się, że można próbować wskazać właściwe poziomy minimalne dla poszczególnych danych. W wielu przypadkach okaże się, że można zwiększyć te poziomy, gdyż zbyt szeroki zakres realnych danych nie będzie potrzebny podczas korzystania z bazy de-identyfikowanej (np. adresy pozostaną prawdziwe do poziomu miast, związanego z testowanymi zapytaniami raportowymi). Losowa de-identyfikacja ma jedną zasadniczą wadę – może tworzyć osobowości, które fragmentarycznie odpowiadają prawdziwym podmiotom – imiona, nazwiska czy numery PESEL nie mają jakiejś gigantycznej zmienności. Jednym z wymogów może być, by wylosowane wartości anonimizacyjne były różne od oryginalnych. Ale już sprawienie by nie były identyczne z innymi w systemie – niekoniecznie. Pewnym problemem mogą okazać się indeksy unikalne (np. na PESEL, czy niepoprawny na kombinacji imienia i nazwiska), które uniemożliwią takie duplikaty – aplikacja powinna być przygotowana na taką ewentualność i albo sprawdzać to z góry (konfiguracja) albo przechwytywać stosowny wyjątek i losować nową wartość.

Wróćmy zatem do listy proponowanej przez HIPPA:

Continue reading Dane wrażliwe

Anonimizacja vs de-identyfikacja

W pierwszej kolejności należałoby się zapoznać z różnicami między anonimizacją i de-identyfikacją.
Wg definicji (De-identification):

Anonymization
refers to irreversibly severing a data set from the identity of the data contributor in a study to prevent any future re-identification, even by the study organizers under any condition.
De-identification
is the process used to prevent a person’s identity from being connected with information. Common uses of de-identification include human subject research for the sake of privacy for research participants. Common strategies for de-identifying datasets are deleting or masking personal identifiers, such as name and social security number, and suppressing or generalizing quasi-identifiers, such as date of birth and zip code. The reverse process of defeating de-identification to identify individuals is known as re-identification.

Jak należy to rozumieć?

Anonimizacja
odnosi się do NIEODWRACALNEGO pozbawienia zbioru danych wszelkich wskazówek pozwalających na re-identyfikację osoby, której dotyczą.
De-identyfikacja

to usunięcie z danych wszelkich informacji OSOBISTYCH bezpośrednio lub pośrednio wskazujących na konkretną osobę, ale pozostawienie identyfikatora umożliwiającego ewentualne połączenie z oryginalnym zbiorem i osobą.

Generalnie, najlepiej by przedmiotowe dane pozbawić wszelkich możliwych powiązań z oryginalnymi danymi (pełna anonimizacja). Pytanie – czy jest to wykonalne?
Na pierwszy rzut oka – nie wydaje się to możliwe. Pracując na kopii danych, którą będziemy poddawali procesowi de-identyfikacji raczej pozostawimy w stanie niezmienionym wszelkie systemowe identyfikatory – klucze oraz klucze obce – odbudowanie wszelkich relacji o nie opartych wydaje się zadaniem zarówno skomplikowanym jak i wyjątkowo zasobożernym (bazy produkcyjne mają to do siebie, że zazwyczaj są duże). Może nie być to wskazane również ze względów operacyjnych – jeżeli anonimowa baza była używana do naprawy błędów – może zajść konieczność re-identyfikacji oryginalnych rekordów i ich naprawa.
Wniosek 1. W celu realizacji niektórych wymagań organizacji, aplikacja musi umożliwiać pozyskanie kopii danych poddanych jedynie procesowi de-identyfikacji. Musi być możliwość powiązania (przez osoby uprawnione, mające dostęp do oryginalnej bazy) wierszy oryginalnych i anonimowych.
Wniosek 2. Jednakże, na podstawie dowolnej analizy danych zawartych w przetworzonej kopii, bez posiadania dostępu do bazy oryginalnej, re-identyfikacja nie powinna być w żaden sposób możliwa.
Reasumując – jedynymi danymi umożliwiającymi re-identyfikację powinny zostać wewnętrzne identyfikatory z oryginalnego systemu, tj. identyfikatory nadane unikalnie przez ten system a nie pochodzące z innych systemów takie jak np. PESEL.

Continue reading Anonimizacja vs de-identyfikacja

Anonimizator – Nowy Projekt!

Cel projektu

Sytuacja wygląda tak – potrzebuję dostarczyć do zespołu deweloperskiego bazę produkcyjną aby dokonali na niej pewnych testów i optymalizacji. Występują też jeden czy dwa błędy, których nie daje się zreprodukować w środowisku testowym.

Oczywiście baza zawiera masę danych wrażliwych, które absolutnie nie powinny opuścić serwerów produkcyjnych. Zamazanie danych przypadkowymi śmieciami nie wchodzi w rachubę – rozkład statystyczny indeksów ulegnie zmianie i spora część pracy optymalizacyjnej deweloperów będzie bez sensu. Oczywistym jest, że w takim razie należy dane wrażliwe zastąpić danymi “niewrażliwymi” ale sensownymi, o w miarę naturalnym rozkładzie.

Dodatkowe wymagania

  • Dane w bazie są międzynarodowe – mają różną postać i niektóre także formaty
  • Warto zachować statystyczny rozkład danych
  • Powinna być otwarta na przyszłe formaty bazy – nowe bazy jak i rozbudowę / zmiany w istniejącej. Oraz nowe formaty danych.

Zarys rozwiązania

Swego czasu, podczas jednego z projektów, przygotowałem trochę klas generatorów danych testowych, takich jak dane osobowe, adresy, adresy e-mail. Dane bazowe dla generatorów były wyłącznie polskie a ponadto moduł adresów był potraktowany bardzo po macoszemu. Niewątpliwie jest to jakiś punkt wyjścia, ale zdecydowanie zbyt prymitywny na potrzeby funkcjonalnej anonimizacji. Głównie dlatego, że generatory generowały dane zupełnie przypadkowe (Do pewnego stopnia – np. nr PESEL i imię czy nazwisko były dostosowane do płci osoby, podobnie jak PESEL uwzględniał datę urodzenia osoby – o ile została dostarczona w przeciążonej metodzie.) a w obecnym przypadku musimy mieć możliwość kontroli nad zakresem zmian – np. rok i miesiąc urodzenia pozostają oryginalne a randomizujemy wyłącznie dzień albo losujemy imię o identycznej długości (chociaż to, może już nie spełniać wszystkich wymagań…).
Warto też by aplikacja dostarczała na tyle wygodny interfejs, by mogła z niego korzystać uprawniona osoba (Administrator Danych Osobowych), która prawie na pewno nie będzie programistą… Już na wstępie wydaje się zasadnym taki sposób przygotowania konfiguracji procesu, by rozdzielić opracowanie reguł od ich wykonania, oraz w pełni zabezpieczyć dane w bazie produkcyjnej przed niepowołanym dostępem ale także uchronić je przed celowymi lub przypadkowymi zmianami.

Literatura przedmiotu

  1. Niewątpliwie w pierwszej kolejności warto sięgnąć Ustawa o Ochronie Danych Osobowych.
  2. Ciekawym źródłem przydatnych wskazówek i wytycznych jest stosowna ustawa amerykańska dotycząca między innymi anonimizacji i deidentyfikacji pacjentów (HIPAA) wskazana na stronie Wikipedii – De-identification, i w interesującym zakresie dokładniej omówiona tutaj: Protected health information. Zamierzam dokładniej omówić ten ostatni artykuł w kolejnym poście, gdyż te wytyczne są bardzo istotne dla projektowania architektury systemu.

Hello world!

To jest prawdziwy Hello World, godny strony o C# 🙂

// Hello1.cs
public class Hello1
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}

Do diaska – tak na prawdę, to próbuję wyłącznie zmusić Syntax Highlighter do działania 🙁