Ochrona danych osobowych w procesie tworzenia aplikacji mobilnych

Zapewne każdy użytkownik smartfona spotkał się z sytuacją, kiedy niepozorna aplikacja, np. kalkulator, prosi o dostęp do kontaktów zapisanych w telefonie, lokalizacji lub kamery. Jest to przykład błędów – choć czasem też celowych zabiegów – popełnianych przez deweloperów wynikających z nieuwzględniania prywatności w fazie projektowania. W poniższym artykule wskażę, jakie kroki powinny podjąć podmioty odpowiedzialne za stworzenie i eksploatację aplikacji mobilnej, tak aby skutecznie realizować zasady przetwarzania danych osobowych.

Telefon, który trzymam właśnie w ręku, posiada niezliczoną ilość danych. To niewielkie urządzenie już na poziomie hardware’u ma wbudowane sensory ruchu (np. akcelerometr, żyroskop), otoczenia (barometr, magnetometr), pozycji (czujnik bliskości, magnetometr, GPS), które generują szeroki zakres danych osobowych i metadanych (np. dokładne położenie). Możesz sprawdzić, jakie sensory posiada Twój smartfon przy pomocy zaufanych aplikacji do diagnostyki, które można znaleźć w sklepie z aplikacjami (Google Play, App Store).

Ponadto, wiele modeli smartfonów posiada czytniki linii papilarnych, kamery oraz oprogramowanie do rozpoznawania twarzy (biometria), karty sieciowe, bluetooth, NFC. Telefony mogą być sparowane z urządzeniami takimi jak smartwatch, smartband, fitness tracker, które dodatkowo rozszerzają możliwości zbierania danych o np. dane o zdrowiu, a także z innymi urządzeniami internetu rzeczy, które dodatkowo mogą zbierać dane wysoce osobiste, związane z życiem prywatnym danej osoby (np. urządzenie typu smart home może zbierać informacje o naszych nawykach, diecie, a nawet nagrywać nasze rozmowy). Smartfony mogą samodzielnie ułatwiać życie osobom niepełnosprawnym albo przy pomocy urządzeń peryferyjnych. Mogą być także używane przez dzieci, które potrafią korzystać ze swoich telefonów, wykorzystując ich wszystkie funkcje.

W zależności od systemu operacyjnego, konfiguracji prywatności i posiadanych aplikacji smartfon będzie bardzo często zawierał takie dane jak: podstawowe dane identyfikujące, w tym PESEL, dane urządzenia (IMEI, nr seryjny etc.), położenie, dane biometryczne, dane finansowe (stan konta, numer rachunku, zadłużenie u operatora telekomunikacyjnego), historię przeglądarki, dane dotyczące orientacji seksualnej i tożsamości płciowej (np. poprzez aplikacje randkowe), dane dotyczące zdrowia (np. aplikacja mojeIKP), informacje o karalności (punkty karne w mObywatel), e-mail, historię połączeń i książkę kontaktową, zdjęcia (zawierające także metadane), preferencje żywieniowe, informacje wysoce osobiste, jak np. pamiętniki, plany dnia, kalendarze, a także wszelkie dane gromadzone w mediach społecznościowych.

A zatem smartfon jest czymś więcej niż przenośnym komputerem podłączonym do sieci. Jest to także przenośne źródło wszelkich danych o osobie. Dlatego też na producentach telefonów i systemów operacyjnych ciąży wielka odpowiedzialność za bezpieczeństwo danych osobowych. Trzeba jednak wskazać, że odpowiedzialność ta ciąży również na producentach oprogramowania na urządzenia mobilne, czyli aplikacji mobilnych, które po zainstalowaniu i nadaniu uprawnień przez użytkownika mogą mieć dostęp do wielu zasobów danego urządzenia.

Zagrożenia dla ochrony danych osobowych

Szeroki dostęp do danych i możliwość ich ciągłego przetwarzania (w zależności od ustawień, aplikacja może stale monitorować pewne dane), a także liczba interesantów w toku produkcji (inwestorzy, software house’y, freelancerzy, oprogramowanie firm trzecich, producenci urządzeń i ich systemów operacyjnych, sklepy z aplikacjami, reklamodawcy) powoduje, że za używaniem aplikacji mobilnych może iść szereg ryzyk dla praw i wolności osób, których dane dotyczą.

