Ocena skutków dla ochrony danych (art. 35 RODO) – MousePlayer Session Replay

1. Dlaczego ta ocena jest wymagana

Art. 35 ust. 1 RODO wymaga oceny skutków, jeżeli dany rodzaj przetwarzania - w szczególności z użyciem nowych technologii i z uwzględnieniem jego charakteru, zakresu, kontekstu i celów - z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. MousePlayer rejestruje zachowanie odwiedzających witryny w sposób ciągły i domyślny: ruch wskaźnika, kliknięcia, przewijanie, dotknięcia i przełączanie kart, wraz z pełnym zrzutem strony, którą odwiedzający zobaczył, i każdą jej późniejszą zmianą, a do tego tekst, który odwiedzający wpisuje do formularzy. Zarejestrowany materiał jest przechowywany, odtwarzany, oceniany i może być udostępniany. To nie jest przypadek brzegowy art. 35 ust. 1; to jego istota.

Jeden punkt kwalifikacji trzeba wskazać precyzyjnie, a nie powtórzyć za innymi. Art. 35 ust. 3 wymienia trzy przypadki, w których ocena skutków jest wymagana w szczególności, i żaden z tych trzech nie pasuje w sposób czysty. Litera a) obejmuje systematyczną, kompleksową ocenę opartą na zautomatyzowanym przetwarzaniu, która jest podstawą decyzji wywołujących skutki prawne lub w podobny sposób znacząco wpływających na osobę - ocena tutaj istnieje (por. ryzyko R8), ale nie znaleziono takiej decyzji wobec odwiedzającego. Litera b) obejmuje przetwarzanie na dużą skalę szczególnych kategorii danych z art. 9 - tu niezamierzone, choć szczególne kategorie trafiają do nagrania niezamierzoną drogą (ryzyko R1), a zmierzone wolumeny w tym systemie nie są dużą skalą. Litera c) obejmuje systematyczne monitorowanie na dużą skalę miejsc dostępnych publicznie, co odnosi się do obserwacji fizycznej, a nie do witryny internetowej. Powołanie litery b) jako podstawy dla session replay byłoby błędem, a błędne powołanie jest pierwszą rzeczą, którą organ skreśla.

Właściwą drogą jest sam art. 35 ust. 1, stosowany przez dziewięć kryteriów wytycznych Grupy Roboczej Art. 29 dotyczących oceny skutków (WP248 rev.01, zatwierdzonych przez EROD). Przyjmuje się, że dwa spełnione kryteria wskazują na wysokie ryzyko. To przetwarzanie spełnia sześć lub siedem.

• Ocena lub punktacja - spełnione. Każda sesja otrzymuje engagement_score (0-255), session_quality i is_bot; w chwili pomiaru w sierpniu 2026 r. istniało 4043 wierszy cech i 3203 maszynowo napisanych narracji sesji. Od tego czasu doszły dalsze oceny i dane pochodne (por. R8).
• Zautomatyzowane podejmowanie decyzji o skutku prawnym lub podobnym - nieustalone wobec odwiedzających. Ustalone wobec klientów i adresów IP (automatyczna blokada, is_suspicious), co jest inną grupą osób, których dane dotyczą.
• Systematyczne monitorowanie - spełnione w najsilniejszej postaci. Nagrywanie jest ciągłe, metodyczne i niewidoczne dla obserwowanej osoby, gdy tylko zniknie baner.
• Dane wrażliwe lub dane o wysoce osobistym charakterze - spełnione. Wpisy do formularzy, pełna treść strony w postaci wyrenderowanej dla tej konkretnej osoby oraz zapis minuta po minucie tego, co czytała i przy czym się wahała.
• Duża skala - nie spełnione przy zmierzonych liczbach tego systemu deweloperskiego (pomiar z sierpnia 2026 r.: 706 sesji, 329 odrębnych identyfikatorów odwiedzających, 7 projektów, 4 konta. Stan na 16.10.2026: 8648 sesji ludzi z 7363 odrębnymi identyfikatorami odwiedzających od 21.07.2026, w tym 3515 odrębnych identyfikatorów w ostatnich 30 dniach, w 3 z 75 utworzonych projektów; ponadto 186163 sesje oznaczone jako boty z ostatnich 14 dni, usuwane po upływie ich terminu; 24 konta, w tym 19 rozpoznawalnych kont testowych). Jest spełnione w zamyśle projektowym, a projekt nie zawiera żadnej górnej granicy.
• Dopasowywanie lub łączenie zbiorów danych - spełnione. MousePlayer.setUserId() oraz automatyczna ścieżka dataLayer 'uid' dołączają własny identyfikator klienta do nagrania; eksport do BigQuery wysyła visitor_id, custom_user_id i ip_address do własnej hurtowni klienta.
• Osoby wymagające szczególnej ochrony - dające się obronić. Odwiedzający nie widzi, co zarejestrowano, nie może tego zweryfikować, a w 92 przypadkach według pomiaru z sierpnia 2026 r. nie dało się go w ogóle powiązać z jego własnymi rekordami (stan na 16.10.2026: brak takiej sesji; por. R9).
• Innowacyjne zastosowanie - spełnione. Odtwarzanie pełnego DOM połączone z maszynowo generowanymi narracjami behawioralnymi nie jest ugruntowaną, dobrze rozpoznaną techniką.
• Uniemożliwienie wykonywania prawa lub korzystania z usługi - spełnione w dwóch wąskich aspektach: automatyczna blokada IP przerywa dalszy dostęp, a luka identyfikacyjna (R9) czyni art. 15 i art. 17 technicznie niewykonalnymi dla części przechowywanych danych.

Art. 35 ust. 4 zobowiązuje każdy organ nadzorczy do opublikowania wykazu rodzajów operacji przetwarzania podlegających wymogowi oceny skutków. Właściwym organem jest tu polski Prezes UODO. do uzupełnienia: które pozycje aktualnego wykazu UODO z art. 35 ust. 4 odnoszą się do session replay oraz data sprawdzonej wersji wykazu

2. Role: kto ma ten obowiązek i za co

MousePlayer zajmuje jednocześnie dwie pozycje, a odpowiedź na niemal każde pytanie w tym dokumencie zależy od tego, o którą z nich chodzi. To rozróżnienie nie jest wyborem redakcyjnym; jest wpisane w kod. class/Server.class.php:416 stwierdza to w samym źródle: "REGEL B ... Hier sind wir AUFTRAGSVERARBEITER" - tutaj jesteśmy podmiotem przetwarzającym.

Dane	Rola MousePlayer	Administrator	Konsekwencja
Odwiedzający witryny klientów: nagrania, treść stron, wpisy w formularzach, identyfikatory, wyprowadzone oceny	Podmiot przetwarzający (art. 28)	Klient MousePlayer prowadzący witrynę	Obowiązek z art. 35 formalnie spoczywa na kliencie. Obowiązkiem MousePlayer jest wsparcie na podstawie art. 28 ust. 3 lit. f).
Klienci samego MousePlayer: konta, rozliczenia, wsparcie, logi dostępu do panelu, dziennik zmian	Administrator (art. 24)	LW IT Solutions Company Lukas Wójcik	MousePlayer we własnym imieniu odpowiada za ocenę z art. 35 dla tego przetwarzania - choć sama ta część nie uruchomiłaby takiego obowiązku.

Daje to wynik, który warto powiedzieć wprost, ponieważ często mylony jest w obie strony. Przetwarzanie, które wymaga oceny skutków, jest przetwarzaniem, dla którego MousePlayer nie jest administratorem. Podmiot przetwarzający nie może przeprowadzić oceny za administratora, nie może w jego imieniu rozstrzygnąć kwestii niezbędności ani nie może zamiast niego przeprowadzić konsultacji z organem nadzorczym na podstawie art. 36. To, co podmiot przetwarzający może i musi zrobić, to dostarczyć administratorowi wszystkiego, czego administrator potrzebuje - opisu z lit. a), zmierzonych faktów z lit. c) i uczciwej listy statusów z lit. d). Tym właśnie jest ten dokument: własną oceną MousePlayer dotyczącą własnych operacji oraz podstawą faktyczną, której klient potrzebuje do swojej.

3. Inspektor ochrony danych: test z art. 37

Inspektor ochrony danych nie został wyznaczony. Art. 37 ust. 1 wiąże jednakowo "administratora i podmiot przetwarzający", więc pytanie jest własnym pytaniem MousePlayer, a nie takim, które można przerzucić na klientów. Trzy ustawowe przypadki:

Art. 37 ust. 1	Test	Wynik przy zmierzonych faktach
lit. a)	Przetwarzanie przez organ lub podmiot publiczny	Nie dotyczy. LW IT Solutions Company jest przedsiębiorstwem prywatnym.
lit. b)	Główna działalność wymaga regularnego i systematycznego monitorowania osób, których dane dotyczą, na dużą skalę	Główna działalność: tak, bez dyskusji - monitorowanie jest produktem, a nie funkcją pomocniczą. Regularne i systematyczne: tak - ciągłe, metodyczne, według z góry przyjętego systemu. Duża skala: nie, przy zmierzonych liczbach (pomiar z sierpnia 2026 r.: 706 sesji, 329 identyfikatorów, 4 konta; stan na 16.10.2026: 3515 odrębnych identyfikatorów odwiedzających będących ludźmi w ciągu 30 dni; jedna instancja deweloperska).
lit. c)	Główna działalność polega na przetwarzaniu na dużą skalę danych z art. 9 lub art. 10	Nie w zamyśle. Szczególne kategorie mimo to trafiają do zapisanej treści strony drogą opisaną w ryzyku R1. Jest to raczej uboczne niż konstytutywne, więc dziś przesłanka nie jest spełniona - ale staje się dyskusyjna w chwili pozyskania klienta z sektora ochrony zdrowia, prawnego lub finansowego.

WP243 (zatwierdzone przez EROD) ocenia "dużą skalę" według liczby osób, których dane dotyczą, wolumenu i zakresu danych, czasu trwania oraz zasięgu geograficznego. Trzy z tych czterech czynników są tu już na maksimum: zakres to pełna rekonstrukcja sesji osoby, czas trwania jest ciągły, a zasięg geograficzny jest taki, jak audytoria klientów. Mała jest wyłącznie liczba osób. Aby próg nie został zauważony zbyt późno, srv/cron_status.php od 19.08.2026 raz dziennie liczy odrębne identyfikatory odwiedzających będących ludźmi z ostatnich 30 dni (bez 'unknown' i bez sesji oznaczonych jako boty), porównuje tę liczbę z progiem 100000 użytkowników końcowych miesięcznie i zgłasza pocztą elektroniczną przekroczenie oraz przypadający coroczny przegląd. Stan na 16.10.2026: 3515.

Wynikają z tego dwie rzeczy i obie są zaleceniami, a nie stwierdzeniami stanu prawnego. Po pierwsze, należy już teraz sporządzić pisemną ocenę progową, z podaną liczbą monitorowanych użytkowników końcowych, przy której wyznaczenie następuje automatycznie, oraz ze stałym odstępem przeglądu - tak, by decyzja była udokumentowana jako podjęta, a nie tylko jako jeszcze niepodjęta. Po drugie, art. 37 ust. 4 pozwala prawu państwa członkowskiego wymagać wyznaczenia w dalszych przypadkach. do uzupełnienia: potwierdzenie prawne, czy prawo polskie na podstawie art. 37 ust. 4 tworzy obowiązek wyznaczenia wykraczający poza art. 37 ust. 1. Próg i częstotliwość przeglądu są ustalone: ponad 100000 obserwowanych użytkowników końcowych miesięcznie, co najmniej raz w roku

Art. 35 ust. 2 wymaga, by administrator - jeżeli inspektor został wyznaczony - zasięgnął jego opinii przy dokonywaniu oceny skutków. Wobec braku wyznaczonego inspektora ten krok nie ma zastosowania, a jego pominięcie nie jest uchybieniem. Zatwierdzone przez Lukasa Wojcika, właściciela, 17.08.2026. Nie zasięgnięto zewnętrznej porady w zakresie ochrony danych. Przegląd corocznie oraz przy każdej zmianie przetwarzania; datowane wersje w systemie kontroli wersji w ai/cms/.

4. Metoda, źródła i granice tej wersji roboczej

Każde stwierdzenie faktyczne w tym dokumencie zostało zmierzone wobec działającego systemu - kodu źródłowego, schematu bazy danych, liczby wierszy, listy procesów, wartości konfiguracyjnych i plików dziennika - a nie zaczerpnięte z opisów produktu ani z tego, co oprogramowanie ma robić. Tam, gdzie pomiar przeczy zamiarowi, raportowany jest pomiar. Tam, gdzie faktu nie dało się ustalić, w jego miejscu stoi pole do uzupełnienia; żadna liczba nie została oszacowana i żaden okres przechowywania nie został wymyślony.

• Zmierzonym systemem jest instancja deweloperska (APP_ENV=dev). Kilka liczb jest zatem artefaktami danych testowych i jest tak oznaczonych - przede wszystkim zapisy zgód, gdzie 671 z 706 sesji nosi consent_source='testdata' z pustym znacznikiem czasu, zapisane przez ai/devdata/001_altsitzungen_markieren.sql (pomiar z sierpnia 2026 r.; stan na 16.10.2026: 566 z 8648 sesji ludzi).
• Część pomiarów wykonano w odstępie kilku minut i wskutek tego nieznacznie się różnią (705 wobec 706 sesji; 36409 wierszy dziennika wobec 36542 sprawdzonych adresów). Obie liczby podano tak, jak je zmierzono, zamiast uzgadniać je po fakcie.
• Dostęp na poziomie roota nie był dostępny. Konfiguracji jail dla fail2ban, crontabów roota i www-data oraz dotarcia kopii zapasowej poza siedzibę do miejsca docelowego nie dało się w związku z tym zweryfikować. Każde z tych ustaleń jest oznaczone jako niezweryfikowane, a nie przyjęte. Uzupełnienie: właściciel przeprowadził w międzyczasie przestawienie kopii zapasowej z uprawnieniami roota, a dotarcie kopii poza siedzibę do miejsca docelowego jest wykazane od 11.08.2026, ponieważ codzienny przebieg sam je protokołuje i sprawdza - udokumentowane dla 11.08.2026 i 12.08.2026 (por. R5). Sprawdzono ponownie 16.10.2026: fail2ban prowadzi dziewięć jaili, w tym mp-nginx-429 dla adresów, które wielokrotnie uruchamiają limit szybkości nginx. Zaplanowane przebiegi MousePlayer znajdują się w /etc/cron.d/mouseplayer i są wykonywane przez srv/cron_run.sh na odrębnym koncie mouseplayer-dev; na tym koncie działają też usługi procesów roboczych. Codzienna kopia zapasowa jest nadal uruchamiana z crona roota, a codzienny przebieg usuwania nadal działa w procesie db_worker.
• Katalogów vendor (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) nie przeszukano pod kątem wychodzących punktów końcowych. Kod własny przeszukano wyczerpująco pod kątem curl_init, curl_exec, file_get_contents na http, fsockopen i stream_context_create oraz wszystkich literałów https.
• Jedna liczba w tej ocenie - 92 sesje z visitor_id 'unknown' - została przyjęta przy pomiarze z sierpnia 2026 r. jako ustalony pomiar, ponieważ nie dało się jej wtedy zmierzyć ponownie. Zmierzono ponownie 16.10.2026: żadna sesja nie nosi już visitor_id 'unknown'. Kod nadal może zapisać tę wartość przy zakładaniu sesji (srv/db_worker.php); R9 pozostaje więc możliwe.

