Stvarna naspram prividne privatnosti: pitanja koja se vrijedi zapitati

Razlika između arhitektonske privatnosti i deklarativne privatnosti

Tijekom prethodnih sedam članaka ovog ciklusa prošli smo kroz različite slojeve iste teme. Pravo međunarodnih prijenosa sa Schrems II. Matematičku ideju kriptografskog sažetka (hash) koji pečati svaki Cuaderno. Arhitektonski izbor kill switcha i institucionalno zarobljavanje koje ga gotovo uvijek prati. Mehanizam enkripcije s kraja na kraj i operativno pitanje gdje se nalaze ključevi. Usklađivanje poticaja prema poslovnom modelu. Samosuvereni kriptografski identitet. Self-hosting kao razmjernu strategiju. Svaki se članak bavio jednim kutom gledanja. Ovaj, posljednji u ciklusu, sjedinjuje ih u upitnik.

Razlikovanje koje vrijedi zapamtiti jednostavno je: postoje usluge čija je privatnost arhitektonska i postoje usluge čija je privatnost deklarativna. Prva je ugrađena u tehnički dizajn: određene povrede obveze privatnosti tehnički su teške ili nemoguće jer ih arhitektura ne dopušta. Druga je položena u tekst pravne obavijesti: određene bi povrede bile ugovorno kažnjive ako se dogode, ali ih tehnički ništa ne sprječava. Oba modela mogu ispunjavati GDPR; ali jedan štiti po konstrukciji, a drugi štiti obećanjem, i razlika je operativno golema.

Pitanja koja slijede osmišljena su tako da razlikuju jedan slučaj od drugoga. Nisu napredna tehnička pitanja. To su pitanja na koja svaki pošten pružatelj može odgovoriti u svojoj javnoj dokumentaciji. Kvaliteta i preciznost odgovora govori o proizvodu jednako koliko i sam odgovor. Pitanja se grupiraju u šest slojeva; vrijedi ih postaviti sva prije prihvaćanja usluge za osjetljive podatke, ne samo ona koja prepoznaje prvi instinkt.

1. sloj: arhitektura

Prije nego nastavimo, definirajmo jedan pojam. Pod operaterom podrazumijevamo tvrtku koja pruža uslugu: subjekt koji kontrolira poslužitelje i softver, a ne konkretnu osobu. Kada je to razjašnjeno, temeljno arhitektonsko pitanje glasi: što operater radi sa sadržajem između pošiljatelja i primatelja? Postoje tri moguća odgovora i vrijedi ih znati razlikovati, jer se sva tri ponekad oglašavaju sličnim rječnikom.

• Prvi: sadržaj prolazi kroz operaterov poslužitelj u otvorenom obliku, gdje ga operater može čitati iako obeća da to neće činiti.
• Drugi: sadržaj prolazi kroz operaterov poslužitelj šifriran, gdje ga operater ne može čitati ako ključevi prebivaju isključivo u uređajima korisnika.
• Treći: sadržaj ne prolazi kroz nijedan operaterov poslužitelj, jer u tom konkretnom toku operaterov poslužitelj ne postoji.

Razlika između ova tri nije razlika u stupnju: razlika je u vrsti.

Dopunsko pitanje — već postavljeno u Cuaderno o enkripciji — glasi: tko ima kriptografske ključeve koji omogućuju čitanje sadržaja? Ako ih ima korisnik i samo korisnik, enkripcija je stvarna. Ako ih osim toga ima operater u bilo kojem obliku — pa makar pod nazivom „oporavak računa” ili „sinkronizacija među uređajima” —, enkripcija je nominalna. Pitanje ne dopušta pošten posredan odgovor.

2. sloj: poslovni model

Pitanje o poslovnom modelu važno je jednako koliko i arhitektonsko pitanje, i to iz istog suštinskog razloga: poticaji tijekom vremena proizvode sustavno različite proizvode čak i uz istovjetne deklarirane svrhe. Kako operater danas zarađuje novac? Jedan izvor, dva, mješavina? Ako financiranje uključuje oglašavanje ili monetizaciju podataka, koji se podaci monetiziraju i na kojoj se pravnoj osnovi GDPR-a to čini? Pokriva li svrha deklarirana u pravnoj obavijesti podatke trećih osoba koje stručnjak namjerava povjeriti usluzi?

I pitanje drugog reda, ne uvijek postavljeno: kakva je financijska situacija operatera u perspektivi tri do pet godina? Tvrtka u fazi rizičnog kapitala posluje pod drugačijim pritiscima nego tvrtka sa stabilnom profitabilnošću. Promjena modela financiranja opetovano je trenutak u kojem se prešutni ugovor s korisnicima iznova ispisuje bez pregovaranja.