Wśród zagrożeń dla ochrony danych osobowych można wskazać:

  1. brak przejrzystości – wiele podmiotów odpowiedzialnych za aplikację nie zamieszcza stosownych informacji o przetwarzaniu danych osobowych lub umieszcza je w sposób nieprzejrzysty;
  2. brak dobrowolnej, konkretnej, świadomej i jednoznacznej zgody użytkownika – w przypadkach, w których wymagana będzie zgoda użytkownika, zdarza się, że treść checkboksa jest zbyt ogólna lub zgoda jest wymuszana;
  3. brak zabezpieczeń – sama aplikacja, jak i serwery ją wspierające mogą być niedostatecznie zabezpieczone, powodując wysokie ryzyko naruszenia ochrony danych osobowych;
  4. brak realizacji zasady ograniczenia celu i minimalizacji danych – twórcy aplikacji (świadomie bądź nie) mogą zbierać dane zbędne dla celu przetwarzania oraz dane nadmiarowe;
  5. brak realizacji zasady ograniczenia przechowywania – niektóre aplikacje przechowują na serwerach informacje dłużej, niż jest to niezbędne dla celu, w którym są przetwarzane;
  6. dostęp różnych podmiotów do zasobów aplikacji i transfery danych – wytwórca aplikacji może, świadomie bądź nie, udostępniać dane aplikacji swoim podwykonawcom, dostawcom reklam (w tym plików cookie i podobnych rozwiązań), usługodawcom (biblioteki, serwery, rozwiązania chmurowe), organom nadzoru. W wielu przypadkach może dochodzić do transferów danych osobowych do państw, w których system ochrony danych jest nieadekwatny, a środki zabezpieczające, jak np. standardowe klauzule umowne, mogą nie gwarantować stosownej ochrony.

W związku z tym deweloperzy lub właściciele aplikacji powinni mieć na uwadze powyższe zagrożenia i dążyć do ich minimalizacji. Powstaje jednak pytanie: na jakim etapie tworzenia aplikacji twórcy aplikacji powinni brać pod uwagę ochronę danych osobowych?

Funkcja IOD - to się dobrze przekazuje

Privacy by design i privacy by default

Zgodnie z art. 25 ust. 1 RODO, podmiot odpowiedzialny za stworzenie aplikacji mobilnej w celu realizacji wymogów RODO oraz ochrony praw osób, których dane dotyczą, powinien wdrażać już na etapie określania sposobów przetwarzania, jak i w czasie samego przetwarzania (aspekt czasowy ochrony w fazie projektowania) odpowiednie środki techniczne i organizacyjne, zaprojektowane w celu skutecznej realizacji zasad ochrony danych, takie jakie jak pseudonimizacja danych i minimalizacja (aspekt domyślnej ochrony danych). Ochrona danych w fazie projektowania powinna być wdrażana uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie wystąpienia i wadze zagrożenia, wynikające z przetwarzania.

Powyższe określa się jako zasadę uwzględniania ochrony danych w fazie projektowania, czyli privacy by design.

Zasada ta zawiera w sobie aspekty domyślnej ochrony danych (privacy by default); obie te zasady się przenikają, wzajemnie uzupełniają i wzmacniają.

GRATIS

Mechanizmy domyślnej ochrony i w fazie projektowania

Obejrzyj webinar

Zasada domyślnej ochrony danych wskazana jest w art. 25 ust. 2 RODO, który stanowi, iż administrator wdraża odpowiednie środki techniczne i organizacyjne, aby domyślnie przetwarzane były wyłącznie te dane osobowe, które są niezbędne dla osiągnięcia każdego konkretnego celu przetwarzania. Obowiązek ten odnosi się do ilości zbieranych danych osobowych, zakresu ich przetwarzania, okresu ich przechowywania oraz ich dostępności. W szczególności środki te zapewniają, by domyślnie dane osobowe nie były udostępniane bez interwencji danej osoby nieokreślonej liczbie osób fizycznych.