5. (a) Systematyczny opis operacji przetwarzania i celów

5.1 Jak działa nagrywanie

Klient osadza w swojej witrynie statyczny plik JavaScript (www/mp.js). Zanim cokolwiek zostanie zarejestrowane, muszą otworzyć się dwie bramki. Najpierw uruchamia się kontrola botów, która przerywa działanie dla zautomatyzowanych przeglądarek. Za nią stoi maszyna stanów zgody mpEinw, która zezwala na zbudowanie trackera wyłącznie po pozytywnym sygnale zgody - z własnego wywołania API klienta, z Google Consent Mode, z obsługiwanego CMP albo z ciągu TCF. Każdy inny wynik, w tym całkowity brak sygnału, CMP, który się nie wczyta, błąd skryptu i nieznane pochodzenie, prowadzi do braku nagrywania. Zasada przewodnia jest zapisana we własnych notatkach roboczych projektu i obowiązuje w całym kodzie: w razie wątpliwości nie nagrywać.

Po uzyskaniu zezwolenia skrypt otwiera szyfrowany WebSocket (/mp_wss/) do serwera nagrywającego. Szyfrowanie TLS kończy się w nginx; sam serwer WebSocket (srv/server.php) nasłuchuje wyłącznie na adresie pętli zwrotnej 127.0.0.1:8081 i otrzymuje stamtąd połączenie bez szyfrowania w obrębie tej samej maszyny. Serwer stosuje bramkę po raz drugi, niezależnie od przeglądarki: class/Server.class.php:977-1004 przepuszcza wyłącznie GRANTED lub GRANTED_LATE albo wyraźne zwolnienie regionalne, a zamyka połączenie kodem 1008 przy wycofaniu, nieznanym kraju i wszystkim, co niejasne. Wcześniej działa lista wykluczeń ścieżek, dopasowywana wyłącznie do ścieżki, a nie do pełnego adresu URL. Jeśli WebSocket trzykrotnie z rzędu nie zostanie nawiązany (serwer proxy lub zapora blokuje nawiązanie połączenia), skrypt wysyła te same wiadomości zamiast tego metodą HTTPS POST do /mp_wst; ten punkt końcowy niczego nie rozstrzyga i przekazuje je do tego samego procesu serwera, gdzie przechodzą przez tę samą bramkę (www/api/ws_tunnel.php, class/HttpTunnel.class.php). Zrzut strony większy niż 1 MB skrypt przesyła metodą HTTPS POST do /mp_dom (www/api/dom_upload.php); ten punkt końcowy sprawdza podpisany przez serwer, ograniczony w czasie dostęp, przechowuje zrzut w Redis najwyżej 120 sekund i niczego poza tym nie rozstrzyga - realizuje go to samo połączenie, które przeszło już przez bramki. Ponadto /mp_wsfail zlicza nieudane połączenia WebSocket według projektu, bez identyfikatora odwiedzającego; adres IP jest tam używany wyłącznie jako skrót do usuwania duplikatów i wygasa po godzinie. Zdarzenia kolejkowane są przez Redis i zapisywane przez długo działający proces roboczy (srv/db_worker.php) do MariaDB.

To, co jest przechowywane, nie jest nagraniem wideo. To sama strona: zserializowana kopia DOM z chwili odsłony wraz z każdą późniejszą jej zmianą, odtwarzana potem w ramce iframe z narysowanymi na wierzchu zarejestrowanymi pozycjami wskaźnika. To rozróżnienie ma znaczenie dla oceny ryzyka, ponieważ oznacza, że przechowywany materiał zawiera to, co zawierała strona - w tym tekst, którego odwiedzający nigdy nie wpisał i nigdy nie postrzegał jako "danych".

5.2 Rejestr operacji przetwarzania

Cel	Rola	Główne tabele	Usuwanie (stan na 23.09.2026)
Rejestrowanie zachowania: ruch, kliknięcia, przewijanie, dotknięcia, przełączanie kart	Podmiot przetwarzający	mouse_events (225892 wierszy, 322,6 MB), session_pageviews, visitor_sessions	Codzienne czyszczenie według taryfy, monitorowane (por. R7)
Treść strony: zrzut DOM i bieżące mutacje, aby odtworzyć stronę taką, jaką widziano	Podmiot przetwarzający	session_pageviews.payload_blob (1848 wierszy, 162,9 MB), mouse_events.target_selector dla mutacji (66153 wiersze)	To samo czyszczenie
Wpisy w formularzach, znak po znaku, maskowane zgodnie ze skonfigurowanym poziomem	Podmiot przetwarzający	mouse_events.target_selector dla zdarzeń input (599 wierszy)	To samo czyszczenie; co do 173 starych wierszy por. R2
Rozpoznawanie tego samego odwiedzającego między sesjami i odsłonami	Podmiot przetwarzający	visitor_sessions.visitor_id / custom_user_id, visitor_nicknames (329 wierszy)	visitor_nicknames: razem z ostatnią sesją odwiedzającego
Ustalanie sieci i przybliżonej lokalizacji	Podmiot przetwarzający	visitor_sessions.ip_address, country, city, asn_number, asn_org; ip_lifetime_stats (446 wierszy)	ip_lifetime_stats: 365 dni
Dowód zgody i jej zmian (art. 7 ust. 1)	Podmiot przetwarzający, przechowuje na potrzeby ciężaru dowodu klienta	consent_events (120 wierszy), visitor_sessions.consent_*	730 dni od wycofania zgody; do tego czasu celowo, bo to dowód, że zgoda została wycofana
Zdarzenia niestandardowe, sygnały frustracji, błędy JavaScript	Podmiot przetwarzający	session_custom_events (823), session_custom_event_params (1264)	To samo czyszczenie
Wyprowadzone cechy i maszynowo napisane narracje sesji	Podmiot przetwarzający	ai_session_features (4043), ai_timelines (3203 wiersze, 5,5 MB)	Razem z sesją, w tym samym łańcuchu usuwania
Prowadzenie własnych kont klientów MousePlayer	Administrator	users (4), user_ip_history (5), workspace_users, workspace_invites	Razem z kontem; nieaktywne konta po 24 miesiącach i doręczonym ostrzeżeniu
Logowanie dostępu, bezpieczeństwa i zmian w panelu	Administrator	mouseplayer_logs (36409), security_access_logs (1354), audit_logs (666), banned_ips	60 dni / 72 godzin / 60 dni / po wygaśnięciu
Zgłoszenia do wsparcia	Administrator	support_requests	730 dni
Współpraca nad nagraniem: komentarze i linki udostępniania	Mieszana - administrator wobec autora, podmiot przetwarzający wobec nagranej treści	session_comments (12), session_shares (9)	Komentarze razem z sesją; linki udostępniania 90 dni po wygaśnięciu
Akceptacja przez klienta regionalnych reguł nagrywania	Administrator	consent_region_acceptances (0 wierszy)	730 dni

5.3 Podstawa prawna

Dla wszystkiego, co znajduje się na ścieżce nagrywania, podstawą jest zgoda, a uzasadnienie jest udokumentowane w migracji, która wprowadziła architekturę zgody (ai/migrations/018_consent.sql): nagrywanie jest obserwacją zachowania w rozumieniu motywu 24 i dostępem do urządzenia końcowego w rozumieniu polskiej implementacji przepisów ePrivacy, wymaga zgody, a prawnie uzasadniony interes go nie uniesie. Wszystkie 7 projektów ma ustawienie consent_mode='required'. Wyłącznik awaryjny site_settings.consent_gate_active jest włączony. Ta analiza jest prawidłowa i nietypowo dobrze udokumentowana; nigdzie w kodzie nie jest łagodzona.

Dla czterech operacji kod nie wskazuje żadnej podstawy: prowadzenie własnych kont MousePlayer, logi dostępu i bezpieczeństwa panelu, zgłoszenia do wsparcia oraz komentarze do nagrań. Są to operacje w roli administratora. Prawnie uzasadniony interes (art. 6 ust. 1 lit. f) i wykonanie umowy (art. 6 ust. 1 lit. b) są oczywistymi kandydatami, ale kandydat to nie rozstrzygnięcie, a art. 6 ust. 1 lit. f wymaga udokumentowanego testu równowagi. Odpowiedziano 17.08.2026: dane konta i rozliczeń art. 6 ust. 1 lit. b, dla przechowywania faktur lit. c (pięć lat od końca roku kalendarzowego, w którym upłynął termin płatności podatku). Dzienniki dostępu, bezpieczeństwa i zmian oraz reCAPTCHA i dzienniki serwera: lit. f, cel obrona przed nadużyciami i rozliczalność; testy równowagi znajdują się w rejestrze w punktach B.2 i B.5. Demonstracja na stronie głównej: zgoda, lit. a. Zgłoszenia do wsparcia: lit. b, o ile zgłaszający jest klientem, a zgłoszenie dotyczy umowy, w przeciwnym razie lit. f (rejestr, B.3). Komentarze i linki udostępniania do nagrań MousePlayer przetwarza na polecenie klienta (rejestr, A.9).

5.4 Odbiorcy i transfery do państw trzecich

Wewnątrz ścieżki nagrywania nie znaleziono żadnego wychodzącego wywołania do jakiegokolwiek podmiotu trzeciego. Geolokalizacja rozwiązywana jest wobec lokalnych plików bazy MaxMind, a nie wobec usługi sieciowej - jest to świadoma decyzja projektowa odnotowana w kodzie, tak aby przed uzyskaniem zgody nie kontaktowano się z żadnym podmiotem trzecim. Czcionki, flagi i skrypty serwowane są lokalnie. To rzeczywiście dobry wynik i należy go tak nazwać.

Odbiorca	Co jest przekazywane	Stan dzisiaj
Klient	Wszystko, co zarejestrowano, przez panel i trzy punkty końcowe odtwarzacza	Aktywne - to jest cel
Dowolny posiadacz linku udostępniania, bez logowania	Pełne odtworzenie jednej sesji	Aktywne; stan na 16.10.2026: utworzono 5 linków udostępniania; każde otwarcie jest rejestrowane z czasem, adresem IP i identyfikatorem przeglądarki (share_views)
Google Cloud Storage, Warszawa (do 5 września 2026 r.: Google Drive, USA)	Codzienna pełna kopia każdej bazy danych i całego drzewa webowego. Do 11.08.2026 bez szyfrowania. Od 11.08.2026 szyfrowana na własnym serwerze przed przesłaniem	Aktywne codziennie. Przekazywanie tekstem jawnym zakończone 11.08.2026; nieszyfrowany zasób historyczny u Google został usunięty 12.08.2026. Od 5 września 2026 r. konto firmowe, region europe-central2 (Warszawa), objęte Warunkami przetwarzania danych Google Cloud; kopie na dawnym koncie Drive zostały usunięte 6 września 2026 r. - por. ryzyko R5
Stripe (USA / Irlandia)	E-mail klienta, nazwa, adres rozliczeniowy, dane płatnicze - żadnych danych odwiedzających	Wyłącznie klucze testowe; klucze produkcyjne puste
Namecheap Private Email (wysyłka poczty przez SMTP)	Adres odbiorcy, temat i treść wychodzących wiadomości do klientów i do operatora, np. potwierdzenie konta, reset hasła, zaproszenia, powiadomienia o logowaniu z nowego urządzenia, ostrzeżenie przed usunięciem nieaktywnych kont, powiadomienia o zmienionych dokumentach umownych, raport tygodniowy, odpowiedzi wsparcia, powiadomienia dotyczące oznaczeń i anomalii oraz komunikaty systemowe	Aktywne od 23.09.2026, nadawca office@mouseplayer.com; ujęte w wykazie podmiotów podprzetwarzających
Telegram (poza UE)	Do 11.08.2026: zgłoszenia do wsparcia w całości, w tym nieskrócony adres IP i pełna treść wiadomości. Od 11.08.2026: wyłącznie stałe zdanie "MousePlayer: es liegt eine neue Supportanfrage vor." - żadnej zmiennej, żadnego numeru sprawy, żadnego odnośnika; tym kanałem nie wychodzą już żadne dane osobowe	Kanał nadal aktywny (tokeny ustawione w .env), ale od 11.08.2026 nie jest odbiorcą danych osobowych, a tym samym nie jest podmiotem przetwarzającym
Google reCAPTCHA (USA)	Strony logowania, rejestracji, wsparcia i rozliczeń	Wyłączone w tym systemie (APP_ENV=dev); aktywne w produkcji
Google BigQuery (własny projekt klienta)	session_id, visitor_id, custom_user_id, ip_address, country, referrer, user agent, rozmiar ekranu, znaczniki czasu, typ urządzenia	Nieaktywne: wyłączone we wszystkich 7 projektach, a proces nie działa
Zdefiniowany przez klienta adres URL webhooka (cel nieograniczony)	Dane zdarzeń oraz bezpośredni link odtwarzacza do sesji	Nieaktywne: wyłączone we wszystkich 7 projektach, proces dyspozytora działa

5.5 Przechowywanie - zmierzone, a nie zamierzone

