Prywatność rzeczywista a pozorna: pytania, które warto sobie zadać Cuadernos Lacre https://solo2.net/pl/zeszyty/articulos/prywatnosc-architektoniczna-vs-deklaratywna.html Operacyjne podsumowanie cyklu 2: pytania, które odróżniają usługę o prywatności architektonicznej od usługi o prywatności deklaratywnej. Kwestionariusz dla europejskiego profesjonalisty przed przyjęciem jakiegokolwiek narzędzia cyfrowego do danych wrażliwych. --- Żebyśmy się zrozumieli: Dwie usługi z tą samą notą prawną mogą zachowywać się bardzo różnie. Jedna chroni dzięki projektowi technicznemu. Druga chroni dzięki obietnicy umownej. Różnicy nie wyczytasz z noty — odkrywasz ją, stawiając konkretne pytania. Jakość odpowiedzi mówi o produkcie tyle samo, co ich własna treść. --- Różnica między prywatnością architektoniczną a prywatnością deklaratywną Na przestrzeni siedmiu poprzednich artykułów tego cyklu przeszliśmy przez różne warstwy tej samej sprawy. Prawo transferów międzynarodowych przy Schrems II. Matematyczną ideę haszu kryptograficznego, który pieczętuje każdy Cuaderno. Architektoniczny wybór kill switcha i przejęcie instytucjonalne, które niemal zawsze mu towarzyszy. Mechanizm szyfrowania typu end-to-end i operacyjne pytanie o to, gdzie znajdują się klucze. Dopasowanie zachęt zależnie od modelu biznesowego. Samosuwerenną tożsamość kryptograficzną. Self-hosting jako proporcjonalną strategię. Każdy artykuł zajął się jednym kątem widzenia. Ten, ostatni w cyklu, zbiera je w kwestionariusz. Rozróżnienie, które warto zapamiętać, jest proste: są usługi, których prywatność jest architektoniczna, i są usługi, których prywatność jest deklaratywna. Pierwsza jest wbudowana w projekt techniczny: pewne naruszenia zobowiązania do prywatności są technicznie trudne lub niemożliwe, bo architektura na nie nie pozwala. Druga jest złożona w treści noty prawnej: pewne naruszenia byłyby umownie sankcjonowalne, gdyby do nich doszło, ale technicznie nic ich nie powstrzymuje. Oba modele mogą spełniać RODO; ale jeden chroni z założenia konstrukcji, a drugi chroni obietnicą, a różnica jest operacyjnie ogromna. Pytania, które następują, zaprojektowano tak, by odróżnić jeden przypadek od drugiego. Nie są to zaawansowane pytania techniczne. To pytania, na które każdy uczciwy dostawca potrafi odpowiedzieć w swojej publicznej dokumentacji. Jakość i precyzja odpowiedzi mówi o produkcie tyle samo, co sama odpowiedź. Pytania grupują się w sześć warstw; warto zadać je wszystkie przed przyjęciem usługi do danych wrażliwych, nie tylko te, które wskazuje pierwszy instynkt. Warstwa 1: architektura Ustalmy jeden termin, zanim przejdziemy dalej. Przez operatora rozumiemy firmę świadczącą usługę: podmiot kontrolujący serwery i oprogramowanie, a nie konkretną osobę. Po tym wyjaśnieniu podstawowe pytanie architektoniczne brzmi: co operator robi z treścią między nadawcą a odbiorcą? Możliwe są trzy odpowiedzi i warto umieć je rozróżniać, ponieważ wszystkie trzy bywają reklamowane podobnym słownictwem. Pytaniem uzupełniającym — sformułowanym już w Cuaderno o szyfrowaniu — jest: kto ma klucze kryptograficzne pozwalające odczytać treść? Jeśli ma je użytkownik i tylko użytkownik, szyfrowanie jest rzeczywiste. Jeśli ma je dodatkowo operator w jakiejkolwiek formie — choćby pod nazwą „odzyskiwania konta” lub „synchronizacji między urządzeniami” — szyfrowanie jest nominalne. Pytanie nie dopuszcza uczciwej odpowiedzi pośredniej. Warstwa 2: model biznesowy Pytanie o model biznesowy liczy się tyle samo, co pytanie architektoniczne, i z tego samego zasadniczego powodu: zachęty wytwarzają, na przestrzeni czasu, produkty systematycznie różne, nawet przy identycznych deklarowanych celach. Jak operator zarabia dziś pieniądze? Jedno źródło, dwa, mieszanka? Jeśli finansowanie obejmuje reklamę lub monetyzację danych, jakie dane są monetyzowane i na jakiej podstawie prawnej RODO się to odbywa? Czy cel zadeklarowany w nocie prawnej obejmuje dane osób trzecich, które profesjonalista zamierza powierzyć usłudze? I pytanie drugiego rzędu, nie zawsze stawiane: jaka jest sytuacja finansowa operatora w perspektywie trzech lub pięciu lat? Firma w fazie kapitału ryzyka działa pod innymi presjami niż firma o stabilnej rentowności. Zmiana modelu finansowania jest, raz po raz, momentem, w którym domyślny kontrakt z użytkownikami zostaje napisany na nowo bez negocjacji. Warstwa 3: jurysdykcja Dla europejskiego profesjonalisty pytanie o jurysdykcję nie jest retoryczne. W jakiej jurysdykcji zarejestrowany jest operator? W jakim kraju fizycznie znajdują się serwery przetwarzające dane? Czy odpowiedź na oba poprzednie pytania jest taka sama czy różna, a jeśli się różni, jakie ustawodawstwo ma zastosowanie? Region europejski obsługiwany przez firmę amerykańską nie jest, dla celów Schrems II, odpowiedzią europejską: firma podlega FISA 702 niezależnie od tego, gdzie znajdują się serwery. Uzupełniającym pytaniem operacyjnym jest: gdyby jutro nadszedł nakaz wywiadowczy ważny w jurysdykcji operatora, żądający wydania moich danych lub danych moich klientów, co by się stało? Jeśli uczciwa odpowiedź zaczyna się od „firma byłaby zobowiązana je wydać”, usługa nie chroni przed tym nakazem, choćby reklama sugerowała coś przeciwnego. Jeśli uczciwa odpowiedź zaczyna się od „firma nie mogłaby ich wydać, bo nie ma ich w postaci jawnej”, usługa chroni; a różnica zależy niemal całkowicie od dwóch pierwszych warstw, a nie od jakości polityki prywatności. Warstwa 4: operator i kill switch Jaką zdolność techniczną zachowuje operator, by zdalnie zawiesić, zablokować, usunąć lub pogorszyć usługę? Pytanie nie jest paranoiczne: jest operacyjne. Platformy cyfrowe wielokrotnie korzystały z tej zdolności w ostatnich latach, czasem z własnej inicjatywy, innym razem na nakaz rządów, jeszcze innym po zmianach własnościowych lub polityki. Jeśli zdolność istnieje, warto wiedzieć, na jakich umownie zadeklarowanych przesłankach jest wykonywana, i zarezerwować margines na przesłanki niezadeklarowane, które praktyka ostatnich lat pokazała jako równie istotne: niespodziewany nakaz sądowy, sankcja międzynarodowa, zmiana ładu korporacyjnego, przejęcie przez podmiot o innej polityce. Bliźniaczym pytaniem jest pytanie o plan ciągłości: gdyby operator skorzystał z tej zdolności przeciwko profesjonaliście — z jakiegokolwiek powodu, słusznego czy nie — ile czasu działania pozostałoby dostępne, jaka procedura eksportu danych istnieje i do jakiego alternatywnego dostawcy można by migrować? Jeśli odpowiedź zaczyna się od „to nie powinno się zdarzyć”, to nie jest odpowiedź operacyjna; to obietnica. Warstwa 5: tożsamość i dostęp Kto kontroluje poświadczenia dostępu do usługi? Jeśli operator może przywrócić dostęp użytkownika bez udziału użytkownika — procedurę zwykle nazywaną „odzyskiwaniem konta” — operator jest, technicznie, depozytariuszem konta i może je również odstąpić temu, kto o to wystąpi we właściwym trybie. Jeśli operator nie może przywrócić dostępu, ponieważ tożsamość znajduje się kryptograficznie na urządzeniu użytkownika, operator nie może go również odstąpić, nawet na nakaz. Oba tryby są zgodne z prawem zależnie od kontekstu; ale, raz jeszcze, są różne i warto wiedzieć, który się przyjmuje. Co dzieje się z danymi profesjonalisty, jeśli profesjonalista utraci dostęp? Czy istnieją mechanizmy odzyskiwania — konta, pliku, sesji — zależne od operatora? Czy te mechanizmy są zgodne z deontologią zawodową branży, jeśli operator zostanie zmuszony do ich użycia? Warstwa 6: przyszłość Ta ostatnia warstwa bywa zaniedbywana, ponieważ wymaga projekcji. Co by się stało, gdyby usługa została przejęta przez inną firmę? Niemal wszystkim przejęciom towarzyszy w kolejnych miesiącach przegląd warunków usługi. Co by się stało, gdyby zmieniły się wymogi regulacyjne? Prawo europejskie od 2022 roku zwiększyło obowiązki usuwania i blokowania, a nie je ograniczyło. Co by się stało, gdyby operator zniknął? Znacząca część usług chmurowych nie ma udokumentowanego planu wyjścia na scenariusz zamknięcia operatora; profesjonalista odkrywa problem, gdy nie ma już czasu, by się do niego przygotować. Jest sformułowanie, które warto zapamiętać dla tej warstwy: architektury mniej zależne od operatora są bardziej odporne na zmiany operatora. Self-hosting w którejkolwiek ze swoich postaci, samosuwerenna tożsamość kryptograficzna, komunikacja bez serwera pośredniczącego — wszystkie one redukują przyszłą powierzchnię ryzyka poprzez zredukowanie obecnej powierzchni zależności. Nie eliminują jej; redukują. Różnica między strukturą a obietnicą Gdybyśmy mieli zdestylować cały cykl w jedno zdanie, brzmiałoby ono tak: odpowiedzi strukturalne utrzymują się, choćby zmienił się operator, administracja czy ustawodawstwo; odpowiedzi oparte na obietnicy utrzymują się tak długo, jak długo ten, kto obiecuje, może i chce ich dotrzymać. Obie mogą być poprawne w chwili przyjęcia. Tylko jedna z nich utrzymuje się niezależnie od upływu czasu i zmiany okoliczności. Nie oznacza to, że każdy profesjonalista powinien wymagać odpowiedzi strukturalnych od wszystkich usług, które przyjmuje. Proporcjonalność pozostaje uprawniona: arkusz kalkulacyjny do wewnętrznej księgowości nie potrzebuje tej samej odpowiedzi co kartoteka kliniczna pacjenta. Oznacza natomiast, że profesjonalizm polega na wiedzy, jaki rodzaj odpowiedzi został przyjęty w każdym przypadku, i na świadomym zdecydowaniu, że ten rodzaj odpowiedzi jest proporcjonalny do konkretnej danej. Kwestionariusz, uporządkowany Dwanaście konkretnych pytań, które syntetyzują cykl, uporządkowanych tak, by odpowiedź na każde z nich kształtowała następne: 1. Czy treść przechodzi przez serwer operatora? Jeśli przechodzi: jawnie, zaszyfrowana kluczami operatora, czy zaszyfrowana kluczami wyłącznie użytkownika? 2. Jeśli powołuje się na szyfrowanie typu end-to-end, gdzie znajdują się klucze kryptograficzne? Czy operator zna lub przechowuje jakąkolwiek ich część w dowolnej formie, w tym w ramach „odzyskiwania”? 3. Jakie metadane usługa generuje i przechowuje? Przez jaki czas? Dla kogo są widoczne? 4. W jaki sposób operator się finansuje? Jeśli finansowanie obejmuje reklamę lub monetyzację danych, czy zadeklarowany cel obejmuje dane osób trzecich powierzone przez profesjonalistę? 5. Jaka jest sytuacja finansowa operatora w perspektywie trzech lub pięciu lat? Czy istnieją czynniki sugerujące rychłą zmianę modelu (oczekujące wejście na giełdę, kończąca się runda finansowania, prawdopodobne przejęcie)? 6. W jakiej jurysdykcji zarejestrowany jest operator? W jakim kraju fizycznie znajdują się serwery? Jeśli się różnią, jakie ustawodawstwo krajowe ma zastosowanie do przetwarzania? 7. Co by się stało, gdyby nakaz wywiadowczy ważny w jurysdykcji operatora zażądał wydania moich danych? Czy firma mogłaby go technicznie wykonać? 8. Jaką zdolność techniczną zachowuje operator, by zawiesić, zablokować lub usunąć usługę? Na jakich przesłankach umownych? Na jakich przesłankach pozaumownych historycznie udokumentowanych? 9. Jaki plan wyjścia istnieje, gdyby operator skorzystał z tej zdolności przeciwko mnie, słusznie czy niesłusznie? Czy istnieje udokumentowana procedura eksportu danych do alternatywnego dostawcy? 10. Kto kontroluje poświadczenia dostępu? Czy operator może je zresetować bez mojego udziału? Czy to mnie chroni, czy naraża? 11. Czy istnieje europejska, samodzielnie hostowana alternatywa lub taka bez serwera pośredniczącego dla tej konkretnej funkcji? Jaki jest jej rzeczywisty koszt w porównaniu z ocenianym ryzykiem? 12. Gdyby dzisiejszą decyzję zbadał za pięć lat inspektor, audytor lub klient dotknięty naruszeniem, czy obecny wybór dałoby się obronić argumentami dostępnymi dziś, czy też wymagałby przeprosin za niezadanie rozsądnych pytań? Pytania nie oczekują odpowiedzi doskonałych. Oczekują odpowiedzi uczciwych, których uczciwy operator potrafi udzielić, a mniej uczciwy operator unika precyzyjnego ich sformułowania. Operacyjna różnica między dwiema klasami operatorów, mówimy to bez dramatyzowania, daje się zwykle dostrzec, czytając powoli odpowiedzi, których udzielają dobrowolnie, jeszcze zanim trzeba poprosić o więcej. --- Tym artykułem zamykamy drugi cykl Cuadernos Lacre. Zaczęliśmy od długu redakcyjnego odziedziczonego po Schrems II, a kończymy kwestionariuszem operacyjnym. Po drodze przeszliśmy przez pojęcia — hasz, szyfrowanie, tożsamość — oraz analizy stosowane — kill switch, model biznesowy, self-hosting. Deklarowanym zamysłem redakcyjnym publikacji nie było przytłaczanie czytelnika wyczerpującą listą problemów, lecz wręczenie mu narzędzi, by potrafił rozróżnić, wobec każdej nowej usługi, jaki rodzaj odpowiedzi przyjmuje. To rozróżnienie — między architekturą a obietnicą — jest tym narzędziem. Resztę każdy profesjonalista odda na usługę danych, które uzna w swojej praktyce za godne tego pytania. Źródła i dodatkowa lektura - Ta publikacja, cykl 2 (maj 2026) — Schrems II pięć lat później, Czym naprawdę jest SHA-256, Kill switch i przejęcie instytucjonalne, Szyfrowanie end-to-end wyjaśnione naprawdę, Model biznesowy jako sygnał zaufania, 24 słowa: czym jest tożsamość kryptograficzna, Self-hosting jako praktyka zawodowa. Siedem artykułów, na których opiera się ten kwestionariusz. - Rozporządzenie (UE) 2016/679 — Ogólne rozporządzenie o ochronie danych. Referencyjne ramy prawne dla wszystkich pytań, które stawia kwestionariusz, w szczególności artykuły 5, 6, 25, 28, 32, 33 oraz rozdział V. - Europejska Rada Ochrony Danych — wytyczne i opinie operacyjne dotyczące Schrems II, transferów międzynarodowych, ocen skutków i proaktywnej rozliczalności (publikacje 2020–2024). - Hiszpańska Agencja Ochrony Danych — sankcje opublikowane w latach 2022–2024 wobec administratorów danych za nieodpowiednie instrumenty transferu lub za formalne oceny skutków bez merytorycznej treści. - noyb.eu — Europejskie Centrum Praw Cyfrowych, kierowane przez Maximiliana Schremsa. Publiczne repozytorium skarg, środków odwoławczych i analiz dotyczących rzeczywistego, a nie pozornego przestrzegania europejskich norm ochrony danych. --- Cuadernos Lacre · Publikacja Menzuri Gestión S.L. · napisana przez R.Eugenio · redagowana przez zespół Solo2. https://solo2.net/pl/zeszyty/