Domyślna ochrona danych oznacza, iż gotowy produkt już domyślnie, a zatem już w ustawieniach fabrycznych, powinien uwzględniać przetwarzanie jedynie danych niezbędnych dla celu przetwarzania i nie dłużej, niż jest to konieczne.

Zasady te mają istotne znaczenie dla aplikacji mobilnych. Jak wskazuje motyw 78 RODO: „jeżeli opracowywane, projektowane, wybierane i użytkowane są aplikacje, usługi i produkty, które opierają się na przetwarzaniu danych osobowych albo przetwarzają dane osobowe w celu realizacji swojego zadania, należy zachęcać wytwórców tych produktów, usług i aplikacji, aby podczas opracowywania i projektowania takich produktów, usług i aplikacji wzięli pod uwagę prawo do ochrony danych osobowych i z należytym uwzględnieniem stanu wiedzy technicznej zapewnili administratorom i podmiotom przetwarzającym możliwość wywiązania się ze spoczywających na nich obowiązków ochrony danych”.

Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA) w swym raporcie pt. „Privacy and data protection in mobile applications („Prywatność i dane osobowe w aplikacjach mobilnych”) zwraca uwagę na strategie projektowania prywatności, tj. wyraźne cele architektoniczne realizowane w fazie projektowania w ramach prywatności, aby osiągnąć określony stopień prywatności – opracowane na podstawie RODO przez holenderskich badaczy. Są to:

  1. Minimalizuj – strategia realizująca zasadę minimalizacji. Jako jej przykład ENISA podaje ograniczenie dostępu aplikacji do sensorów urządzenia;
  2. Ukrywaj – ochrona danych przed upublicznieniem lub nieuprawnionym dostępem, np. poprzez domyślne szyfrowanie danych;
  3. Separuj – zapobieganie korelacji danych poprzez ich separację fizyczną lub logiczną;
  4. Abstrahuj – minimalizacja szczegółów na temat przetwarzanych danych poprzez ich grupowanie lub podsumowanie. ENISA jako przykład podaje ograniczenie geolokalizacji stosowanej przez aplikację w celu bardziej ogólnego określenia położenia niż do szczegółowej lokalizacji urządzenia;
  5. Informuj – realizacja zasady przejrzystości; należy adekwatnie i przejrzyście informować użytkowników o przetwarzaniu danych, w tym o wszelkich zmianach i naruszeniach;
  6. Kontrola – użytkownik powinien mieć kontrolę nad tym, jak przetwarzane są dane – wytwórca aplikacji powinien zagwarantować użytkownikom możliwość wyrażenia i wycofania zgody, wyboru, jakie dane mają być przetwarzane, aktualizacji danych oraz ich usunięcia. ENISA jako przykład podaje sytuację, w której użytkownik może zablokować dostęp aplikacji do sensorów i do zdjęć znajdujących się w pamięci telefonu. W takiej sytuacji wytwórca aplikacji powinien umożliwić dalsze korzystanie z aplikacji, nawet jeśli jej funkcjonalność zostanie ograniczona;
  7. Egzekwuj – należy zapewnić jak największe zaangażowanie w tworzenie, utrzymywanie i przestrzeganie polityk dotyczących przetwarzania danych. Jak zwraca uwagę ENISA, strategia ta wymaga od podmiotów odpowiedzialnych za aplikację, aby przede wszystkim stworzyły, utrzymywały i egzekwowały politykę prywatności dla aplikacji;
  8. Demonstruj – realizacja zasady rozliczalności; administrator powinien móc wykazać, że posiada adekwatne środki techniczne i organizacyjne. Należy rejestrować czynność przetwarzania, dokonywać audytów i sporządzać stosowne raporty. Jako przykład czynności realizowanej w ramach tej strategii ENISA podaje m.in. wykonanie i udokumentowanie DPIA.

Powyższe zasady i proponowane strategie oraz taktyki narzucają zatem administratorom, a pośrednio także i wykonawcom aplikacji mobilnych, obowiązek takiego projektowania i konfigurowania swoich produktów, aby były one w stanie skutecznie zapewnić realizację wszystkich zasad dotyczących przetwarzania danych osobowych, tj. zasadę zgodności z prawem, rzetelności i przejrzystości, ograniczenia celu, minimalizacji danych, prawidłowości, ograniczenia przechowywania, integralności i poufności oraz rozliczalności.