Automatyczna procedura usuwania istnieje i działa. Mieszka wewnątrz stale działającego procesu roboczego (srv/db_worker.php) i wykonuje się przy starcie procesu, a następnie raz na dzień kalendarzowy; terminy dla sesji oznaczonych jako boty ten sam proces realizuje co godzinę. Przebieg usuwania nie ma własnego wpisu w cronie. Jego brak nie pozostaje jednak niezauważony: proces roboczy zapisuje swój wynik, a srv/cron_status.php - inny proces - ocenia go, zgłasza pocztą elektroniczną przebieg sprzed ponad 48 godzin i rejestruje usterkę jako wpis w Urgent Logs obszaru administracyjnego. Pozostałe zaplanowane przebiegi znajdują się w /etc/cron.d/mouseplayer; niepowodzenia i zbyt długie przerwy tych przebiegów zgłasza ten sam proces statusu (stan na 16.10.2026).

W chwili pomiaru w sierpniu 2026 r. przebieg niczego jeszcze nie usunął: wszystkie projekty należały do właściciela w taryfie enterprise z okresem przechowywania 365 dni, a najstarsza sesja miała 20 dni. Według stanu na 16.10.2026 przebieg w udokumentowany sposób usuwa dane: działają terminy dla dzienników i danych pochodnych (najstarszy wpis w audit_logs znajduje się na granicy terminu 60 dni), sesje oznaczone jako boty są usuwane po 14 dniach, a ich nagrania opróżniane po własnym terminie (termin w dniach: 1). Termin taryfowy dla sesji ludzi nie objął dotąd żadnej sesji, ponieważ oba projekty z rzeczywistym ruchem odwiedzających nadal należą do właściciela w taryfie enterprise z 365 dniami, a ich najstarsze sesje pochodzą z 21.07.2026.

6. (b) Ocena niezbędności i proporcjonalności

Niezbędność i proporcjonalność ocenia się wobec deklarowanego celu: umożliwienia operatorowi witryny zrozumienia, jak odwiedzający korzystają z jego strony, gdzie napotykają trudności i dlaczego ją porzucają. Cel ten jest uprawniony, a ogólna technika jest zdolna mu służyć. Pytanie z art. 35 ust. 7 lit. b) jest węższe i trudniejsze: czy to przetwarzanie, na tym poziomie szczegółowości, jest niezbędne do tego celu - i czy ingerencja jest proporcjonalna do korzyści?

Element	Niezbędny do celu?	Proporcjonalny w obecnej postaci?
Ruch wskaźnika, kliknięcia, przewijanie, dotknięcia	Tak. To jest sygnał, o który w tym celu chodzi.	Tak.
Struktura i układ odwiedzanej strony	Tak. Współrzędne są bez sensu bez układu, do którego się odnoszą.	Co do zasady tak.
Pełna treść tekstowa strony, dosłownie	Nie - nie w ogólności. Zrozumienie, gdzie odwiedzający napotkał trudność, wymaga struktury i etykiet, a nie wyrenderowanej w nią treści osobowej.	Nie, w obecnej postaci. Maskowania trzeba zażądać dla każdego elementu z osobna; domyślnie zapisywane jest wszystko. Por. R1.
Wpisy w formularzach	Dyskusyjne. Wiedza, że pole zostało porzucone, jest cenna; wiedza, co w nie wpisano, rzadko jest niezbędna.	Częściowo. Dolna granica maskowania jest mocna i wszystkie projekty działają na najsurowszym poziomie - ale konstrukcja nadal dopuszcza słabsze poziomy, a etykietowanie tego ustawienia jest odwrócone (poziom 0 jest najsurowszy, a podpowiedź w panelu mówi coś przeciwnego).
Stan pól wyboru i przycisków opcji	Dyskusyjne.	Nie. Nigdy nie są maskowane na żadnym poziomie - a pole wyboru może nieść deklarację zdrowotną, przynależność polityczną albo zgodę na wrażliwy cel.
Rozpoznawanie między sesjami	Tak dla analizy powracających odwiedzających; nie dla celu podstawowego.	Warunkowo. Rozpoznawanie pseudonimowe jest proporcjonalne; identyfikator dostarczony przez klienta jest miejscem, w którym proporcjonalność się kończy. Por. R6.
Adres IP	Tak dla przybliżonego przypisania lokalizacji (kraj; miasto wyłącznie z już skróconego adresu) i obrony przed nadużyciami.	Tak, na przyszłość: adres jest skracany natychmiast po odczycie, zanim zobaczy go jakikolwiek odbiorca. Zasób historyczny w ścieżce nagrywania został uporządkowany 17.08.2026; por. R3.
Ocena punktowa i narracje sesji	Nie. To udogodnienia dla przepływu pracy klienta przy przeglądaniu.	Wątpliwe i jest to najsłabiej zbadana część systemu - nigdzie w kodzie nie wskazano dla niej podstawy prawnej.
Pełna kopia poza siedzibę (do 5 września 2026 r. do dostawcy z państwa trzeciego)	Kopia zapasowa poza siedzibą tak - służy dostępności (art. 32 ust. 1 lit. c). Jej zakres wykracza poza tę usługę: zawiera każdą bazę danych na maszynie.	Od 5 września 2026 r. tak, z zastrzeżeniem co do zakresu. Kopia jest szyfrowana przed przesłaniem i przechowywana w europejskim regionie na podstawie umowy z art. 28. Do 5 września 2026 r. nie: bez ustalonej umowy, a do 11.08.2026 bez szyfrowania. Por. R5.

W kwestii minimalizacji danych (art. 5 ust. 1 lit. c) system pokazuje dwie przeciwstawne twarze. Świadoma minimalizacja jest widoczna w kilku miejscach i dobrze uargumentowana w kodzie: nazwy pól są klasyfikowane, a nie przesyłane, ponieważ surowa nazwa pola w sklepie bywa na tyle mówiąca, by zidentyfikować osobę; ciąg TCF przechowywany jest wyłącznie jako skrót SHA-256; ładunek odtwarzania jest celowo wyłączony z publicznego API. Naprzeciw tego stoi centralna decyzja projektowa, by domyślnie zapisywać całą stronę dosłownie, co jest przeciwieństwem minimalizacji i czego żaden z powyższych środków nie równoważy.

W kwestii ograniczenia przechowywania (art. 5 ust. 1 lit. e) ocena była do 17.08.2026 jednoznaczna i niekorzystna. Trzynaście tabel zawierających dane osobowe nie miało żadnego okresu usuwania, w tym dwie zawierające najbardziej czytelny materiał: ai_timelines, która zawiera każdą sesję zapisaną jako czytelna proza, oraz visitor_nicknames. Procedura, która istniała, nigdy nie wykonała się na rzeczywistych danych. Koncepcja przechowywania, która nigdy nie usunęła żadnego rekordu, jest planem, a nie zabezpieczeniem. Od 17.08.2026 wszystkie trzynaście tabel ma okres usuwania, czyszczenie w mierzalny sposób usuwa dane, a jego brak jest zgłaszany (por. R7).

7. (c) Ocena ryzyka naruszenia praw i wolności osób, których dane dotyczą

Ryzyka ocenia się dla osoby, której dane dotyczą, a nie dla przedsiębiorstwa. Prawdopodobieństwo oceniane jest jako Odległe, Możliwe, Prawdopodobne albo Zmaterializowane - to ostatnie oznacza, że zdarzenie nie jest prognozą, lecz obecnym, zmierzonym stanem danych. Waga oceniana jest jako Ograniczona, Znacząca, Poważna albo Bardzo poważna, według tego, co dana osoba może stracić: nie zażenowanie, lecz ujawnienie zdrowia, sytuacji finansowej lub innych chronionych cech, utratę kontroli nad identyfikacją i niemożność wykonania przysługującego prawa.

ID	Ryzyko	Prawdopodobieństwo	Waga	Poziom
R1	Szczególne kategorie danych wewnątrz zarejestrowanej treści strony	Prawdopodobne	Bardzo poważna	Bardzo wysoki
R2	Niemaskowane wpisy formularzy w danych historycznych (173 wiersze) - ocena z pomiaru; wiersze usunięto 17.08.2026, ponowna ocena przez administratora pozostaje otwarta	Zmaterializowane	Znacząca	Wysoki
R3	Nieskrócone adresy IP w danych historycznych i logach panelu - ocena z pomiaru; zasób historyczny skrócono 17.08.2026, a logi panelu mają od tego czasu terminy, ponowna ocena pozostaje otwarta	Zmaterializowane	Znacząca	Wysoki
R4	Linki udostępniania ujawniają pełne nagranie bez jakiegokolwiek logowania	Możliwe	Poważna	Wysoki
R5	Codzienna pełna kopia poza siedzibę - do 11.08.2026 bez szyfrowania, od 11.08.2026 szyfrowana na własnym serwerze przed przesłaniem; nieszyfrowany zasób historyczny został u dostawcy usunięty 12.08.2026. Od 5 września 2026 r. kopia znajduje się w zasobniku Google Cloud Storage w regionie europe-central2 (Warszawa) na koncie firmowym, objęta Warunkami przetwarzania danych Google Cloud; kopie na dawnym koncie Drive zostały usunięte 6 września 2026 r. Zakres pozostaje bez zmian. Utrata obu plików kluczy czyni kopię bezpowrotnie nieodzyskiwalną; wydruki leżą w sejfie	Odległe (ponowna ocena 17.09.2026). Wcześniej: przekazywanie tekstem jawnym do 11.08.2026, przekazywanie bez ustalonej podstawy prawnej do 5 września 2026 r. - oba zmaterializowane i zakończone	Bardzo poważna	Średni - ponowna ocena 17.09.2026; do 5 września 2026 r. bardzo wysoki. Warunek z oceny (usunięcie starych skryptów) został spełniony 16.10.2026; ponowna ocena R5 należy do administratora
R6	Rozpoznawanie między sesjami i łączenie z własnymi rekordami klienta	Prawdopodobne	Poważna	Wysoki
R7	Brak okresu usuwania dla trzynastu tabel; usunięte od 17.08.2026, czyszczenie działa codziennie i jest monitorowane	Odległe (ponowna ocena 23.09.2026). Do 17.08.2026: zmaterializowane	Poważna	Niski - ponowna ocena 23.09.2026; do 17.08.2026 wysoki
R8	Zautomatyzowana ocena punktowa i klasyfikacja każdej sesji	Prawdopodobne	Znacząca	Średni
R9	92 sesje nieosiągalne żadnym identyfikatorem; brak drogi od osoby do rekordu - ocena z pomiaru; stan na 16.10.2026 brak takiej sesji, samoobsługowy wgląd od 17.08.2026, ponowna ocena pozostaje otwarta	Zmaterializowane	Znacząca	Wysoki
R10	Brak szyfrowania w spoczynku, brak TLS do bazy danych, Redis bez ochrony dostępu (do 16.08.2026; od tego czasu z ograniczonym dostępem, baza danych i Redis dodatkowo osiągalne w sieci lokalnej - ponowna ocena pozostaje otwarta)	Możliwe	Bardzo poważna	Średnio-wysoki
R11	Brak zapisu o tym, kto które nagranie oglądał	Zmaterializowane	Znacząca	Średnio-wysoki
R12	Jakość dowodu zgody; nieprzetestowane adaptery CMP	Zmaterializowane (dane deweloperskie)	Poważna	Średni
R13	Zgłoszenia do wsparcia do Telegrama wraz z nieskróconym IP - do 11.08.2026; od 11.08.2026 wychodzi już tylko stały komunikat bez żadnej zmiennej. Pozostaje lokalne przechowywanie zgłoszenia wraz z adresem e-mail i adresem IP w support_requests; od 17.08.2026 z okresem 730 dni (por. R7)	Przekazywanie: usunięte 11.08.2026. Przechowywanie lokalne: zmaterializowane	Znacząca - do 11.08.2026 dla przekazywania, od tej daty już tylko dla przechowywania lokalnego	Usunięte 11.08.2026 w zakresie przekazywania; pozostałe przechowywanie lokalne prowadzone jest w ramach R7 (tam: niski od 23.09.2026)
R14	Wyprowadzenie danych do odbiorców wybranych przez samego administratora — żądanie usunięcia do nich nie dociera	Możliwe (zależnie od tego, czy administrator włączy most; w bieżących danych: żaden nie jest włączony)	Istotna	Średnie

R1 - Szczególne kategorie danych wewnątrz zarejestrowanej treści strony

To najpoważniejsze ryzyko w systemie i zarazem najmniej widoczne, ponieważ nic w nim nie wygląda jak usterka. Maskowanie zrzutu strony działa wyłącznie wewnątrz oznaczonych obszarów (www/mp.js:3934-3970): wewnątrz elementu noszącego data-mp-mask lub klasę .mp-masked każdy znak niebędący białym znakiem jest zastępowany, a atrybuty spoza listy dozwolonych ustawiane są na [FILTERED]. Wszystko pozostałe zapisywane jest dosłownie. Maskowanie jest zatem adnotacją opt-in, którą klient musi nanieść, element po elemencie, na stronę, nad którą może nie mieć pełnej kontroli.

Skutkiem jest to, że ochrona obejmuje to, co odwiedzający wpisuje, a nie to, co strona mu odpowiada. Strona potwierdzenia z gabinetu lekarskiego pokazująca wizytę z nazwaną specjalizacją; koszyk w aptece; oferta ubezpieczeniowa wymieniająca choroby współistniejące; wyciąg bankowy; podsumowanie wniosku o pomoc prawną - wszystko to jest wyjściem strony, poza jakimkolwiek polem formularza, i wszystko to trafia do payload_blob w niezmienionej postaci. To nie jest hipoteza: 1848 wierszy jest wypełnionych, średnio po 90,3 kB, a próbka potwierdza, że przechowywana wartość zaczyna się od kompletnego dokumentu <html>. To samo dotyczy każdej późniejszej zmiany strony, serializowanej jako fragmenty HTML do mouse_events.target_selector w 66153 wierszach mutacji.

Prawdopodobieństwo - Prawdopodobne. Mechanizm ochronny wymaga świadomego działania kogoś innego niż osoba zagrożona, domyślnie zapisuje wszystko i nie ma żadnego wykrywania, żadnego ostrzeżenia ani żadnego raportu, który powiedziałby klientowi, że przechwytywana jest niemaskowana treść osobowa. Nic w systemie nie próbkuje zapisanego ładunku pod kątem wzorców, które by na to wskazywały. Prawdopodobieństwo, że co najmniej jedna strona klienta wyrenderuje dane szczególnej kategorii, jest bliskie jedności w każdym sensownym okresie działania.

