DPO On Demand

Biti ali ne biti (prijazen obiskovalcu) – to je sedaj vprašanje?

Kolegica Tina je v svojem komentarju na sodbo EČSP v zadevi Fashion ID (Všečkati ali ne všečkati – to je zdaj vprašanje)(1) lepo obdelala dileme, ki jih sodba predstavlja za upravitelje spletnih strani, ki na le-teh uporabljajo kateregakoli od mehanizmov »lajkanja«, »endorsanja« in »šeranja«, pa tudi dileme spletnega gostovanja ali nalaganja Googleovih pisav(2).

Ne morem reči, da se ne strinjam z izpostavljenimi dilemami, kljub temu pa mi dovolite, da izpostavim vpliv na še enega udeleženca v zgodbi, to je posameznika obiskovalca, ki (bolj ali manj načrtno) zajadra na ponudnikove spletne strani.

Dasiravno sem sicer pogosteje v vlogi svetovalca, kako spletne strani (in tudi ostale storitve IKT) narediti čimbolj skladne, pa se bom tokrat postavil v vlogo tistega, ki – kar se da striktno – zagovarja pravico posameznika.

Da se izognemo dilemam glede skupinskih dostopov(3), predlagam, da se pri razmišljanju omejimo in za primer tega komentarja vzamemo posameznika, ki do spletišča dostopa iz zasebnega mobilnega telefona, na katerem ima svoj IP naslov recimo 1.2.3.4. V tem primeru verjamem, da se strinjate z menoj, da lahko IP naslov tretiramo kot osebni podatek, saj je posameznik sicer psevdonimiziran, a povsem določljiv(4).

Ko se posameznik odloči obiskati neko spletno stran, bo njegov brskalnik od upraviteljevega spletnega strežnika najprej zahteval in pridobil osnovni dokument HTML(5), ki brskalniku predstavlja neko okostje in navodilo, kaj vse mora še zahtevati, da lahko spletno stran prikaže v vsej njeni lepoti.

Že na tem mestu bo upraviteljev spletni strežnik zabeležil zapis o prevzemu dokumenta(6). Skoraj vedno je zabeležen čas, IP naslov in status posredovanja, običajno pa so tu še informacije o brskalniku in operacijskem sistemu obiskovalca.

Potem pa bo brskalnik analiziral zahteve v prejetem HTML dokumentu in po potrebi zahteval še dodatne elemente spletne strani, kot so slike, pisave, skripte,…; ti elementi pa se že lahko (a ne nujno) nahajajo na strežnikih drugih ponudnikov, ki seveda vsako zahtevo vestno zabeležijo.

Kot primer: če je na spletišču zavetišča za živali objavljen Facebookov gumbek »Like«, bo Facebook vsaj trikrat dobil posameznikov IP naslov in še nekaj že omenjenih podatkov, ki običajno sodijo v zahtevo po protokolu HTTP(7). Pomembno je poudariti, da bodo ti podatki Facebooku na voljo še preden bo obiskovalec sploh imel možnost prebrati spletno stran in se odločiti za všečkanje ali ne – obiskovalec v tem primeru nima skoraj(8) nobene možnosti vplivati na to, ali bo Facebook dobil njegov IP ali ne.

Iz gornjega sledi, da ima tehnično vse niti pri odločanju o tem, katere dodatne elemente in s katerih strežnikov bo brskalnik moral pridobiti, da bo spletna stran pravilno prikazana (s tem pa tudi nad tem, komu bodo IP naslovi obiskovalcev posredovani), ponudnik spletne strani (oz. spletni mojster, ki je za ponudnika pripravil spletišče). S tem pa tudi odgovornost.

Dobršen del teh dilem je na spletišču mogoče rešiti že tehnično, če je seveda spletni »mojster« res mojster in je naročnik spletne strani seveda to pripravljen plačati. Ko se – v pripravi spletišč – pogovarjam z različnimi naročniki, dostikrat ugotovim, da tudi izražene želje niso nujno tisto, kar res potrebujejo (le redki recimo v resnici rabijo vso širino funkcionalnosti Google Analytics – stari dobri Webalyzer jim že povsem zadošča).

Z dobrimi ponudniki spletnega gostovanja se je tudi povsem preprosto dogovoriti, da so logi na voljo zgolj za potrebe varovanja spletišča ter, da so avtomatsko dostopni tudi lastniku spletišča. Ko upravljavce ob tem opomnim še, da vsak dodaten modul v njihovem CMS predstavlja dodatno možnost za kibernetski vdor in višje stroške vzdrževanja, pa dostikrat naletim na odobravanje tudi po tej plati.

Seveda bi bil idealist, če bi trdil, da je vse opisane dileme mogoče urediti samo s tehniko. Prav tako bi si gotovo pridobil tudi nalepko ludista, če bi trdil, da naj se vse spletne strani vrnejo na čas, ko ni bilo skupnih pisav, »lajkanja«,…. Priznati moram tudi, da bi bil kot informatik precej bolj vesel nekoliko bolj razmejene (digitalne) odločitve sodišča (saj veste: če je to, je eno, sicer nekaj drugega).

Zato pričujoče mnenje niti približno ni nasprotovanje izvornemu članku, ampak spodbuda k razmisleku, kaj je mogoče narediti na način, da kot ponudnik strani ne bomo izpostavljali ne sebe, ne naših obiskovalcev. Prepričan sem, da bodo slednji vedno bolj znali ceniti in nagraditi našo prijaznost in pripravljenost varovati njihovo zasebnost.

Primož Govekar, CISO, Ascaldera d.o.o.

Komentar ne izraža mnenja Ascaldere ali Info Hiše.

[3] https://www.mediapost.com/publications/article/320518/gdpr-got-it-wrong-ip-address-is-not-personal-data.html

[4] Splošna uredba, člen 4.

[5] HyperText Markup Language

[6] V danem primeru osnovnega dokumenta. Teoretično je mogoče zapisovanje obiskov tudi izključiti, vendarje v praksi praviloma vključen, ker se uporablja za analizo uspešnosti postrežbe in delovanja strežnika.

[7] HyperText Transfer Protocol

[8] Nekaj malega lahko vpliva na to, da namesti različne dodatke (npr. NoScript) v brskalnik, vendar to lahko vpliva na prejeto jedrno vsebino in obliko strani.