Zatem przykładowa realizacja zasady przejrzystości może polegać na uwzględnieniu w fazie projektowania kwestii związanych z UI/UX oraz z dostępem do informacji o przetwarzaniu poprzez umożliwienie użytkownikowi łatwego dostępu do polityki prywatności aplikacji, np. dwa-trzy kliknięcia przy użyciu jednej ręki (w duchu zasady trzech kliknięć). Polityka prywatności powinna móc być wyświetlana z uwzględnieniem zasad uniwersalnego projektowania i dostępności cyfrowej. W szczególności, gdy docelowym użytkownikiem mogą być dzieci lub osoby wymagające szczególnego traktowania.

W celu realizacji przejrzystości można również wdrażać rozwiązania związane z warstwowym informowaniem osób, których dane dotyczą.

Cykl życia aplikacji mobilnej a ochrona danych osobowych

Istnieją różne opisy cyklu życia oprogramowania, jakkolwiek co do zasady można wyróżnić następujące etapy: analiza i identyfikacja wymagań, projektowanie, programowanie, testowanie, wdrożenie i utrzymanie.

Diagnoza zgodności RODO.
Zrób to sam

Wykorzystaj elastyczne narzędzie do inwentaryzacji, audytu, przeprowadzenia DPIA oraz analizy ryzyka.
POZNAJ DR RODO
Ponadto, podmiot odpowiedzialny za proces tworzenia aplikacji może zdecydować się na szereg metodyk tworzenia oprogramowania, od których będzie zależało jak projektować prywatność danego rozwiązania. W metodykach waterfallowych (kaskadowych) już na etapie projektowania można zdefiniować cel i charakter przetwarzania oraz wymogi stawiane przez RODO w kontekście danego rozwiązania, a także dobrać środki techniczne i organizacyjne, które skutecznie pozwolą realizować zasady przetwarzania danych osobowych. Wydaje się, że trudniejsze zadanie będzie stało przed podmiotami decydującymi się na rozwiązania zwinne, które opierają się na ograniczonych w czasie sprintach. Trudność ta jednak będzie pozorna, gdyż zwinne metodyki pozwalają na szybkie reagowanie na zmieniające się okoliczności i parametry, co pozwala dostosować aplikację do bieżących potrzeb i zagrożeń. Konieczne jednak będzie odpowiednie zdefiniowanie wymagań/user stories oraz ról w zespole pod kątem ochrony danych. Przykładowo, Product Owner powinien dbać, aby zasady przetwarzania danych osobowych miały priorytet w backlogu produktu oraz w toku realizacji zadań, a Scrum Master powinien odpowiadać za to, aby wymagania względem prywatności były wdrażane w sprintach, a produkt był zgodny z RODO.

ENISA w swym raporcie jako przykład metodologii tworzenia oprogramowania skupionej na bezpieczeństwie, którą można zastosować w ramach metodyk zwinnych, wskazuje na metodykę Secure Development Lifecycle for Agile Development opartą na Microsoft Secure Development Lifecycle (SDL). Implementacja frameworku SDL do metodyk zwinnych będzie polegała w skrócie na implementacji wymogów SDL w trzech kategoriach zależnych od częstotliwości działań:

  • pierwszą kategorią są wymogi dla każdego sprintu – będą to wymogi bezpieczeństwa, bez których żadna aplikacja nie może być opublikowana (np. wymogi SDL dla firewalla, komunikowanie IODowi zmian w zakresie prywatności aplikacji);
  • kolejną kategorią są wymogi dla trzech „wiaderek” (ang. buckets), które implementuje się regularnie w cyklu życia aplikacji. Będą to z reguły zadania, których wykonanie nie jest konieczne w każdym sprincie. Z punktu widzenia czynności z zakresu ochrony danych osobowych może to być np. przegląd i aktualizacja dokumentacji ochrony danych osobowych;
  • ostatnią kategorią jest kategoria czynności, które wykonuje się tylko raz w toku realizacji projektu. Przykładem z zakresu ochrony danych być wyznaczenie IODa i włączenie go do procesu.