Waga - Bardzo poważna. Dane z art. 9 ust. 1 korzystają z najwyższej ochrony, a żaden z wyjątków z art. 9 ust. 2 nie jest tu dostępny. Zgoda odwiedzającego na nagrywanie sesji nie jest wyraźną zgodą na przetwarzanie danych o zdrowiu i być nią nie może - ani odwiedzający, ani klient, ani MousePlayer nie wie w tym momencie, że takie dane są przechwytywane. Materiał zapisywany jest dosłownie, w pełni odtwarzalny, możliwy do wyeksportowania, objęty codzienną kopią poza siedzibę (R5) i możliwy do przekazania nieustalonej osobie trzeciej linkiem udostępniania (R4).

R2 - Niemaskowane wpisy formularzy w danych historycznych

173 wiersze w mouse_events zawierają wartości wpisane do formularzy otwartym tekstem. Zlokalizowano je dopasowaniem wzorca do zapisanej struktury ('"v":"' po którym następuje znak inny niż znak maskujący), przypadają na okres od 21 do 27 lipca 2026 i obejmują wpisy takie jak pełne imię i nazwisko osoby. Wiersze zapisane 10 sierpnia 2026 są maskowane, więc bieżące zachowanie jest już prawidłowe: wszystkie 7 projektów działa z smart_masking=0, co mimo etykiety jest najsurowszym ustawieniem i zastępuje każdy znak każdego pola, a bezwarunkowa dolna granica zastępuje hasła i dane płatnicze przy każdym ustawieniu.

Prawdopodobieństwo - Zmaterializowane. To nie jest prognoza. Wiersze istnieją teraz, a ponieważ mouse_events czyszczone jest wyłącznie przez czyszczenie taryfowe - które nie usuwa niczego, zanim rekord nie osiągnie 365 dni, i które nigdy się nie wykonało - pozostaną co najmniej do lipca 2027, o ile nie zostaną usunięte ręcznie. Prawdopodobieństwo ponownego wystąpienia na przyszłość jest niskie.

Waga - Znacząca. Znane próbki są nieszkodliwe, ale treść pozostałych wierszy nie została sklasyfikowana, a kategorie pól rozpoznawane przez system obejmują e-mail, telefon, płatność, adres i nazwisko. Nie ustalono, czy bezwarunkowa dolna granica dla haseł i danych płatniczych obowiązywała już w tamtym okresie. Wykonano 17.08.2026: wiersze zostały usunięte bez przeglądu (decyzja administratora). Pomiar wykazał 174 wiersze z 18 sesji jednego projektu, od 21.07 do 06.08.2026; po przebiegu pozostaje 0. Sama luka była już wcześniej zamknięta: od 07.08.2026 żadna wartość nie zawiera jawnego tekstu. Przy pomiarze omal drugi błąd: znakiem maskowania jest gwiazdka, a nie punktor - wzorzec na punktor znalazł 862 wiersze z najnowszym trafieniem z dzisiaj i wyglądał jak trwający wyciek. Usunięcie według tej liczby zabrałoby 688 poprawnie zamaskowanych wierszy.

R3 - Nieskrócone adresy IP w danych historycznych i logach panelu

Skracanie IP na ścieżce nagrywania jest zaimplementowane prawidłowo i we właściwym miejscu: class/Server.class.php:432-435 zastępuje ostatni oktet IPv4 albo ostatnią grupę IPv6 natychmiast po odczytaniu adresu, zanim pojawi się jakikolwiek odbiorca tej wartości. Zweryfikowano jego skuteczność dla nowych danych - każda sesja zarejestrowana od 7 sierpnia 2026 jest skrócona. Nie działa wstecz i nie istnieje żadna procedura uzupełniająca; zasób historyczny został zamiast tego uporządkowany jednorazowo, ręcznie, 17 sierpnia 2026 - por. notatkę o stanie pod tabelą.

Tabela	Nieskrócone adresy (stan z chwili oceny, przed 17.08.2026)	Okres usuwania
visitor_sessions	236 z 705, z okresu od 21 lipca do 7 sierpnia 2026, pełne adresy publiczne	Czyszczenie taryfowe - nigdy nie wykonane
ip_lifetime_stats	291 z 446	Nigdzie żaden
mouseplayer_logs	Żaden z 36542 sprawdzonych adresów nie był skrócony	60 dni
audit_logs	Wszystkie 666 wierszy	Brak
user_ip_history	Wszystkie 5 wierszy	Brak
security_access_logs	1004 z 1354	72 godziny
support_requests	Wszystkie, i przekazywane dalej - por. R13	Brak
Log dostępu Apache	Wszystkie	14 dziennych rotacji

Prawdopodobieństwo - Zmaterializowane. Waga - Znacząca. Sam adres IP to ograniczone ujawnienie. W visitor_sessions nie jest sam: znajduje się w tym samym wierszu co nagranie, łączy więc tożsamość sieciową, a przez nią osobę, z pełnym odtworzeniem jej zachowania - w tym z tym wszystkim, co obejmuje R1. Logi panelu są mniej dotkliwe, ale znacznie obszerniejsze i są przetwarzaniem w roli administratora, gdzie MousePlayer odpowiada za ten wybór bezpośrednio.

Wykonano 17.08.2026: adresy historyczne w audit_logs (681) i user_ip_history (7) zostały wstecznie skrócone, w tej samej formie, którą i tak zapisuje rejestrator; pozostaje 0. Przyszłe terminy obowiązują od tego samego dnia. (decyzja administratora, 17.08.2026)

Stan na 17.08.2026. Zasób historyczny w ścieżce nagrywania jest załatwiony: pomiar wykazał 267 z 267 skróconych adresów w ip_lifetime_stats i 881 z 901 w visitor_sessions; pozostałe 20 zawiera 0.0.0.0 i pochodzi z danych testowych analizy formularzy, nie są to więc adresy odwiedzających. W logach panelu pełny adres pozostaje - celowo, i od 17.08.2026 z wykazanym terminem: mouseplayer_logs 60 dni, security_access_logs 72 godzin, audit_logs 60 dni, user_ip_history 90 dni od ostatniego wystąpienia adresu (od 24.09.2026), support_requests 730 dni. Dlaczego pełny adres jest potrzebny przy zapytaniach do wsparcia, wyjaśnia rejestr z art. 30 w punkcie B.3.

R4 - Linki udostępniania ujawniają pełne nagranie bez jakiegokolwiek logowania

Reguła przepisywania kieruje /s/<40 znaków szesnastkowych> wprost do odtwarzacza. Token jest całą barierą, a projekt uczciwie to przyznaje: token to 20 bajtów z random_bytes (160 bitów, nie do odgadnięcia), identyfikatory kanału i sesji pochodzą wyłącznie z tokena, a nie z żądania, pozostały ciąg zapytania jest zastępowany, a nie ignorowany, rola pozostaje NULL, więc usunięcie i ponowne udostępnienie są po stronie serwera niemożliwe, wszystkie trzy punkty końcowe odtwarzacza są ograniczone do sesji z tokena, a tokeny wymyślone, wygasłe i odwołane dają identyczną odpowiedź, więc próbkowanie nic nie daje. Domyślny czas życia to 7 dni, minimum 1, maksimum 90; odwołanie istnieje. To starannie zbudowany mechanizm.

Ryzyko szczątkowe nie jest kryptograficzne, lecz ludzkie, a dwa szczegóły implementacji je poszerzają. Po pierwsze, strona pokazująca nagranie przez link udostępniania (player.php w trybie udostępniania) ma wprawdzie nagłówki Referrer-Policy: no-referrer i Cache-Control: no-store, ale nie ma nagłówka X-Robots-Tag; noindex występuje tylko w www/share.php, który jest już wyłącznie stroną błędu, a robots.txt zezwala na wszystko (sprawdzono 16.10.2026). Po drugie, od 17.08.2026 system rejestruje każde otwarcie linku udostępniania - czas, nieskrócony adres IP i identyfikator przeglądarki w share_views (por. też R11) -, nie da się jednak na tej podstawie ustalić osoby stojącej za otwarciem.

Prawdopodobieństwo - Możliwe. Token nie zostanie złamany siłowo. Zostanie przekazany dalej - wklejony do zgłoszenia, na czat grupowy, do wątku e-mailowego, który zyskuje kolejnego adresata - i może wyciec przez nagłówek Referer. Waga - Poważna: jeden link ujawnia całą sesję nieograniczonej, nieustalonej publiczności, w tym wszystko objęte R1 i R2, a potem da się ustalić jedynie, z jakiego adresu i z jakiej przeglądarki ją otwarto (share_views), ale nie, kto ją widział. Powiązane pytanie jest odnotowane jako otwarte we własnych notatkach projektu i pozostaje niezweryfikowane: Pomiar z 17.08.2026: limit obserwatorów nie jest omijany przez linki udostępniania - w ogóle ich nie dotyczy. Obserwatorzy na żywo liczeni są przez znacznik IS_LIVE_VIEWER na połączeniu WebSocket (class/Server.class.php, zaehleLiveViewers). www/player.php nie zawiera ani jednego miejsca z WebSocket; odtwarzacz jedynie odtwarza. Link udostępniania prowadzi do odtwarzacza, a nie do podglądu na żywo. Nieograniczone jest co innego: ile osób otworzy ten sam link jednocześnie. Na to nie ma limitu ani - inaczej niż przy podglądzie na żywo - licznika. Od 17.08.2026 każde otwarcie jest przynajmniej rejestrowane (share_views, rejestr B.6), więc można później ustalić, jak często i skąd link był używany.

R5 - Codzienna pełna kopia poza siedzibę (do 5 września 2026 r. do Google Drive, od tego dnia do Google Cloud Storage w Warszawie; od 11.08.2026 przesyłana z szyfrowaniem; zasób historyczny usunięty 12.08.2026)

Tego ryzyka nie ma w technicznej podstawie faktycznej; ustalono je z własnego pliku otwartych punktów projektu, gdzie jest szczegółowo udokumentowane. Do 11.08.2026 wcześniejszy skrypt kopii zapasowej uruchamiany był z crona roota codziennie o 02:00. Wykonywał mysqldump na wszystkich bazach danych i pakował tarem całe drzewo webowe, a następnie wysyłał wynik przez rclone do gdrive:backups/rpi-ls5/daily - bez jakiegokolwiek szyfrowania. Lokalnie potwierdzono 653 MB bazy danych i 678 MB plików dziennie. Od 11.08.2026 linia crona jest przestawiona: codzienny przebieg to nowy skrypt kopii zapasowej trzymany w projekcie, który zabezpiecza ten sam zakres, ale szyfruje go na własnym serwerze przed przesłaniem (rclone crypt) i wysyła do osobnego, własnego katalogu docelowego; planowo odbywa się o 03:00. Zaszyfrowane są także nazwy plików i katalogów, u dostawcy leżą więc bloki bez znaczenia. Przebieg z 11.08.2026 uruchomiono ręcznie i dotarł (733 MB bazy danych, 678 MB plików); przebieg z 12.08.2026 wykonał się planowo o 03:00 w całości. Oba są zaprotokołowane, a kontrola po stronie docelowej za każdym razem odnalazła tam zrzut bazy z tą samą liczbą bajtów.

To, co opuszcza maszynę, nie jest zatem kopią zapasową nagrań sesji. Jest pełną kopią każdej bazy danych i każdego systemu na hoście - łącznie z nagraniami i ich zrzutami DOM, 173 wpisami formularzy otwartym tekstem, 236 nieskróconymi adresami i każdym plikiem .env z jego produkcyjnymi sekretami. Zakres pozostaje bez zmian; szyfrowanie tego nie zmienia. Zmieniła się czytelność u dostawcy: do 11.08.2026 przed wysyłką nie było żadnej warstwy szyfrowania i tekst jawny docierał jako tekst jawny; od 11.08.2026 szyfrowanie odbywa się na własnym serwerze, zanim cokolwiek wyjdzie, a klucze leżą w dwóch plikach z prawami 600 na tym samym serwerze - Google ich nie ma. Zasób historyczny nie był tym objęty: nowy skrypt sprząta wyłącznie własny katalog docelowy, a dotychczasowy katalog trzymał kopie tygodniowe do 364 dni. Został usunięty 12.08.2026; nieszyfrowanych pełnych kopii sprzed 11.08.2026 u dostawcy już zatem nie ma.

• Transfer jest rzeczywisty i codzienny. Do 11.08.2026 nie było zweryfikowane, czy dociera: przebieg korzystał z konfiguracji rclone roota, skrypt niczego nie logował, a cron odrzucał jego wyjście. Od 11.08.2026 przebieg zapisuje protokół i po przesłaniu sam sprawdza, czy zrzut bazy stoi w miejscu docelowym z oczekiwaną liczbą bajtów; dla 11.08.2026 (ręcznie) i dla 12.08.2026 (planowo, o 03:00) udokumentowane jest jedno i drugie, za każdym razem z zaliczoną kontrolą. Wykazana jest tym samym codzienna praca, a nie tylko pierwsza próba. Nie zamyka to ryzyka dostępności, lecz je przesuwa: utrata obu plików kluczy czyni całą kopię poza siedzibą bezpowrotnie nieodzyskiwalną. Środek, który usuwa czytelność u dostawcy, tworzy tym samym nową zależność od przechowywania kluczy; poza tą maszyną leżą, według oświadczenia administratora, w formie wydruku w sejfie (sekcja 8.3). Właściciel sprawdził odszyfrowanie - to jego oświadczenie, a nie pomiar niniejszego dokumentu.
• Do 5 września 2026 r. nie ustalono żadnego instrumentu transferu. Kopia znajdowała się w Google Drive na koncie prywatnym (odpowiedziano 17.08.2026), bez możliwości wykupienia europejskiego regionu danych i bez umowy powierzenia. Od 5 września 2026 r. znajduje się w zasobniku Google Cloud Storage w regionie europe-central2 (Warszawa) na koncie firmowym i jest objęta Warunkami przetwarzania danych Google Cloud; kopie na koncie Drive zostały usunięte 6 września 2026 r.
• Stary skrypt był eskalacją uprawnień. Do 11.08.2026 należał do roota, wykonywany był przez crona roota, a jego prawa dostępu wynosiły 777: każdy, kto miał konto SSH pi, miał o 02:00 uprawnienia roota. Od 11.08.2026 codzienny przebieg nie idzie już przez ten skrypt; przesyłanie do Google Drive zostało z niego usunięte 9 września 2026 r. Stare skrypty kopii zapasowej zostały usunięte 16.10.2026 r. Ponowna ocena R5 należy do administratora.
• Do 5 września 2026 r. kopia wykraczała poza jakiekolwiek polecenie klienta. Art. 28 ust. 3 lit. a wymaga, by podmiot przetwarzający działał wyłącznie na udokumentowane polecenie; codzienna kopia nagrań odwiedzających klienta do amerykańskiej konsumenckiej usługi chmurowej nie była objęta żadnym udokumentowanym poleceniem. Od tego czasu kopię zapasową w Google Cloud Storage wymieniają sekcja 9 umowy powierzenia i wykaz podmiotów podprzetwarzających.