3. sloj: jurisdikcija

Za europskog stručnjaka pitanje jurisdikcije nije retoričko. U kojoj je jurisdikciji operater registriran? U kojoj se zemlji fizički nalaze poslužitelji koji obrađuju podatke? Je li odgovor na oba prethodna pitanja isti ili različit, i ako se razlikuje, koje se zakonodavstvo primjenjuje? Europska regija kojom upravlja američka tvrtka nije, za potrebe Schrems II, europski odgovor: tvrtka podliježe FISA-i 702 neovisno o tome gdje se poslužitelji nalaze.

Dopunsko operativno pitanje glasi: kad bi sutra stigao obavještajni nalog valjan u jurisdikciji operatera koji traži predaju mojih podataka ili podataka mojih klijenata, što bi se dogodilo? Ako pošten odgovor počinje s „tvrtka bi ih bila dužna predati”, usluga ne štiti od tog naloga koliko god oglašavanje sugeriralo suprotno. Ako pošten odgovor počinje s „tvrtka ih ne bi mogla predati jer ih nema u otvorenom obliku”, usluga štiti; a razlika ovisi gotovo u potpunosti o prva dva sloja, a ne o kvaliteti politike privatnosti.

4. sloj: operater i kill switch

Koju tehničku sposobnost operater zadržava za daljinsku obustavu, blokiranje, uklanjanje ili pogoršanje usluge? Pitanje nije paranoično: ono je operativno. Digitalne su platforme tu sposobnost u posljednjih nekoliko godina opetovano koristile, ponekad na vlastitu inicijativu, drugi put po nalogu vlada, drugi put nakon promjena vlasništva ili politike. Ako sposobnost postoji, vrijedi znati pod kojim se ugovorno deklariranim pretpostavkama izvršava, te zadržati pričuvu za nedeklarirane pretpostavke koje je praksa posljednjih godina pokazala jednako relevantnima: neočekivani sudski nalog, međunarodna sankcija, promjena korporativnog upravljanja, preuzimanje od strane subjekta s drukčijom politikom.

Sestrinsko je pitanje pitanje plana kontinuiteta: kad bi operater tu sposobnost upotrijebio protiv stručnjaka — iz bilo kojeg razloga, opravdanog ili ne —, koliko bi vremena rada ostalo dostupno, koji postupak izvoza podataka postoji i kojem bi se alternativnom pružatelju moglo migrirati? Ako odgovor počinje s „to se ne bi smjelo dogoditi”, to nije operativni odgovor; to je obećanje.

5. sloj: identitet i pristup

Tko kontrolira pristupne vjerodajnice za uslugu? Ako operater može ponovno uspostaviti korisnikov pristup bez sudjelovanja korisnika — postupak koji se obično naziva „oporavak računa” —, operater je, tehnički, skrbnik računa i može ga također ustupiti onome tko to zatraži putem odgovarajućeg postupka. Ako operater ne može ponovno uspostaviti pristup jer identitet kriptografski prebiva u korisnikovu uređaju, operater ga ne može ni ustupiti, čak ni po nalogu. Oba su načina, ovisno o kontekstu, legitimna; ali, još jednom, različiti su i vrijedi znati koji se prihvaća.

Što se događa s podacima stručnjaka ako stručnjak izgubi pristup? Postoje li mehanizmi oporavka — računa, datoteke, sesije — koji ovise o operateru? Jesu li ti mehanizmi spojivi s profesionalnom deontologijom struke ako je operater prisiljen da ih upotrijebi?

6. sloj: budućnost

Taj se posljednji sloj često zanemaruje jer zahtijeva projekciju. Što bi se dogodilo kad bi uslugu preuzela druga tvrtka? Gotovo sva preuzimanja sa sobom u sljedećim mjesecima nose reviziju uvjeta usluge. Što bi se dogodilo kad bi se regulatorni zahtjevi promijenili? Europsko je pravo od 2022. obveze uklanjanja i blokiranja povećalo, a ne smanjilo. Što bi se dogodilo kad bi operater nestao? Znatan dio usluga u oblaku nema dokumentiran izlazni plan za scenarij prestanka rada operatera; stručnjak otkriva problem kad više nema vremena da se za njega pripremi.

Postoji formulacija koju za ovaj sloj vrijedi zapamtiti: arhitekture koje manje ovise o operateru otpornije su na promjene operatera. Self-hosting u bilo kojem od svojih oblika, samosuvereni kriptografski identitet, komunikacija bez poslužitelja u sredini — sve to smanjuje buduću površinu rizika postupkom smanjivanja sadašnje površine ovisnosti. Ne uklanja je; smanjuje je.

Razlika između strukture i obećanja