Zgodnie z zasadami privacy by design i privacy by default, o ochronie danych osobowych wytwórca aplikacji będzie zatem musiał myśleć na każdym etapie tworzenia aplikacji, niezależnie od przyjętej metodyki, a także wersji produktu trafiającej do użytkownika końcowego (MVP czy pełna wersja programu).

Dla uproszczenia cykl życia aplikacji mobilnej podzielę na trzy etapy: etap projektowy, etap wykonawczy i etap wdrożenia. W każdym etapie wskazuję przykładowe czynności związane z procesami IT i biznesowymi, a także z ochroną danych osobowych.

  1. Obszar: IT/Biznes
  2. Etap projektowy
    - pomysł
    - badania rynku, tworzenie profilu potencjalnego użytkownika
    - budżetowanie, pozyskiwanie środków,
    - wybór technologii i architektury,
    - wybór metodyki i wykonawców,
    - analizy,
    - identyfikacja wymagań i ich dokumentacja,
    - projektowanie,
    - mock-up’y.
  3. Etap wykonawczy:
    - programowanie,
    - implementacje,
    - testowanie,
    - tworzenie treści.
  4. Etap wdrożenia:
    - przygotowanie do publikacji,
    - publikacja aplikacji w sklepie (np. App Store, Google Play),
    - utrzymanie.

RODO. Wspracie się przydaje!

  1. Obszar: Ochrona danych
  2. Etap projektowy
    - analiza ryzyka i DPIA, analiza rozwiązań third-party,
    - dobór środków technicznych i organizacyjnych w celu skutecznej realizacji zasad przetwarzania danych osobowych,
    - tworzenie dokumentacji ochrony danych,
    - identyfikacja zakresu danych niezbędnych, celów i podstaw prawnych przetwarzania, w tym zakresu uprawnień, które aplikacja musi uzyskać (dostępu do informacji przechowywanych w urządzeniu, np. lokalizacja, aparat, pamięć, kontakty, kamera etc.), domyślna ochrona danych,
    - identyfikacja wymogów względem prywatności sklepu z aplikacjami,
    - umowy z dostawcami i wykonawcami (umowy powierzenia, umowy o współadministrowanie etc.),
    - ocena obowiązku wyznaczenia IODa oraz jego ewentualne wyznaczenie i zgłoszenie,
    - identyfikacja transferów danych,
    szkolenia dla osób zaangażowanych w projekt.
  3. Etap wykonawczy:
    - polityka prywatności, treść zgód i checkboksów klauzule informacyjne,
    - regulaminy,
    - dokonywanie przeglądów, monitorowanie zmian mających wpływ na charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych,
    - finalizowanie dokumentacji ochrony danych,
    - testowanie zabezpieczeń aplikacji,
    - testowanie rozwiązań z zakresu realizacji praw podmiotów danych,
    - informowanie IODa o zmianach w zakresie prywatności.
  4. Etap wdrożenia:
    - dokonywanie przeglądów, monitorowanie zmian mających wpływ na charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych,
    - aktualizowanie polityki prywatności,
    - testowanie,
    - realizacja praw podmiotów danych,
    - monitorowanie i obsługa naruszeń ochrony danych.

Pozostałe wymogi prawne w zakresie bezpieczeństwa i przejrzystości aplikacji mobilnych

Poza ogólnymi wymogami stawianymi przez RODO aplikacje mobilne mogą podlegać także przepisom szczególnym, które nakładają konkretne obowiązki na podmioty odpowiedzialne za aplikacje.

W zakresie przepisów, pod które będą podlegać podmioty prywatne warto wskazać:

  • rozporządzenie Ministra Zdrowia z dnia 17 grudnia 2020 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinny spełniać aplikacje mobilne służące do przesyłania danych zawartych w informacji o wystawionej recepcie oraz sposobu wymiany informacji w postaci elektronicznej między Internetowym Kontem Pacjenta i aplikacjami mobilnymi (Dz.U. z 2020 r. poz. 2330), w którym ustawodawca wskazuje wymagania, jakie powinna spełniać aplikacja, poprzez którą użytkownik może otrzymać informacje o udzielonej recepcie w postaci elektronicznej,
  • rozporządzenie Ministra Cyfryzacji z dnia 28 maja 2020 r. w sprawie aplikacji mobilnej służącej do rozliczania opłaty za przewóz osób (Dz.U. z 2020 r. poz. 954), które ustanawia m.in. minimalne wymogi względem zabezpieczeń w aplikacjach wspomagających świadczenie usług w zakresie pośrednictwa w przewozie osób;