Nieaktualne od 5 września 2026 r. (zob. wyżej); pozostawione jako historia. Odpowiedziano 17.08.2026: konto prywatne. Nie da się więc wykupić europejskiego regionu danych i nie ma umowy powierzenia przetwarzania - dla prywatnego konta Google warunki przetwarzania danych nie są dostępne. Decyzja administratora: kopia pozostaje na razie tam. Testy odtworzenia odtąd miesięcznie. Oba pliki kluczy przechowywane są w formie wydruku w sejfie dostępnym wyłącznie administratorowi (oświadczenie administratora, 17.08.2026); przetrwają więc utratę tej maszyny.

Pomiar z 17.09.2026: ostatnia udana kopia zapasowa została wykonana tego dnia o 03:30 i przeszła kontrolę w miejscu docelowym. Próba odtworzenia przewidziana jest co miesiąc; została zdana przed usunięciem kopii z Drive 6 września 2026 r., a o następnej nie przypomina żaden mechanizm nadzoru. 7 października 2026 r. przeprowadzono dodatkowo pełne odtworzenie danych z kopii w chmurze do odrębnego środowiska (około 70 minut; próbki z archiwum i bazy danych bez błędów). Od 6 października 2026 r. codzienna kopia zapasowa obejmuje także archiwum nagrań (/mnt/mouseplayer-dev-archive); znajduje się ono na tym samym dysku co system. O ile nie zaznaczono tam inaczej, wyliczenie powyżej opisuje stan sprzed 5 września 2026 r.

R6 - Rozpoznawanie między sesjami i łączenie z własnymi rekordami klienta

Pseudonimowy identyfikator jest tworzony i trzymany w localStorage odwiedzającego jako mp_visitor_id. Sam w sobie jest zwyczajny i proporcjonalny dla analizy powracających odwiedzających. Dwa kolejne mechanizmy zmieniają jego charakter. MousePlayer.setUserId() pozwala klientowi dołączyć własny identyfikator - login, numer klienta - do nagrania, zapisywany w visitor_sessions.custom_user_id z dedykowanym indeksem; a ta sama wartość pobierana jest automatycznie ze ścieżki dataLayer o nazwie 'uid', bez żadnego świadomego działania klienta. Tam, gdzie menedżer tagów już publikuje identyfikator użytkownika, nagrania stają się przypisywalne do wskazanej osoby jako efekt uboczny instalacji.

Od tego momentu nagranie nie jest już pseudonimowe w rękach klienta. Da się je połączyć z jego CRM, a eksport do BigQuery zbudowany jest tak, by nieść dokładnie te kolumny, które czynią to połączenie trywialnym: visitor_id, custom_user_id i ip_address w tym samym wierszu. Eksport ten jest obecnie wyłączony we wszystkich projektach, a jego proces nie działa - zdolność istnieje, aktywność nie.

Jedną słabość konstrukcyjną należy odnotować bez wyolbrzymiania. visitor_nicknames ma ograniczenie UNIQUE wyłącznie na visitor_id, bez granicy najemcy - tabela jest strukturalnie międzyprojektowa. W praktyce identyfikator żyje w localStorage i jest tym samym ograniczony do jednego origin, więc samo w sobie nie tworzy to śledzenia międzywitrynowego pomiędzy domenami różnych klientów. Jest to brakująca granica w schemacie, a nie wykazany wyciek, i należy ją domknąć przed jakimkolwiek wdrożeniem, w którym dwa projekty mogłyby dzielić ten sam origin.

Prawdopodobieństwo - Prawdopodobne dla rozpoznawania między sesjami (jest to zachowanie domyślne, a zarejestrowano 329 identyfikatorów); Możliwe do Prawdopodobnego dla identyfikacji, wobec automatycznej ścieżki dataLayer. Waga - Poważna: identyfikacja usuwa czynnik łagodzący, który czyni rejestrowanie zachowania znośnym, i robi to z mocą wsteczną - gdy identyfikator zostanie dołączony, wcześniejsze pseudonimowe sesje tego odwiedzającego również stają się przypisywalne.

R7 - Brak okresu usuwania dla trzynastu tabel; terminy ustalone 17.08.2026

Czyszczenie uwzględniające taryfę usuwa pięć tabel: mouse_events, session_custom_event_params, session_custom_events, session_pageviews i visitor_sessions. Trzynaście tabel zawierających dane osobowe jest poza tą listą: ai_session_features, ai_timelines, consent_events, session_comments, session_shares, visitor_nicknames, ip_lifetime_stats, audit_logs, user_ip_history, users wraz z last_ip, support_requests, consent_region_acceptances i heatmap_page_stats.

Praktyczna konsekwencja jest gorsza, niż sugeruje sama lista, ze względu na kolejność zdarzeń. Gdy czyszczenie w końcu zadziała, sesja zniknie, a pochodne pozostaną - ai_timelines zachowałaby sesję jako czytelną prozę, 3203 wiersze i 5,5 MB tekstu, opisujące osobę, której rekord źródłowy został usunięty. Dziś nie ma takich sierot, ale wyłącznie dlatego, że nigdy nic nie zostało usunięte.

Nakładają się na to trzy dalsze usterki. Procedura nie jest planowana przez crona ani systemd, lecz działa wewnątrz procesu roboczego, więc jeśli ten proces się zatrzyma, usuwanie się zatrzymuje i nic tego nie zgłasza. Jej zapytanie wybierające łączy sesje z projektami, przestrzeniami roboczymi, właścicielami i użytkownikami złączeniami wewnętrznymi, więc sesja, której projekt usunięto, nigdy nie zostanie wybrana i nigdy nie zostanie usunięta - jedna z 706 sesji jest już w tym stanie. A okres przechowywania faktycznie obowiązujący to 365 dni dla każdego projektu w systemie, wobec zbioru danych, którego najstarszy rekord ma 20 dni, co oznacza, że łańcuch usuwania nigdy nie został przećwiczony od początku do końca.

Prawdopodobieństwo - Zmaterializowane. Waga - Poważna, jako naruszenie art. 5 ust. 1 lit. e mające charakter strukturalny, a nie przypadkowy. Zmienione 17.08.2026. Sam przebieg pozostaje w db_worker, ale jego BRAK jest teraz zauważalny: worker zapisuje swój wynik (mp_purge_status), a srv/cron_status.php - INNY proces - ocenia go co 60 sekund, zapisuje sys_purge dla panelu administracyjnego i zgłasza e-mailem, gdy ostatni przebieg jest starszy niż 48 godzin. Najwyżej jedna wiadomość dziennie; strażnik wysyłający co minutę zostaje zignorowany i wtedy nie zgłasza nikomu także prawdziwej awarii. Strażnik celowo nie siedzi w workerze: martwy proces nie może zgłosić samego siebie. Stan na 23.09.2026: wysyłka e-mail działa; powiadomienie trafia na adres alarmowy ustawiony w panelu administracyjnym.

Stan na 17.08.2026. Usunięte. Pięć z trzynastu tabel od 12.08.2026 należy do wspólnego łańcucha usuwania, sześć otrzymało własny termin konfigurowalny w panelu administracyjnym (migracja 039), a dwóch na liście w ogóle nie było: ai_visitor_value i ai_insights - czyli właśnie ocena osoby i wygenerowany o niej tekst. Terminy znajdują się w site_settings i są odczytywane z tego samego wiersza, z którego bierze je do swojego tekstu rejestr z art. 30. Proces usuwania działa; przebieg z 17.08.2026 o 17:37:09 jest udokumentowany w dzienniku procesu roboczego. Obawa z tej sekcji - sesja znika, a wyliczenie zostaje jako sierota - nie może już wystąpić. Przebieg nadal zależy od procesu roboczego i nie planuje go ani cron, ani systemd; jego brak od 17.08.2026 zgłasza strażnik w procesie statusu, a od 23.09.2026 także e-mailem.

Ponowna ocena 23.09.2026. Zmierzone tego samego dnia: czyszczenie działało ostatnio 21 godzin wcześniej, najstarszy wpis w audit_logs ma 60 dni - dokładnie ustawiony okres - i żadna sesja nie pozostaje bez projektu. Wybór nadal łączy tabele złączeniami wewnętrznymi; osierocone sesje mimo to nie powstają, ponieważ usunięcie projektu lub konta zabiera jego sesje według channelid. Od 24.09.2026 również user_ip_history ma własny okres: 90 dni od ostatniego wystąpienia adresu, najpóźniej wraz z kontem. Prawdopodobieństwo - Odległe. Waga - Poważna. Poziom łączny - niski.

R8 - Zautomatyzowana ocena punktowa i klasyfikacja każdej sesji

Każda sesja jest oceniana automatycznie. engagement_score (0-255) wyliczany jest z sygnałów głębokości i sygnałów irytacji; session_quality oddziela sesje, w których niewiele się wydarzyło; is_bot wraz z kodem przyczyny klasyfikuje odwiedzającego jako nie-człowieka, a ta kontrola działa przed bramką zgody. Oceny są indeksowane i sterują kolejnością listy przeglądowej klienta, co oznacza, że decydują o tym, które osoby zostaną obejrzane. W chwili pomiaru w sierpniu 2026 r. istniały 4043 wiersze cech i 3203 wygenerowane narracje.

Jest to profilowanie w rozumieniu art. 4 pkt 11 - zautomatyzowana ocena czynników osobowych dotyczących osoby fizycznej, w szczególności do analizy lub prognozy jej zachowania. Na podstawie dowodów nie jest to zautomatyzowane podejmowanie decyzji w rozumieniu art. 22: nie znaleziono żadnej decyzji kredytowej, cenowej, dostępowej ani kwalifikacyjnej wobec odwiedzającego. Jeden mechanizm stoi bliżej tej granicy niż pozostałe i należy go nazwać: po wykryciu rage click www/mp.js przekazuje behawioralny werdykt do zewnętrznych widgetów czatu działających w przeglądarce samego odwiedzającego - Intercom otrzymuje flagę, LiveChat zmienną sesyjną. Osąd sformułowany o odwiedzającym opuszcza tym samym system w czasie rzeczywistym i może zmienić sposób, w jaki ta osoba jest traktowana w witrynie.

Zakres profilowania, stan na 16.10.2026. Od czasu pomiaru doszły dalsze oceny i dane pochodne i wszystkie należą do tego ryzyka: maszynowo formułowane zdania i raporty o poszczególnych odwiedzających (ai_insights, ai_besucher_bericht; ustalenia są wyliczane, a model językowy na własnych komputerach w tej samej sieci lokalnej je formułuje); model porzucenia (regresja logistyczna), który w przeglądarce odwiedzającego szacuje ryzyko opuszczenia strony i - jeżeli operator go włączy - uruchamia ofertę przy wyjściu, której tekst jest wyświetlany dopiero po zatwierdzeniu przez operatora; regułowy wskaźnik odejścia dla powracających odwiedzających (ai_churn); profile zachowań grupujące sesje według ich przebiegu (k-średnich, mp_profile, mp_profil_sitzung) oraz wzorce sekwencji; wskaźnik tarcia dla każdej sesji; ankiety i przycisk opinii z odpowiedziami odwiedzającego; śledzenie elementów, które przypisuje kliknięcia oznaczonym elementom; indeks wyświetlanych tekstów do wyszukiwania (mp_text_block, mp_text_pv, 30 dni); oraz komunikaty konsoli i nieudane lub powolne żądania strony klienta (bez treści i nagłówków). Według ustaleń żadne z nich nie podejmuje wobec odwiedzającego decyzji w rozumieniu art. 22; oferta przy wyjściu bezpośrednio zmienia jednak to, co odwiedzający widzi na stronie, i dlatego spośród wymienionych stoi najbliżej tej granicy. Szczegóły zawiera rejestr na podstawie art. 30.

Odrębnie, dwie zautomatyzowane konsekwencje mają realny skutek, ale wobec klientów i adresów IP, a nie wobec odwiedzających: konto automatycznie oznaczone jako is_suspicious przy rejestracji ma skrócony okres przechowywania danych do 24 godzin, a adres IP przekraczający progi liczby połączeń jest blokowany, po czym każde kolejne żądanie jest przerywane - w chwili pomiaru w sierpniu 2026 r. odnotowano 24 takie blokady. W chwili pomiaru żadna z nich nie miała udokumentowanej ścieżki przeglądu przez człowieka ani kanału sprzeciwu; dla blokady istnieje ona od 17.08.2026 (poniżej), dla flagi is_suspicious nadal nie.

Prawdopodobieństwo - Prawdopodobne (zachowanie domyślne). Waga - Znacząca: brak skutku prawnego wobec odwiedzających, ale bycie ocenianym i rankingowanym bez własnej wiedzy oraz przekazanie tej oceny do widgetu podmiotu trzeciego jest dokładnie tą utratą kontroli, którą opisuje motyw 75. Ocenione 17.08.2026. Od tego dnia automatyczna blokada wygasała sama po 7 dniach; wcześniej nie wygasała nigdy. Stan na 16.10.2026: serwer WebSocket blokuje sam, a blokada wygasa po 24 h (konfigurowalne od 1 do 168 h); fail2ban blokuje na godzinę; banned_ips jest uzupełniana już tylko ręcznie. Sprzeciw można złożyć przez formularz wsparcia lub na adres office@mouseplayer.com i rozpatruje go człowiek; panel administracyjny może blokadę zdjąć. Czas trwania znajduje się w site_settings (autoban_stunden). Środek ma więc ograniczony skutek, kontrolę człowieka na żądanie i wskazaną drogę do niej - cechy, na których opiera się art. 22. Sama kwalifikacja pozostaje kwestią prawną; rozstrzygnięto zabezpieczenie, nie wykładnię. (decyzja administratora, 17.08.2026)