Kad bismo cijeli ciklus morali destilirati u jednu jedinu rečenicu, ona bi glasila ovako: strukturni se odgovori održavaju iako se operater, uprava ili zakonodavstvo promijene; odgovori temeljeni na obećanju održavaju se dok onaj tko obećava može i želi ih održati. Oba mogu biti ispravna u trenutku prihvaćanja. Samo se jedan od njih održava neovisno o protoku vremena i promjeni okolnosti.

To ne znači da svaki stručnjak mora zahtijevati strukturne odgovore od svih usluga koje prihvaća. Razmjernost ostaje legitimna: proračunska tablica za interno knjigovodstvo ne treba isti odgovor kao klinički karton pacijenta. Znači, doduše, da se profesionalnost sastoji u tome da se zna kakva je vrsta odgovora u svakom slučaju prihvaćena, te da se svjesno odlučilo da je ta vrsta odgovora razmjerna konkretnom podatku.

Upitnik, posložen

Dvanaest konkretnih pitanja koja sintetiziraju ciklus, posloženih tako da odgovor na svako od njih oblikuje sljedeće:

1. Prolazi li sadržaj kroz operaterov poslužitelj? Ako prolazi: u otvorenom obliku, šifriran ključevima operatera ili šifriran ključevima isključivo korisnika?
2. Ako se poziva na enkripciju s kraja na kraj (end-to-end), gdje se nalaze kriptografski ključevi? Poznaje li ili čuva operater bilo koji njihov dio u bilo kojem obliku, uključujući „oporavak”?
3. Koje metapodatke usluga generira i čuva? Koliko dugo? Kome su vidljivi?
4. Kako se operater financira? Ako financiranje uključuje oglašavanje ili monetizaciju podataka, pokriva li deklarirana svrha podatke trećih osoba koje povjerava stručnjak?
5. Kakva je financijska situacija operatera u perspektivi tri do pet godina? Postoje li čimbenici koji upućuju na neposrednu promjenu modela (predstojeći izlazak na burzu, krug financiranja koji se iscrpljuje, vjerojatno preuzimanje)?
6. U kojoj je jurisdikciji operater registriran? U kojoj se zemlji fizički nalaze poslužitelji? Ako se razlikuju, koje se nacionalno zakonodavstvo primjenjuje na obradu?
7. Što bi se dogodilo kad bi obavještajni nalog valjan u jurisdikciji operatera zatražio predaju mojih podataka? Bi li ga tvrtka mogla tehnički ispuniti?
8. Koju tehničku sposobnost operater zadržava za obustavu, blokiranje ili uklanjanje usluge? Pod kojim ugovornim pretpostavkama? Pod kojim neugovornim, povijesno dokumentiranim pretpostavkama?
9. Koji izlazni plan postoji ako bi operater tu sposobnost upotrijebio protiv mene, opravdano ili neopravdano? Postoji li dokumentiran postupak izvoza podataka alternativnom pružatelju?
10. Tko kontrolira pristupne vjerodajnice? Može li ih operater ponovno postaviti bez mojeg sudjelovanja? Štiti li me to ili me izlaže?
11. Postoji li za ovu konkretnu funkciju europska, samostalno hostirana alternativa ili alternativa bez poslužitelja u sredini? Koji je njezin stvarni trošak u usporedbi s procijenjenim rizikom?
12. Kad bi današnju odluku za pet godina ispitivao inspektor, revizor ili klijent pogođen povredom podataka, bi li trenutačni izbor bio obranjiv argumentima dostupnima danas, ili bi zahtijevao ispriku zbog nepostavljanja razumnih pitanja?

Pitanja ne očekuju savršene odgovore. Očekuju poštene odgovore, koje pošten operater zna dati, a manje pošten operater izbjegava precizno formulirati. Operativna razlika između dviju vrsta operatera, kažemo to bez dramatiziranja, obično se zamjećuje polaganim čitanjem odgovora koje pružaju dobrovoljno, još prije nego što treba zatražiti više.

---

Ovim člankom zatvaramo drugi ciklus Cuadernos Lacre. Počeli smo uredničkim dugom naslijeđenim iz Schrems II, a završavamo operativnim upitnikom. Usput smo prošli kroz pojmove — sažetak (hash), enkripciju, identitet — i primijenjene analize — kill switch, poslovni model, self-hosting. Deklarirana urednička namjera publikacije nije bila preplaviti čitatelja iscrpnim popisom problema, nego mu uručiti alate da kod svake nove usluge razazna kakvu vrstu odgovora prihvaća. To razlikovanje — između arhitekture i obećanja — jest taj alat. Ostalo će svaki stručnjak staviti u službu onih podataka koje u svojoj praksi smatra vrijednima tog pitanja.