W zakresie przepisów, które dotyczą podmiotów ze sfery publicznej należy wskazać:

  • art. 19e – 19i ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. 2005 Nr 64, poz. 565 ze zm.), które ustanawiają „publiczną aplikację mobilną”, tj. aplikację znaną jako „mObywatel”;
  • ustawę z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. z 2019 r. poz. 848 ze zm.), która nakłada na podmioty publiczne obowiązek zapewnienia dostępności cyfrowej w aplikacjach mobilnych poprzez odesłanie do wymagań zawartych w załączniku do ustawy, które to wymagania mają spełniać kryteria określone w pkt. 9, 10 i 11 normy EN 301 549 V2.1.2, która odsyła do standardu WCAG 2.1. Przepisy te mają wysoką doniosłość w kontekście zasady przejrzystości, gdyż nakazują, aby aplikacje mobilne podmiotów publicznych były dostępne cyfrowo, tj. spełniały zasady funkcjonalności, kompatybilności, postrzegalności i zrozumiałości.

Ostatnia ustawa zawiera – jak się wydaje – jedyną legalną definicję aplikacji mobilnej w polskim prawie: „publicznie dostępne oprogramowanie z interfejsem dotykowym zaprojektowane do wykorzystania na przenośnych urządzeniach elektronicznych, z wyłączeniem aplikacji przeznaczonych do użytku na przenośnych komputerach osobistych”.

Podsumowanie

W procesie tworzenia aplikacji mobilnej ochrona danych osobowych powinna przenikać przez każdy etap cyklu życia aplikacji – od powstania pomysłu po jej publikację w sklepie z aplikacjami, a następnie utrzymanie. Podmiot odpowiedzialny za aplikację, któremu będziemy mogli nadać przymiot administratora danych osobowych, powinien mieć świadomość zagrożeń istniejących w mobilnym ekosystemie, a także wymogu uwzględniania ochrony danych w fazie projektowania i domyślnej ochrony danych.

Czytaj także:

Najczęstsze błędy przy zawieraniu umów powierzenia
Administratorem Twoich danych jest ODO 24 sp. z o.o. z siedzibą w Warszawie (03-812) przy ul. Kamionkowskiej 45. Twoje dane są przetwarzane w celu świadczenia usługi biuletyn informacyjny na zasadach określonych w Regulaminie ŚUDE. Więcej informacji na temat procesu przetwarzania danych osobowych oraz przysługujących Ci praw uzyskasz w Polityce prywatności.
Potwierdź swój adres e-mail
Wejdź na swoją skrzynkę pocztową, otwórz wiadomość od ODO 24 i potwierdź adres e-mail, klikając w link.
Jeżeli nie znajdziesz naszej wiadomości - sprawdź w folderze SPAM. Aby w przyszłości to się nie powtórzyło oznacz wiadomość jako pożądaną (klikniknij prawym przyciskiem myszy i wybierz “Oznacz jako wiadomość pożądaną”).
Odbierz bezpłatny pakiet 4 poradników
i 4 szkoleń e-learningowych RODO
4x4 - Odbierz bezpłatny pakiet 4 poradników i 4 szkoleń RODO
Administratorem Twoich danych jest ODO 24 sp. z o.o. z siedzibą w Warszawie (03-812) przy ul. Kamionkowskiej 45. Twoje dane są przetwarzane w celu świadczenia usługi biuletyn informacyjny na zasadach określonych w Regulaminie ŚUDE. Więcej informacji na temat procesu przetwarzania danych osobowych oraz przysługujących Ci praw uzyskasz w Polityce prywatności.
Administratorem Twoich danych jest ODO 24 sp. z o. o. >>>