R9 - 92 sesje nieosiągalne żadnym identyfikatorem; brak drogi od osoby do jej rekordu

92 sesje noszą visitor_id 'unknown'. Dla tych rekordów nie istnieje żaden klucz, który by do nich prowadził: dane istnieją, są danymi osobowymi, zawierają nagranie i być może adres, a nie da się ich pobrać żadnym zapytaniem, które mogłoby uruchomić żądanie osoby, której dane dotyczą. Usunięcia na podstawie art. 17 nie da się dla nich wykonać, a dostępu z art. 15 nie da się udzielić. Zmierzono ponownie 16.10.2026: żadna sesja nie nosi już visitor_id 'unknown'; kod nadal może jednak zapisać tę wartość przy zakładaniu sesji.

Szerszy problem jest gorszy niż te 92 wiersze i jest już odnotowany jako nierozwiązany we własnych notatkach projektu. Nawet tam, gdzie visitor_id istnieje, żyje on w localStorage odwiedzającego, a człowiek go nie zna. Nie ma drogi od realnej osoby - która może podać imię i nazwisko, adres e-mail, datę i stronę - do jej rekordów. Przycisk usuwania, do którego nie może dotrzeć osoba uprawniona do jego naciśnięcia, jest atrapą.

Art. 11 daje częściową i niewygodną odpowiedź: jeżeli administrator może wykazać, że nie jest w stanie zidentyfikować osoby, której dane dotyczą, art. 15-20 nie mają zastosowania - ale art. 11 ust. 2 wymaga, by administrator o tym poinformował, a osoba, której dane dotyczą, może dostarczyć dodatkowych informacji pozwalających ją zidentyfikować. Ta ostatnia klauzula jest sednem: odwiedzający może podać swój identyfikator, ponieważ leży on w jego własnej przeglądarce. Strona samoobsługowa, która pokazywałaby odwiedzającemu jego własne mp_visitor_id, zamieniłaby żądanie niemożliwe do wykonania w rutynowe, co sprawia, że powoływanie się na art. 11 jest trudne do obrony, dopóki takiej strony nie ma.

Prawdopodobieństwo - Zmaterializowane. Waga - Znacząca, rosnąca do Poważnej w połączeniu z R1: osobą najmniej zdolną dotrzeć do swojego rekordu jest osoba, która nie wie, że taki rekord istnieje. Postanowiono 17.08.2026: zostanie uruchomiona samoobsługowa informacja dla odwiedzających - strona, na której odwiedzający widzi własny identyfikator i może uruchomić usunięcie swoich nagrań, podlinkowana z polityki prywatności. (decyzja administratora, 17.08.2026) Działa od 17.08.2026 pod adresem /moje-dane (niemiecki /meine-daten, angielski /my-data), podlinkowana ze stopki każdej strony. Pokazuje liczbę sesji, okres oraz objęte domeny — bez nagrań: identyfikator jest kluczem na okaziciela, a kto go zna, mógłby inaczej oglądać cudze zachowanie. Usunięcie jest kolejkowane i wykonywane przez proces roboczy istniejącym łańcuchem; sama strona nie usuwa.

Na ile rozbraja to R9, zależy od tego, gdzie odwiedzający został nagrany, a granica ta jest natury technicznej: pamięć przeglądarki jest oddzielona dla każdego źródła. Identyfikator leży w pamięci tej witryny, na której działał skrypt, a nie w naszej. Strona na mouseplayer.com nie może go więc sama zobaczyć — sprawdzone na danych, gdzie żaden identyfikator nie występuje na więcej niż jednej domenie. Wynikają z tego trzy drogi:

• Odwiedzający samą mouseplayer.com docierają do swoich danych bezpośrednio, bo tutaj pamięć przeglądarki jest nasza. Dla nich R9 zostaje zniesione.
• Odwiedzający witrynę klienta docierają do nich przez link, który klient umieszcza we własnej polityce prywatności; MousePlayer.privacyUrl() zwraca go gotowego, wraz z identyfikatorem. To nie wykręt, lecz podział ról z art. 28: wobec swoich odwiedzających administratorem jest klient, a informacja z art. 13 i tak należy do jego polityki. My dostarczamy narzędzie i jesteśmy odbiorcą.
• Kto już zna swój identyfikator, wpisuje go na stronie.

Jeśli klient nie umieści linku, R9 pozostaje dla jego odwiedzających w pełnej wysokości — żądanie nie jest wtedy niemożliwe, ale biegnie przez klienta, a nie przez nas, i na ten przypadek w polityce prywatności stoi stwierdzenie z art. 11. Kto wyczyścił pamięć przeglądarki, nie jest osiągalny żadną z trzech dróg. Strona zatem nie znosi R9; przesuwa je z „technicznie niewykonalnego” na „wykonalne, o ile administrator wskaże drogę”.

R10 - Brak szyfrowania w spoczynku, brak TLS do bazy danych i do Redis w sieci LAN

Trzy luki infrastrukturalne są udokumentowane jako niewdrożone i zostały zweryfikowane, a nie przyjęte. Szyfrowanie tabel InnoDB, logu i tabel tymczasowych jest wyłączone, a dysk nie jest zaszyfrowany, więc cały zbiór - 322,6 MB zdarzeń i 162,9 MB zrzutów stron - spoczywa w postaci jawnej. Połączenie z bazą danych działa bez TLS: serwer je obsługuje, ale nie skonfigurowano certyfikatu, klucza ani CA; połączenie jest lokalne, co łagodzi, lecz nie usuwa problemu. Do 16.08.2026 Redis działał bez ochrony dostępu, zapisując przy tym na dysk, a jego kolejki niosą skrócone IP, pełny adres URL i ładunek DOM w tranzycie.

Prawdopodobieństwo - Możliwe. Zdalne wykorzystanie jest mało prawdopodobne: w chwili pomiaru Redis i baza danych nasłuchiwały wyłącznie na localhost (stan obecny - zob. niżej), HTTPS jest wymuszony, a połączenie TLS WebSocketu kończy się z prawdziwym certyfikatem w nginx. Realistyczne ścieżki są fizyczne - kradzież maszyny, utylizacja dysku - oraz ścieżka kopii zapasowej z R5, która do 11.08.2026 co noc wynosiła ten sam tekst jawny poza maszynę, a od 11.08.2026 przesyła z szyfrowaniem; nieszyfrowane kopie sprzed tej daty zostały u dostawcy usunięte 12.08.2026. Waga - Bardzo poważna w razie realizacji, ponieważ ujawnia się wszystko naraz.

Odpowiedziano 17.08.2026: serwer stoi w zamykanym pomieszczeniu objetym monitoringiem w Lodzi; dostep ma wylacznie administrator. Dysk USB z kopia lezy w tym samym pomieszczeniu co serwer. Odpowiedziano 17.08.2026: szyfrowanie w spoczynku nie zostanie wprowadzone przed uruchomieniem produkcyjnym - w fazie poczatkowej na Raspberry Pi jest niewykonalne (decyzja administratora). Ryzyko pozostaje wiec w pelnej wysokosci: caly zasob lezy jawnym tekstem na dysku, a dysk USB z kopia znajduje sie w tym samym pomieszczeniu. Pozostale zabezpieczenie jest fizyczne - zamykane pomieszczenie objete monitoringiem, dostep wylacznie administratora - i chroni przed kradzieza lub niewlasciwa utylizacja nosnika tylko na tyle, na ile wytrzyma to pomieszczenie. Do ponownej oceny, gdy tylko eksploatacja opusci Raspberry Pi.

Stan na 17.08.2026. Część została usunięta, część się przesunęła. Redis od 16.08.2026 ma ograniczony dostęp; sprawdzone - bez uwierzytelnienia usługa odrzuca zapytania. Szyfrowanie w spoczynku nadal nie istnieje. Łagodzące założenie tej sekcji przestało jednak obowiązywać: od 16.08.2026 Redis i baza danych nie nasłuchują już wyłącznie na localhost, lecz dodatkowo na adresie LAN (bind-address = 127.0.0.1,192.168.20.2), aby drugi węzeł mógł sięgnąć do wspólnego stanu; wiersze ssl- w konfiguracji serwera pozostają zakomentowane. Dopóki działa jeden węzeł, pozostaje to teoretyczne. Wraz z drugim treść sesji i ruch bazy danych wędrują przez sieć jawnym tekstem, a drogi ataku przestają być wyłącznie fizyczne. Ocenę tego ryzyka należy ustalić na nowo przed uruchomieniem drugiego węzła.

Stan na 16.10.2026. Połączenia z internetu są szyfrowane TLS; szyfrowanie kończy się w nginx, a serwer WebSocket nasłuchuje wyłącznie na 127.0.0.1:8081, czyli na tej samej maszynie. MousePlayer korzysta z własnej instancji Redis na 127.0.0.1:6381 z ograniczonym dostępem i zapisem na dysk (plik append-only); na dysk trafiają więc także zawartość kolejek oraz nieskrócone adresy IP przechowywane przez czas trwania automatycznej blokady (24 h). Starsza, wspólnie używana instancja Redis nasłuchuje z ograniczonym dostępem dodatkowo na adresie LAN. MariaDB nasłuchuje na 127.0.0.1 i na adresie LAN 192.168.20.2 bez TLS (nie skonfigurowano certyfikatu) i istnieją połączenia z sieci lokalnej. W obrębie własnej sieci lokalnej w tej samej lokalizacji połączenia z bazą danych i Redis przebiegają więc bez szyfrowania; mają ograniczony dostęp i są osiągalne wyłącznie z własnej sieci lokalnej (brak przekierowania portów). Szyfrowanie w spoczynku nadal nie istnieje.

R11 - Brak zapisu o tym, kto które nagranie oglądał

Dziennik zmian rejestruje działania zapisujące - utworzenie i odwołanie udostępnienia, usunięcie komentarza, usunięcie sesji i odwiedzającego, automatyczne blokady, działania superadmina, łącznie 666 wpisów w chwili pomiaru. Nie rejestruje odczytu. Wywołanie strony odtwarzacza, punktu końcowego zdarzeń ani punktu końcowego theatre nie zostawia śladu. Nikt nie jest w stanie ustalić po fakcie, który pracownik klienta oglądał sesję wskazanej osoby, jak często ani czy robił to administrator MousePlayer. Od 17.08.2026 rejestrowane są przynajmniej otwarcia linków udostępniania (share_views); wywołania przez zalogowanych użytkowników nie zostawiają śladu (stan na 16.10.2026).

Prawdopodobieństwo - Zmaterializowane jako luka w kontroli. Waga - Znacząca, z efektem wtórnym, który ma większe znaczenie niż bezpośredni: po jakimkolwiek incydencie art. 33 i art. 34 wymagają od administratora opisania kategorii i przybliżonej liczby osób, których dane dotyczą, oraz rekordów, których dotyczy naruszenie. Bez logowania odczytu takiego opisu nie da się sporządzić na podstawie dowodów, a każde zgłoszenie staje się szacunkiem.

R12 - Jakość dowodu zgody i nieprzetestowane adaptery CMP

Art. 7 ust. 1 nakłada ciężar wykazania zgody na administratora, a kod mówi to wprost jako powód istnienia dziennika zgód. Na zmierzonych danych z pomiaru (sierpień 2026 r.) 671 z 706 sesji nosi consent_source='testdata' z pustym znacznikiem czasu, zapisane przez fixture deweloperski - nie są one dowodem na cokolwiek. Prawdziwych zapisów było wtedy 35: 27 z API, 5 z Google Consent Mode, 2 późne udzielenia, 1 wycofanie. Według stanu na 16.10.2026 566 z 8648 sesji ludzi nosi consent_source='testdata'; pozostałe mają zapis z API (7451), z adaptera Consented (620) lub z Google Consent Mode (9). Usuwanie przy wycofaniu istnieje jako opcja i jest wyłączone we wszystkich projektach (stan na 16.10.2026), więc wycofanie zatrzymuje przyszłe nagrywanie, ale pozostawia dotychczasowe nagrania na miejscu.

Z sześciu adapterów CMP i trzech warstw wykrywania zgody tylko trzy ścieżki zostały sprawdzone w praktyce: bezpośrednie API, Google Consent Mode i Cookiebot. TCF oraz pięć adapterów - Usercentrics, OneTrust, Consentmanager, Borlabs, Complianz - jest zbudowanych, ale nigdy nie działało wobec żywego CMP. Wobec obowiązującej zasady fail-closed adapter, który błędnie odczyta sygnał, zawodzi w kierunku nienagrywania, a to kierunek bezpieczny; ryzyko dotyczy więc głównie niezweryfikowanego dowodu, a nie bezprawnego nagrywania.

Prawdopodobieństwo - Zmaterializowane dla tego zbioru danych. Waga - Poważna w kategoriach produkcyjnych, ponieważ zgoda, której nie da się udowodnić, jest w sporze zgodą, której nie było. Ta ocena odnosi się do danych deweloperskich i musi zostać zmierzona ponownie. do uzupełnienia: zmierzony udział sesji produkcyjnych z rzeczywistym zapisem zgody oraz data, w której każdy adapter CMP zweryfikowano wobec żywej instalacji

R13 - Zgłoszenia do wsparcia przekazywane do Telegrama wraz z nieskróconym IP (przekazywanie zakończone 11.08.2026)

Do 11.08.2026 po wysłaniu zgłoszenia do wsparcia cała sprawa trafiała do Telegrama: status konta, adres e-mail, temat, pełna treść wiadomości, źródłowy adres URL oraz adres IP w postaci nieskróconej. Tokeny były ustawione, więc gałąź była aktywna. Zgłaszający często nie jest klientem, a tekst zgłoszenia nie ma ograniczeń - ludzie opisują w zgłoszeniach sytuacje zdrowotne, spory i okoliczności finansowe, bo do tego zachęca samo pole. Od 11.08.2026 cfg/lib.php wysyła dokładnie jeden stały ciąg znaków: "MousePlayer: es liegt eine neue Supportanfrage vor." Do wiadomości nie trafia żadna zmienna, nie ma parse_mode, świadomie nie ma też numeru sprawy - byłby to identyfikator odnoszący się do osoby - ani odnośnika budowanego z nazwy hosta, ponieważ ta wartość pochodzi z samego żądania. Strażnik (ai/pruefstand/test_telegram_signal.php) sprawdza nie wynik, lecz możliwość: które zmienne mogą w ogóle dotrzeć do wiadomości. Cztery są dozwolone, 15 identyfikatorów jest zakazanych, a tekst musi być ciągiem w pojedynczym cudzysłowie, bez wstawiania wartości; strażnika uruchomiono wobec dwóch celowo popsutych wersji i wychwycił obie. Nie usunięto natomiast przechowywania lokalnego. Zgłoszenie zapisywane jest w support_requests bez zmian, wraz z adresem e-mail i adresem IP - jest to zamierzone, dane te są potrzebne na wypadek sporu - a support_requests do 17.08.2026 nie miała okresu przechowywania; od tej daty zgłoszenie jest usuwane po 730 dniach (por. R7). Sens zmiany polega na tym, że dane nie wychodzą na zewnątrz, a nie na tym, że znikają.

