Source: https://www.marcoos.net/index.php/author/marco/
Timestamp: 2020-02-18 19:03:31
Legal References Found: Art. 172
 Art. 15
 Art. 172
 art. 172
 art. 36
 art. 35
 art. 37

Document Content:
marco – poletko testowe
poletko testowe
Iluzja ochrony danych osobowych w Polsce
Autor wpisu Autor: marco
Data wpisu 31 maja, 2019
3 komentarze do Iluzja ochrony danych osobowych w Polsce
Od sierpnia próbuje ustalić w jaki sposób firmy LoanMe i DBMS stwierdziły, że mogą wysyłać na mój numer telefonu SMSy z reklamami chwilówek. W momencie dociekania szczegółów firmy zaczynają milczeć, UKE umywa ręce a UODO od października 2018 prowadzi postępowanie z którego nic nie wynika, tłumacząc przewalenie terminów „dużą ilością zgłoszeń”
SMSowe naganianie na chwilówkę
Wśród różnorakiego spamu telefonicznego i SMSowego szczególnie zapadł mi w pamięć przypadek SMSów od nadawcy „LoanMe” i „LoanMeSMS” zachęcającego do pozabankowego kredytu. Przypadek o tyle szczególny, że nie kryli się za losowym numerem, tylko podpisywali SMSy swoją nazwą, słali je namiętnie i dziwnym trafem nie tylko do mnie ale do kilku pozostałych członków rodziny.
Próba kontaktu z nadawcą
Naiwnie zakładając, że RODO i Prawo Telekomunikacyjne pozwala skutecznie walczyć z takimi praktykami wystosowałem 22 sierpnia 2018 maila na adres kontakt@loanme.pl o treści
proszę o informacje na podstawie jakiej zgody na numer telefonu 502 XXX XXX wysyłane są wiadomości tekstowe z nadawcą LoanMe oraz LoanMeSMS zawierające reklamę usług Państwa firmy. W szczególności proszę o wskazanie gdzie i kiedy została wyrażona wg. Państwa zgoda niezbędna zgodnie z Art. 172 PT.
Proszę również o dostarczenie klauzuli informacyjnej, oraz kopii przetwarzanych danych dotyczących mojej osoby na podstawie Art. 15 ust. 3 RODO.
Na który została szybko udzielona odpowiedź nie odnosząca się do przedmiotu zapytania (jak widać w powyższym liście nie żądałem na razie usunięcia danych a spełnienia obowiązku informacyjnego)
Informujemy, iż otrzymaliśmy Pana zgłoszenie dotyczące usunięcia numeru z bazy danych.
Dyspozycja usunięcia numeru została przesłana do wszystkich partnerów marketingowych. Wystosowaliśmy również prośbę o uzyskanie informacji o źródle pozyskania numeru.
Po uzyskaniu odpowiedzi, zostanie ona natychmiastowo przekazana do Pana.
Informujemy również, że nie posiadamy żadnych danych osoby użytkującej w/w numer.
Proces może potrwać do 7 dni.
Dziękujemy za cierpliwość i przepraszamy za niedogodności.
I po 7 dniach kolejny mail:
Wskazany numer został trwale usunięty z bazy numerów telefonicznych.
Oświadczamy, iż nie dysponujemy i nigdy nie dysponowaliśmy żadnymi danymi właściciela lub osoby użytkującej ten numer telefonu, o którym jest mowa.
Zdarza się, że numer jest błędnie wpisany lub błędnie wybrany przez system.
Pozostaje on jednak tylko nieprzypisanym do konkretnej osoby ciągiem cyfr.
Przepraszamy za niedogodność i zapewniamy, iż nie ma powodu do niepokoju.
Ponieważ odpowiedź znowu nie odnosiła się do meritum (skąd pozyskano dane i na podstawie jakich zgód wysyłana była komunikacja) wysłałem kolejne przypomnienie czego dotyczyło pierwotne żądanie:
to nie jest odpowiedź na postawione pytanie. Art. 172 PT wyraźnie wskazuje, że na wysyłkę wiadomości powinniście posiadać wyrażoną zgodę.
Ponownie proszę o wskazanie w jaki sposób i kiedy zgoda ta została wyrażona. W przeciwnym przypadku będę czuł się zobowiązany złożyć zawiadomienie zarówno do UKE jak i PUODO.
Na co w odpowiedzi następuje zmiana stanowiska LoanMe i zaczynają twierdzić, że to tak naprawdę nie ich baza danych i są jedynie licencjobiorcą (ciekawe określenie w kontekście Administratora Danych Osobowych):
Dziękujemy za wiadomość. Informujemy, iż jest Pan informowany na bieżąco o kolejnych naszych działaniach. Numer 48502XXXXXX pochodzi z bazy, do której mamy tylko licencję użytkowania.
Jeśli klient chce uzyskać szczegółowe informacje dotyczące źródła pochodzenia jego numeru należy skontaktować się z firmą DBMS Sp. z o. o. poprzez formularz kontaktowy dostępny na stronie https://zastrzezeniedanych.pl/ lub pod adresem e-mail: iod@dmsales.com.
Informujemy ponownie, że nie posiadamy żadnych danych osoby użytkującej w/w numer.
mnie nie interesuje skąd zostały pozyskane te dane. Kto wysyłał wiadomości? DBMS czy Wy. Jeśli Wy to musicie mieć na to wyraźną zgodę tak samo jak na przetwarzanie danych osobowych którymi jest również numer telefonu.
Ponawiam żądanie o wskazanie:
– źródła zgody w szczególności w zakresie terminu i formy jej udzielenia
– przesłania kompletu danych dotyczących mojej osoby przetwarzanego w systemach spółki w szczególności z uwzlędnieniem momentu pozyskania danych oraz każdorazowego wykorzystania danych do celów marketingu bezpośredniego.
W przypadku braku otrzymania informacji do końca tego tygodnia jak w poprzedniej wiadomości z radością przekażę temat do UKE i PUODO.
Wiadomość niestety spowodowała zapętlenie się pracowników LoanME bo kolejna odpowiedź była identyczna z poprzednią
Po kolejnych żądaniach co do wskazania źródła zgody ostatnią wypowiedzią przedstawicielki LoanME było:
Spółka LoanMe, nie jest właściwym adresatem pytań /roszczeń ze względu na fakt, iż nie jest Administratorem danych klientów, a jedynie przetwarza je w celu realizacji kampanii, na podstawie licencji udzielonej przez Administratora tj. Spółkę DBMS Sp. z o.o. ul Gwiaździsta 71 lok. 10 Warszawa. W przypadku jeśli klient chce otrzymać dodatkowe informacje na temat swoich danych, zgłosić sprzeciw lub wnieść wniosek o poprawę danych prosimy skontaktować się z Administratorem poprzez portal www.zastrzezeniedanych.pl lub telefonicznie z działem IOD pod numerem 732 052 112.
Równolegle napisałem 10 września 2018 do wskazanej przez LoanME firmy DBMS:
na podstawie korespondencji z firmą LoanME która twierdzi, że rzekomo pracuje na zbiorze danych licencjonowanych przez Państwa firmę proszę o złożenie wyjaśnień:
1) kompletu informacji na temat mojej osoby znajdującej się w Państwa zbiorach danych
2) komu i kiedy zostały one udostępnione
3) podstawy prawnej (forma i data udzielenia zgody)
Równocześnie składam żądanie usunięcia wszystkich moich danych z jakichkolwiek baz administrowanych bądź współadministrowanych przez DBMS sp. z o.o.
Ze względu na brak odpowiedzi 25 września przesłałem ponaglenie:
Ponawiam żądanie o treści jak w poprzedniej wiadomości. Jednocześnie informuje, że w przypadku nie spełnienia żądania w sposób kompletny w terminie jednego miesiąca od czasu jego pierwotnego złożenia informacja ta trafi w pierwszej kolejności do PUODO.
W międzyczasie złożyłem do UKE zawiadomienie o naruszeniu art. 172 Prawa Telekomunikacyjnego. Odpowiedź przyszła szybko, ale oprócz pouczenia i powołania się na przepisy PT merytorycznie zawierała tylko informacje, że:
Wobec powyższego uprzejmie informuję, że przesłana przez Pana wnioskiem z dnia 10 września 2018 r. informacja dotycząca otrzymywania połączeń telefonicznych/wiadomości SMS od firmy LoanMe Sp. z o.o. bez uzyskania od Pana uprzednio zgody, zostanie przeanalizowana pod kątem wszczęcia postępowania kontrolnego lub postępowania administracyjnego w przedmiocie nałożenia kary pieniężnej, o której mowa powyżej.
Niestety od 14 września UKE milczy czy postępowanie zostało wszczęte czy też temat został przez UKE porzucony
Urząd Ochrony Danych Osobowych – część 1
Ponieważ ani DBMS ani LoanME nie chciały współpracować włączyłem w proces świeżo przemianowany w wyniku implementacji RODO Urząd Ochrony Danych Osobowych. Przekazałem do UODO kopie całej korespondencji i wysyłanych SMSów 16 października 2018. Urząd wezwał mnie 7 listopada do uzupełnienia braków we wniosku co też zrobiłem 9 listopada. I w tym momencie zapadła cisza. Pierwsze ponaglenie zostało wysłane do UODO 20 stycznia na co UODO wystosował odpowiedź która mówi tyle co nic:
W nawiązaniu do Pana skargi na przetwarzanie Pana danych osobowych przez DBMS Sp. z o.o. z siedzibą w Warszawie przy ul. Gwiaździstej 71/10 oraz LoanMe Sp. z o.o. z siedzibą w Warszawie przy Alejach Jerozolimskich 142 B, informuję, że Prezes Urzędu Ochrony Danych Osobowych zwrócił się do ww. podmiotów o złożenie wyjaśnień w sprawie.
O wynikach podjętych czynności wyjaśniających i merytorycznym rozstrzygnięciu sprawy poinformujemy Pana w odrębnym piśmie.
Czyli pomimo upłynięcia 3 miesięcy urząd nie potrafi w żaden sposób merytorycznie ustosunkować się do sprawy.
DBMS odpowiada
Chwilę po odpowiedzi z UODO dziwnym zbiegiem okoliczności DBMS odpowiada na wiadomości z września 2018 (po 5 miesiącach!)
W związku z Pana wnioskiem z dnia 10 września 2018 r. informujemy co następuje:
Przetwarzaliśmy dane, które Pana dotyczą.
W załączeniu wyciąg z bazy danych z kopią Pana danych osobowych przetwarzanych przez DBMS Sp. z o.o.
Spółka DBMS sp. z o.o. pozyskała Pana przez serwis Ekofaktura lub poprzez działania promocyjne wspierające rozwój tego serwisu. Zgoda została udzielona w postaci elektronicznej podczas rejestracji w serwisie z numeru IP: 95.108.84.xxx z datą 2012-03-01. Dane wykorzystywane są w celu realizacji kampanii marketingowych oraz obejmują imię, nazwisko, adres, telefon.
W dniu 27 sierpnia 2018 r. dane zostały usunięte ze zbiorów marketingowych.
Spółka DBMS Sp. z o.o. obecnie przetwarza Pana dane wyłącznie w celu umożliwienia realizacji obowiązków informacyjnych jak również ewentualnej ochrony przed roszczeniami. Okres przechowywania danych osób, które zażądały ich usunięcia wynosi w DBMS Sp. z o.o. 4 lata, co stanowi przybliżony okres możliwości dochodzenia roszczeń cywilnoprawnych przez podmiot danych. Obecnie podstawą przetwarzania jest opisany powyżej uzasadniony prawnie interes administratora (art. 6 ust. 1 lit. f RODO).
Przekazaliśmy Pańskie żądanie wszystkim odbiorcom, którym zostały one powierzone, tj. firmom (w nawiasie data powierzenia danych):
Phinance – 2018-08-09
LoanMe – 2018-06-07
Jednocześnie bardzo przepraszamy za opóźnienie w odpowiedzi, wynikało ono z błędnej dekretacji pisma, które do nas wpłynęło przez jednego z naszych pracowników, który został w związku z zaistniałą sytuacją przez nas upomniany i poddany dodatkowemu szkoleniu z zakresu postępowania z korespondencją dotyczącą żądań osób, których dane przetwarzamy.
Zabawne w tym wszystkim jest, że do maila nie został dołączony załącznik o którym mowa w jego treści.
Ponieważ nie kojarzyłem żadnego serwisu o nazwie ekofaktura w którym bym się rejestrował, historia wyszukiwania w gmailu z którego korzystam od lat też nie pomogła to atakowałem dalej. Dodatkowo wskazany przez DBMS adres IP należy do operatora z którego nigdy nie korzystałem – przez cały czas od 2005-2018 byłem abonentem innego operatora.
z żalem zauważam, że „błąd” odkryliście dopiero po otrzymaniu korespondencji od PUODO.
W nawiązaniu do udzielonej odpowiedzi:
2) nie otrzymałem załącznika a jak rozumiem w takiej formie miał być dostarczony wyciąg. Proszę o jego pilną wysyłkę
3) kto jest operatorem serwisu ekofaktura? Jakie jest dokładne brzmienie zgód których rzekomo udzieliłem? Jaka była dokładna godzina ich udzielenia i czy zachowana została procedura double opt-in w celu weryfikacji numeru telefonu. Podany adres IP należy do operatora East and West Sp. z o.o. z usług którego nigdy nie korzystałem.
Dodatkowo jeśli dane były przetwarzane od 2012 to dlaczego do dziś nie została doręczona Klauzula Informacyjna?
Na tą wiadomość i kolejne ponaglenia nie uzyskałem już nigdy odpowiedzi.
Urząd ochrony danych osobowych – dalsze ponaglenia
Kolejne ponaglenia do UODO zostały wysłane 3 kwietnia (zażalenie na bezczynność) i 24 maja
Odpowiedź jest dość kuriozalna:
Nawiązując do dotychczasowej korespondencji dotyczącej Pana skargi na przetwarzanie Pana danych osobowych przez DBMS Sp. z o.o. z siedzibą w Warszawie przy ul. Gwiaździstej 71/10 oraz LoanMe Sp. z o.o. z siedzibą w Warszawie przy Alejach Jerozolimskich 142 B, informuję, że Prezes Urzędu Ochrony Danych Osobowych nadal podejmuje działania w celu wyjaśnienia przedstawionej przez Pana sprawy.
Jednocześnie informuję, iż Prezes Urzędu Ochrony Danych Osobowych ponownie zwrócił się do ww. podmiotów o złożenie dodatkowych wyjaśnień w sprawie. Dotychczas zebrany materiał dowodowy nie jest wystarczający do wydania decyzji administracyjnej.
O dalszych czynnościach zostanie Pan poinformowany w odrębnym piśmie.
Jednocześnie na podstawie art. 36 § 1 ustawy z 14 czerwca 1960 r. Kodeks postępowania administracyjnego (zwanej dalej: Kpa) Prezes Urzędu Ochrony Danych Osobowych informuje, iż niniejsza sprawa nie została załatwiona w terminie określonym w art. 35 Kpa, z uwagi na znaczną ilość spraw prowadzonych przez Prezesa Urzędu. Termin załatwienia sprawy zostaje przedłużony o dwa miesiące. Na podstawie art. 37 Kpa, w przypadku nie załatwienia sprawy w terminie bądź prowadzenia przez organ postępowania dłużej niż jest to niezbędne do załatwienia sprawy (przewlekłość), stronie przysługuje prawo do wniesienia ponaglenia do Prezesa Urzędu Ochrony Danych Osobowych (ul. Stawki 2, 00-193 Warszawa). Ponaglenie powinno zawierać uzasadnienie. Organ rozpatruje ponaglenie w terminie 7 dni od jego otrzymania
Innymi słowy ponieważ urząd ma dużo pracy to jest to uzasadnienie do opóźnienia postępowania. Oczywiście termin 2 miesięcy nie został dochowany.
Wniosek jest jeden – prowadzisz firmę w szczególności działającą w etycznie wątpliwej branży? Spamuj ile wlezie. Póki sprawa nie dotyczy wycieku setek tysięcy informacji co spowoduje medialną histerie organy państwa nie zrobią Ci absolutnie nic.
czekam na odopowiedź UODO na kolejne ponaglenie
zamierzam odpytać UKE o ilość zgłoszeń na działania LoanME i czy podjęto jakiekolwiek działania wobec tego podmiotu
SCM-Manager + apache z mod_jk = problem
Data wpisu 22 października, 2014
Brak komentarzy do SCM-Manager + apache z mod_jk = problem
Od kilku tygodni do zarządzania repozytoriami subversion używam całkiem sensownego narzędzia o nazwie SCM-Manager (i zgodnie z nazwą oprócz SVN wspiera też GITa i Mercuriala). Ponieważ cały ruch na zewnątrz chce mieć szyfrowany za SSL i ładne adresy odpowiada apache. Niestety pierwotna metoda podłączenia aplikacji odpalonej na jetty’m z apachem za pomocą mod_jk i AJP okazała się niestrawna dla SVNKita z którego korzysta SCM-Manager i kończyła się błędem 500 przy próbie checkoutu z repozytorium.
Rozwiązaniem lepszym, ba jak się okazuje polecanym w dokumentacji do serwera jetty jest wykorzystanie mod_proxy i HTTP zamiast AJP. Taka konfiguracja okazuje się stabilna, bezproblemowa i wymaga minimalny zmian w konfiguracji jetty i apache’a.
W pliku konfiguracyjnym jetty (przy instalacji z paczki .deb znajdziemy go w /opt/scm-manager/conf/server-config.xml) odkomentowujemy linijkę mówiącą o tym, że zapytania będą forwardowane przez proxy:
<Configure class="org.eclipse.jetty.server.Server">
<SystemProperty name="jetty.host" />
<Set name="Port">8090</Set>
<Set name="requestHeaderSize">16384</Set>
<!-- for mod_proxy -->
A w samym apache’u uruchamiamy jeśli nie posiadaliśmy do tej pory moduł proxy (a2enmod proxy_http) a w konfiguracji VirtualHosta (w moim przypadku :443 z SSLem):
ProxyPass /scm http://localhost:8090/scm
ProxyPassReverse /scm http://localhost:8090/scm
<Location /scm>
RequestHeader set X-Forwarded-Proto "https" env=HTTPS
Oczywiście port 8090 można zastąpić dowolnym innym otwartym portem, a X-Forwarded-Proto dodajemy tylko w przypadku gdy ruch będzie szedł HTTPSem.
Tagi apache, apache 2.4, mod_jk, mod_proxy, scm-manager, svn
Luke o Iluzja ochrony danych osobowych w Polsce
Andrzej Duqa o Iluzja ochrony danych osobowych w Polsce
Mogherini Dick o Iluzja ochrony danych osobowych w Polsce
© 2020	poletko testowe