Prawdopodobieństwo - Zmaterializowane do 11.08.2026 przy każdym wysłaniu; od 11.08.2026 przekazywanie nie następuje. Waga - Znacząca: do 11.08.2026, ponieważ Telegram jest poza UE i nie oferuje umowy powierzenia dla kanałów botów; od tej daty ta sama ocena odnosi się już tylko do przechowywania lokalnego, bo pozostaje przechowywanie adresu e-mail, adresu IP i nieograniczonego tekstu we własnej bazie danych - od 17.08.2026 ograniczone do 730 dni. Element państwa trzeciego odpadł, okres przechowywania jest ograniczony; jest prowadzony pod R7. Decyzja została podjęta i opatrzona datą: kanał zostaje utrzymany, a wiadomość od 11.08.2026 nie niesie żadnych danych. Podstawa prawna i instrument transferu dla przekazania do państwa trzeciego nie są już zatem potrzebne, ponieważ do Telegrama nie trafiają żadne dane osobowe; dla tej operacji Telegram nie jest podmiotem przetwarzającym. Poziom łączny - średni do 11.08.2026, od tej daty niski.

R14 - Wyprowadzenie danych do odbiorców wybranych przez samego administratora

MousePlayer udostępnia mosty, przez które pojedyncze dane trafiają do własnych systemów administratora: do systemu CRM, helpdesku, marketingu, reklamy, magazynu lub zadań, albo pod adres, który sam wskaże. Wyboru dokonuje wyłącznie on, dostęp zapisuje sam, a przekazanie jest zatem jego poleceniem. Szczegóły opisuje Rejestr, sekcja 4.1.

Na czym polega ryzyko. Nie na ilości: przekazywane są identyfikatory i nazwy zdarzeń, nigdy zarejestrowana treść strony, ślad myszy ani tekst formularza. Ryzyko polega na nieodwracalności. Jeśli dotrze do nas żądanie usunięcia z art. 17, usuwamy naszą kopię — kopii u odbiorcy nie dosięgniemy. Jak długo ją przechowuje, dokąd ją przenosi i komu przekazuje, pozostaje poza naszym wpływem i nie podlega naszej kontroli. To samo dotyczy przekazania do państwa trzeciego: cel wyznacza administrator, a wraz z nim gwarancję z rozdziału V.

Co w tej sprawie zrobiono. Polityka prywatności mówi wprost i jedno, i drugie — co wychodzi oraz że żądanie usunięcia tam nie działa — i w kwestii tego, którzy odbiorcy są włączeni, kieruje osobę, której dane dotyczą, do operatora strony, który podjął tę decyzję. Umowa powierzenia wyjaśnia, że odbiorcy ci nie są podprzetwarzającymi MousePlayera. Technicznie zakres jest wąski, a do sieci reklamowych wyraźnie nie trafiają imię i nazwisko, adres e-mail, numer telefonu ani adres IP. Od 20.08.2026 każdy projekt prowadzi dziennik dostarczeń (Rejestr A.11), z którego administrator może odczytać, co faktycznie wyszło — wcześniej nie było to dla niego widoczne.

Co pozostaje. Ryzyko szczątkowe, którego nie da się usunąć technicznie, dopóki funkcja istnieje: ujawnienie jest zamierzone, a jego skutki leżą poza naszą sferą. Ponosi je administrator, który włącza most, i jest ono wobec niego nazwane w umowie powierzenia oraz w niniejszej ocenie.

8. (d) Środki planowane w celu zaradzenia ryzyku

Każdy środek poniżej ma status, a statusy nie są ozdobą. Wdrożone oznacza zweryfikowane dziś w działającym systemie. Częściowe oznacza, że mechanizm istnieje, ale nie osiąga jeszcze swojego celu. Planowane oznacza, że nie istnieje. Ocena skutków, która przedstawia środki planowane jako wdrożone, jest przedmiotem standardowego zarzutu wobec tego instrumentu i jest to zarzut, który niszczy wartość dokumentu w jedynej sytuacji, w której ten dokument ma znaczenie.

8.1 Wdrożone dzisiaj - zweryfikowane

Środek	Czemu zaradza	Dowód
Bramka zgody w przeglądarce, fail-closed: brak sygnału, awaria CMP, błąd skryptu i nieznane pochodzenie prowadzą do "nie nagrywać"	Zgodność z prawem	Maszyna stanów mpEinw w www/mp.js, za kontrolą botów
Niezależne egzekwowanie po stronie serwera: przechodzi wyłącznie GRANTED lub GRANTED_LATE albo wyraźne zwolnienie regionalne; wycofanie, nieznany kraj i wszystko, co niejasne, zamyka połączenie	Zgodność z prawem	class/Server.class.php:977-1004; w chwili pomiaru odnotowano 24 zablokowane połączenia
Lista wykluczeń ścieżek stosowana przed bramką, dopasowywana wyłącznie do ścieżki	Minimalizacja	class/Server.class.php:963-975; w chwili pomiaru odnotowano 71 zablokowanych połączeń
Skracanie IP w momencie odczytu, przed jakimkolwiek odbiorcą tej wartości	R3, wyłącznie na przyszłość	class/Server.class.php:432-435; wszystkie sesje od 7 sierpnia 2026 skrócone
Maskowanie formularzy z bezwarunkową dolną granicą dla haseł i danych płatniczych przy każdym ustawieniu; wszystkie projekty na najsurowszym poziomie	R2, wyłącznie na przyszłość	www/mp.js:4818-4853
Nazwy pól klasyfikowane zamiast przesyłania	Minimalizacja	www/mp.js:4653-4674
Maskowanie DOM wewnątrz oznaczonych obszarów, stosowane także do bieżących mutacji	R1, częściowo	www/mp.js:3934-3970 oraz 4732-4768
Ciąg TC przechowywany wyłącznie jako skrót SHA-256	Minimalizacja	visitor_sessions.tcf_hash
Ładunek odtwarzania celowo wyłączony z publicznego API	R4	www/api/v1_session_detail.php:25
Linki udostępniania: token 160-bitowy, domyślnie 7 dni i maksymalnie 90 dni, identyfikatory brane wyłącznie z tokena, ciąg zapytania zastępowany, a nie ignorowany, rola NULL, wszystkie trzy punkty końcowe ograniczone, identyczna odpowiedź dla tokenów wymyślonych, wygasłych i odwołanych, dostępne odwołanie	R4	cfg/lib.php mp_share_erstellen / mp_share_pruefen; www/.htaccess
Geolokalizacja wobec lokalnych plików bazy - żadnego wywołania do podmiotu trzeciego na całej ścieżce nagrywania	Transfery do państw trzecich	class/IP2CityLite.class.php:37; class/Server.class.php:724
Model ról dla każdej przestrzeni roboczej; usuwanie ograniczone do owner i admin i zawsze ograniczone do projektu	Kontrola dostępu	www/player.php:267, 275-282
Dziennik zdarzeń zgody celowo zachowywany po usunięciu sesji, jako dowód, że nastąpiło wycofanie	Art. 7 ust. 1	srv/db_worker.php:257-259
Dziennik zmian dla działań zapisujących	Rozliczalność	cfg/lib.php:2878-2890; 666 wpisów w chwili pomiaru
Bezpieczeństwo transportu: wymuszony HTTPS; TLS z prawdziwym certyfikatem kończy się w nginx, także dla WebSocketu (/mp_wss/), tunelu HTTP (/mp_wst), przesyłania zrzutów (/mp_dom) i punktu pomiarowego (/mp_wsfail); serwer WebSocket nasłuchuje wyłącznie na adresie pętli zwrotnej. Połączenia z bazą danych i Redis w sieci lokalnej nie są szyfrowane (por. R10)	Poufność	www/.htaccess; konfiguracja nginx (srv/nginx/); srv/server.php z powiązaniem z 127.0.0.1:8081
Tokeny CSRF z random_bytes z porównaniem o stałym czasie; ciasteczko sesyjne httponly, SameSite=Lax, secure; hashowanie haseł; przygotowane zapytania we wszystkich audytowanych ścieżkach zapisu; ograniczanie tempa logowania; automatyczna blokada i limity połączeń na IP; działający fail2ban	Poufność	cfg/lib.php:110-132; www/login.php; class/Server.class.php:449-455, 660-668
Sekrety poza kontrolą wersji	Poufność	.gitignore obejmuje .env; śledzony jest wyłącznie .env.example
Wyegzekwowane przechowywanie dla logów panelu: odpowiednio 60 dni i 72 godzin, plus wygasanie blokad	Ograniczenie przechowywania	srv/db_worker.php (codzienny przebieg usuwania)
Codzienny przebieg usuwania według taryfy i według odrębnych terminów dla pozostałych tabel, a do tego co godzinę terminy dla sesji oznaczonych jako boty; jego brak zgłasza odrębny proces statusu pocztą elektroniczną i w Urgent Logs	Ograniczenie przechowywania, R7	srv/db_worker.php; srv/cron_status.php (sys_purge); najstarszy wpis w audit_logs w dniu 16.10.2026 na granicy terminu 60 dni
fail2ban z dziewięcioma jailami, w tym mp-nginx-429, który blokuje adresy wielokrotnie uruchamiające limit szybkości nginx; do tego limity szybkości w nginx	Dostępność, przeciwdziałanie nadużyciom	fail2ban-client status, sprawdzono 16.10.2026
Archiwizacja przed ostatecznym usunięciem: usunięcie projektów, przestrzeni roboczych i kont oraz usunięcie według adresu IP lub odwiedzającego najpierw ukrywa dane i kończy nagrywanie; ostateczne usunięcie następuje po 30 dniach lub wcześniej na żądanie, wykonywane i przeliczane przez proces roboczy. Usunięcie nieaktywnych kont nie poprzedza archiwizacja	Integralność, ograniczenie przechowywania	Migracja 189; cfg/archivierung_lib.php; mp_loesch_archiv
Terminy dla sesji oznaczonych jako boty: nagranie opróżniane (termin w dniach: 1), wiersz sesji usuwany po 14 dniach	Ograniczenie przechowywania	site_settings retention_bot_recording_days i retention_bot_session_days; srv/db_worker.php

8.2 Częściowe - istnieje, ale nie osiąga jeszcze swojego celu

Środek	Dlaczego nie jest jeszcze skuteczny
Maskowanie DOM	Opt-in dla każdego elementu. Chroni to, co odwiedzający wpisuje, a nie to, co strona wyświetla - istota R1
Usuwanie przy wycofaniu	Zaimplementowane jako opcja, wyłączone we wszystkich projektach (stan na 16.10.2026), więc wycofanie nie usuwa tego, co już zarejestrowano
Nagłówki noindex i no-referrer	Strona pokazująca nagranie przez link udostępniania (player.php w trybie udostępniania) ma Referrer-Policy: no-referrer i Cache-Control: no-store, ale nie ma nagłówka X-Robots-Tag; noindex występuje tylko w www/share.php, stronie błędu, a robots.txt zezwala na wszystko (sprawdzono 16.10.2026)

8.3 Planowane - niewdrożone

Środek	Czemu zaradza	Priorytet
Zaszyfrować kopię poza siedzibę przed wysyłką - wykonane 11.08.2026: codzienny przebieg szyfruje na własnym serwerze przed przesłaniem (rclone crypt, wraz z nazwami), a klucze leżą w dwóch plikach z prawami 600. Usunąć nieszyfrowany zasób historyczny z dotychczasowego katalogu docelowego - wykonane 12.08.2026. Złożyć pliki kluczy tak, by przetrwały zniszczenie maszyny - wykonane 17.08.2026: leżą w formie wydruku w sejfie (oświadczenie administratora). Ustalić albo zakończyć układ z Google Drive – wykonane 5 września 2026 r.: od tego dnia kopia poza siedzibą znajduje się w zasobniku Google Cloud Storage w regionie europe-central2 (Warszawa) i jest objęta Warunkami przetwarzania danych Google Cloud. Pozostałość na prywatnym koncie Drive została usunięta 6 września 2026 r., po zdanej próbie odtworzenia z nowego miejsca docelowego. Usunąć stare skrypty kopii zapasowej - wykonane 16.10.2026.	R5	Odpada - wykonane
Odwrócić ustawienie domyślne dla treści strony: zapisywać tekst maskowany, chyba że został wyraźnie zwolniony, i wymagać pisemnego potwierdzenia klienta, zanim tekst strony będzie przechwytywany dosłownie	R1	Pierwszy
Umowna polityka branżowa: które branże są w ogóle dopuszczane i na jakich dodatkowych warunkach	R1	Pierwszy
Jednorazowe skrócenie lub usunięcie 236 + 291 + 666 + 5 historycznych adresów - wykonane 17.08.2026: zasób historyczny w ścieżce nagrywania oraz w audit_logs i user_ip_history został skrócony (por. R3)	R3	Odpada - wykonane 17.08.2026
Przejrzeć i usunąć 173 wiersze z wpisami otwartym tekstem - wykonane 17.08.2026: usunięte bez przeglądania (decyzja administratora, por. R2)	R2	Odpada - wykonane 17.08.2026
Rozszerzyć czyszczenie na trzynaście nieobjętych tabel; przenieść je na monitorowany harmonogram; naprawić lukę złączenia wewnętrznego, aby osierocone sesje były osiągalne	R7	Nie dotyczy - wykonane 17.08.2026 (okresy i strażnik); wybór przez złączenia wewnętrzne pozostaje, osierocone sesje nie powstają (por. R7)
Logować dostęp odczytu do odtwarzacza i obu punktów końcowych danych	R11, art. 33	Wysoki
Referrer-Policy i X-Robots-Tag na stronie odtwarzacza; krótszy domyślny czas życia udostępnienia - Referrer-Policy: no-referrer jest ustawiony w trybie udostępniania (sprawdzono 16.10.2026); X-Robots-Tag i krótszy domyślny czas życia (nadal 7 dni) pozostają do wykonania	R4	Średni
Samoobsługowy odczyt, dzięki któremu odwiedzający może pobrać własny identyfikator, co czyni żądania z art. 15 i art. 17 wykonalnymi - wykonane 17.08.2026: /moje-dane (po niemiecku /meine-daten, po angielsku /my-data), por. R9	R9	Odpada - wykonane 17.08.2026
Nigdy nie zwalniać z maskowania stanu pól wyboru i przycisków opcji; objąć je maskowaniem	R1, R2	Średni
Szyfrowanie w spoczynku; TLS do bazy danych; ochrona dostępu do Redis - ochrona dostępu do Redis wykonane 16.08.2026; szyfrowanie w spoczynku i TLS do bazy danych pozostają do wykonania (por. R10)	R10	Średni
Usunąć IP z powiadomienia Telegram albo zastąpić kanał - wykonane 11.08.2026: powiadomienie składa się już tylko ze stałego komunikatu, bez żadnej zmiennej (cfg/lib.php), zabezpieczone przez ai/pruefstand/test_telegram_signal.php	R13	Nie dotyczy - wykonane 11.08.2026
Okres przechowywania dla support_requests, audit_logs i user_ip_history	R7	Nie dotyczy - wykonane 17.08.2026 dla support_requests i audit_logs, 24.09.2026 dla user_ip_history
Granica najemcy w visitor_nicknames	R6	Niski
Udokumentowana ścieżka przeglądu i sprzeciwu dla automatycznej blokady i flagi is_suspicious - dla automatycznej blokady wykonane 17.08.2026 (wygaśnięcie wtedy po 7 dniach, dziś po 24 h, sprzeciw przez formularz wsparcia, zniesienie w obszarze administracyjnym, por. R8); dla flagi is_suspicious pozostaje do wykonania	R8	Niski
Zweryfikować każdy adapter CMP wobec żywej instalacji, zanim zostanie zaoferowany	R12	Niski

8.4 Procedury i zabezpieczenia jeszcze do ustanowienia

Art. 35 ust. 7 lit. d wymaga zabezpieczeń, środków bezpieczeństwa i mechanizmów - co obejmuje procedury organizacyjne, a nie tylko kod. W chwili pomiaru brakowało czterech; ich obecny stan podano przy każdym z nich.

• Ustalono 17.08.2026. Wykrycie: administrator, klient lub odwiedzający stronę. Droga zgłoszenia do nas: privacy@mouseplayer.com. Decyzja o zgłoszeniu do organu nadzorczego: Lukas Wójcik, właściciel, w ciągu 72 godzin zgodnie z art. 33 ust. 1. Poinformowanie klienta: pocztą elektroniczną, bez zbędnej zwłoki zgodnie z art. 33 ust. 2, najpóźniej w ciągu 48 godzin (umowa powierzenia przetwarzania danych, sekcja 8). Wysyłka: poczta wychodząca jest od 23.09.2026 skonfigurowana przez SMTP w Namecheap Private Email (nadawca office@mouseplayer.com); obiecana droga do klienta jest więc dostępna. Ćwiczenie dotąd się nie odbyło.
• Odpowiedziano 17.08.2026: do tego czasu nie przeprowadzono żadnego testu odtworzenia; przewidziano test comiesięczny, zakładany czas odtworzenia nie więcej niż 24 godziny. Oba pliki kluczy przechowywane są w formie wydruku w sejfie dostępnym wyłącznie administratorowi. Od tego czasu przeprowadzono: próbę odtworzenia z nowego miejsca docelowego w Google Cloud Storage przed usunięciem kopii z Drive (5/6 września 2026 r.) oraz 7 października 2026 r. pełne odtworzenie danych z kopii w chmurze do odrębnego środowiska - około 70 minut, próbki z archiwum i bazy danych bez błędów. Jest to dowód odtworzenia danych, a nie odbudowa kompletnej maszyny produkcyjnej; mechanizm przypominający o następnym teście nie istnieje.
• Odpowiedziano 17.08.2026: automatycznego alarmowania NIE MA, sprawdza sie recznie. Pomiar tego samego dnia: w kodzie nie istnieje czujnik awarii, miejsca na dysku ani powodzenia kopii - jedyne wystapienia Telegrama znajduja sie w dolaczonej bibliotece, ktorej nikt nie wywoluje, srv/cron_status.php zapisuje jedynie wartosc statusu do Redis, a system_alerts jest pusta. Do 17.08.2026 TOM zapowiadaly cos przeciwnego ("w razie awarii systemu administrator otrzymuje automatyczne powiadomienie"). Byla to obietnica, ktorej kod nie spelnia; zostala sprostowana tego samego dnia. Załatwiono 19.08.2026: srv/backup-crypt.sh utrwala wynik każdego przebiegu w pliku stanu, a srv/cron_status.php sprawdza obok dotychczasowych pięciu składników powodzenie kopii zapasowej, wolne miejsce na dysku systemowym i nośniku kopii oraz – jako czujnik prawny, a nie operacyjny – próg z art. 37. Każda nieudana kontrola zgłaszana jest pocztą elektroniczną najwyżej raz dziennie. Czujnik pyta o ostatnią udaną kopię, a nie o ostatnią próbę: skrypt, który startuje każdej nocy i każdej nocy przerywa, ma świeży znacznik czasu i nie ma kopii – dokładnie tak przez pięć dni pozostawała niezauważona aktualizacja GeoIP. Jedno ograniczenie pozostaje i zostaje wskazane wprost: czujnik działa na tej samej maszynie, którą obserwuje, i nie może zgłosić jej całkowitej awarii; zewnętrznej kontroli dostępności nie było. Od 2 października 2026 r. druga maszyna w tym samym miejscu co minutę sprawdza aplikację (TOM, sekcja 5); awarii łącza internetowego nadal nie wykrywa. TOM zostały dostosowane tego samego dnia (wersja 1.2), aby sprostowanie nie ograniczało się do niniejszego dokumentu.
• Nie zasięgnięto opinii osób, których dane dotyczą. Uzasadnienie: wobec obserwowanych użytkowników końcowych MousePlayer występuje wyłącznie jako podmiot przetwarzający i nie ma do nich własnego kanału - każde wystąpienie biegłoby przez strony klientów i samo byłoby przetwarzaniem ich danych w nowym celu. Interesy osób, których dane dotyczą, uwzględniono pośrednio: przez mechanizm zgody, który bez sygnału nic nie nagrywa, przez maskowanie danych wejściowych oraz przez terminy usuwania. Zasięgnięcie opinii pozostaje możliwe, gdy tylko powstanie kanał docierający do nich bez ponownego ich rejestrowania. (decyzja administratora, 17.08.2026)

9. Ryzyko szczątkowe i uprzednie konsultacje na podstawie art. 36

Art. 36 ust. 1 wymaga uprzednich konsultacji z organem nadzorczym, jeżeli ocena skutków wskazuje, że przetwarzanie powodowałoby wysokie ryzyko w braku środków zastosowanych w celu zminimalizowania tego ryzyka. Testem nie jest zatem to, czy zidentyfikowano wysokie ryzyka - zidentyfikowano dwa bardzo wysokie - lecz to, czy wysokie ryzyko pozostaje po wdrożeniu środków z lit. d). Na to pytanie trzeba uczciwie odpowiedzieć dla każdego z tych dwóch.

R5, codzienna kopia poza siedzibę, dawała się naprawić zwykłymi środkami - i została naprawiona. Warstwa szyfrowania przed wysyłką działa od 11.08.2026, nieszyfrowany zasób historyczny u dostawcy został usunięty 12.08.2026, a od 5 września 2026 r. kopia znajduje się w europejskim regionie na Warunkach przetwarzania danych Google Cloud. Pytanie, na czym opiera się codzienne przekazywanie, ma zatem odpowiedź. Po ponownej ocenie 17.09.2026 R5 jest na poziomie średnim. Warunek z oceny (usunięcie starych skryptów) został spełniony 16.10.2026; ponowna ocena R5 należy do administratora.

R1, szczególne kategorie w treści strony, nie daje się w pełni naprawić. System nie może wiedzieć, co wyświetla strona klienta, i żadna ilość logiki maskowania tego nie zmieni. Środki mogą osiągnąć odwrócenie ustawienia domyślnego, tak by trybem awarii było nagranie mało użyteczne, a nie bezprawne, a do tego umowną politykę branżową i potwierdzenie ze strony klienta. To zmniejsza ryzyko istotnie. Nie eliminuje go, ponieważ klient nadal może zwolnić tekst strony dla strony, która później wyrenderuje coś wrażliwego.

Co do art. 36 wniosek ma dwie części i nie wolno ich zlewać w jedną. Formalnie obowiązek konsultacji spoczywa na administratorze - kliencie prowadzącym witrynę - a nie na MousePlayer, który jest podmiotem przetwarzającym dla danych odwiedzających niosących wysokie ryzyko. MousePlayer nie może konsultować za klienta, a klient nie może scedować tej decyzji. To, co MousePlayer jest winien na podstawie art. 28 ust. 3 lit. f, to przekazanie klientowi faktów, które pozwolą mu ją podjąć, i temu właśnie służą sekcje a) i c) niniejszego dokumentu.

Merytorycznie: uprzednie konsultacje nie są wskazane, jeżeli środki z 8.3 zostaną wdrożone przed uruchomieniem produkcyjnym, ponieważ ryzyko szczątkowe spada wówczas poniżej progu, do którego odnosi się art. 36. Uprzednie konsultacje są wskazane w jednej konkretnej sytuacji i jest ona decyzją, a nie przypadkiem: jeżeli operator postanowi nie odwracać ustawienia domyślnego dla treści strony, przyjmując dalej klientów z sektora ochrony zdrowia, prawnego, finansowego lub publicznego. Ryzyko szczątkowe pozostaje wtedy wysokie z wyboru, a art. 36 ust. 1 stosuje się wprost. Druga sytuacja, która figurowała tu do 17.09.2026 - codzienna kopia poza siedzibę kontynuowana bez ustalonego instrumentu transferu - od 5 września 2026 r. już nie istnieje (R5).

Jeszcze jedna kwestia należy do tego miejsca, bo łatwo ją zgubić. Art. 36 nie jest karą, a konsultacja nie jest przyznaniem się do winy. Jest mechanizmem, który rozporządzenie przewiduje dokładnie dla sytuacji, w jakiej znajduje się ten system - rzeczywiście użytecznej techniki, której ryzyko szczątkowe zależy od czynnika, nad którym operator nie ma pełnej kontroli. Jeżeli administrator zamierza kontynuować przy wysokim ryzyku szczątkowym, konsultacja jest zgodną z prawem drogą do tego.

10. Przegląd, wersja i zatwierdzenie

Art. 35 ust. 11 wymaga, by administrator dokonywał przeglądu, czy przetwarzanie odbywa się zgodnie z niniejszą oceną, przynajmniej gdy zmienia się ryzyko. Trzy zdarzenia zmieniają tu ryzyko istotnie i każde z nich powinno uruchamiać powtórzenie oceny, a nie jej odczytanie: pierwszy klient z sektora regulowanego; pierwsze uruchomienie eksportu do BigQuery albo webhooka; oraz moment, w którym monitorowani użytkownicy końcowi przekroczą próg zapisany w sekcji 3.

Ocena skutków opiera się zasadniczo na pomiarach wykonanych 10 i 11 sierpnia 2026 wobec systemu deweloperskiego; została zatwierdzona 17.08.2026 i od tego czasu jest aktualizowana, ostatnio 16.10.2026 przez uzgodnienie ze stanem technicznym. Otwarte pozostają pola do uzupełnienia w sekcjach 1, 3 i 4 oraz w R12, które może wypełnić wyłącznie administrator, a także ponowna ocena ryzyk, których przyczyny od czasu pomiaru zostały całkowicie lub częściowo usunięte (R2, R3, R9, R10); wniosek o ryzyku szczątkowym w sekcji 9 jest warunkowany środkami nadal otwartymi w 8.3.

Pozycja	Wpis
Administrator i podmiot przetwarzający	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polska - NIP PL7252266190 - office@mouseplayer.com
Inspektor ochrony danych	Nie wyznaczono. Analiza z art. 37 i zalecenie - por. sekcja 3.
Dokumenty powiązane	Rejestr czynności przetwarzania z art. 30 ust. 1 i rejestr kategorii czynności przetwarzania z art. 30 ust. 2, środki techniczne i organizacyjne, lista podprzetwarzających, umowa powierzenia przetwarzania danych oraz informacja o ochronie danych
Podstawa faktyczna	Kod źródłowy, schemat bazy danych, liczby wierszy, lista procesów, wartości konfiguracyjne i pliki dziennika systemu deweloperskiego, 10-11 sierpnia 2026, aktualizowane do 16 października 2026 r.
Wersja i data zatwierdzenia	Zatwierdzone przez Lukasa Wojcika, właściciela, 17.08.2026. Nie zasięgnięto zewnętrznej porady w zakresie ochrony danych. Przegląd corocznie oraz przy każdej zmianie przetwarzania; datowane wersje w systemie kontroli wersji w ai/cms/. Uzupełniono 17.09.2026 na polecenie właściciela: ponowna ocena R5 (sekcje 5.4, 6, 7, 8.3 i 9). Uzupełniono 16.10.2026: uzgodnienie ze stanem technicznym (nagłówek, sekcje 1, 3, 4, 5, 7, 8 i 10); poziomy ryzyka bez zmian, ponowna ocena R2, R3, R9 i R10 przez administratora pozostaje otwarta. Uzupełniono 16.10.2026 (drugi przegląd): terminy i czas trwania automatycznej blokady jako ustawienia zamiast stałych liczb, podstawy prawne zgłoszeń do wsparcia i komentarzy, przechowywanie kluczy i dostępność starych skryptów kopii zapasowej (R5), termin poinformowania klienta; poziomy ryzyka bez zmian, ponowna ocena R5 przez administratora pozostaje otwarta. Uzupełniono 16.10.2026 (trzeci przegląd): odnotowano usunięcie starych skryptów kopii zapasowej (R5), ujednolicono informacje o ochronie dostępu do bazy danych i Redis (R10); poziomy ryzyka bez zmian, ponowna ocena R5 przez administratora pozostaje otwarta.