Implementacija zahtev GDPR za spletna mesta in servise
12 naročnikov
12 naročnikov
Ker opažam, da je okoli implemetacije zahtev uredbe GDPR za spletna mesta in servise kar nekaj zmede, bom z vami delil način moje tehnične in vsebinske implementacije na primeru tega foruma. Dodal bom še videnje glede nekaterih drugih tem, na katere sem naletel pri raziskovanju. O nejasnostih, na katere sem naletel pri raziskovanju, sem se posvetoval s pravniki iz JK Group. Bom v nadaljevanju posebej označil, kjer sem upošteval njihovo mnenje.
GDPR in piškotki?
Za začetek en debunk. V nasprotju z večinskim (po mojih opažanjih) mnenjem uredba GDPR v ničemer ne spreminja obvestil o rabi piškotkov. Torej, implementacija obvestila o piškotkih, ki bi bila GDPR compliant, ne obstaja, ker ta uredba o shranjevanju na terminalsko opremo uporabnika (157. člen ZEKom-1) ne govori nič. Obvestila o piškotkih bi morala ostati enaka. Lahko pa jih združite s pridobivanjem soglasij za obdelavo osebnih podatkov.
Osebni podatki, ki jih obdelujem sam
Uporabniški račun
V postopku registracije uporabnika zbiram naslednje podatke:
- Uporabniško ime
- E-poštni naslov
V svoj profil lahko opcijsko kasneje vnesete še naslednje podatke:
- Spol
- Kontaktne podatke
Uporabniško ime in e-poštni naslov
Uporabniško ime načeloma ni OP (osebni podatek), razen če veš, kdo ga uporablja. Ker ga uporabljamo v povezavi z IP naslovom, je OP, tudi če nimamo imena in priimka. E-poštni naslov potrebujemo za komunikacijo z uporabniki (primer: možnost ponastavitve gesla). To je tudi zakoniti interes za obdelavo teh osebnih podatkov. (mnenje JK Group) V postopku registracije za potrebe kasnejšega dokazovanja shranimo tudi IP naslov in čas registracije.
Spol
Podatek o spolu uporabnika uporabljamo striktno samo za prikazovanje pravilne slovnične spolne oblike obvestil na forumu. Osnovno segmentiranje za potrebe slovnice ni profiliranje, zato soglasja ne potrebujemo. (mnenje JK Group)
Kontaktni podatki
Vsak uporabnik lahko vnese svoje kontaktne podatke in jim določa stopnjo vidnosti. Kontaktne podatke, ki so vidni samo med povezanimi uporabniki, se drugemu uporabniku prikažejo samo po sistemu zahteve in potrditve. Tule beležim samo čas potrditve dostopa, ne pa IP naslova, ki verjetno ni potreben, glede na to, da lahko potrjujete te zadeve samo takrat, ko ste prijavljeni s svojim uporabniškim računom.
Dnevniški zapisi
Strežniški
V strežniške dnevniške zapise beležimo IP naslove dostopov, kot pač to počne vsak spletni strežnik - v našem primeru nginx.
Za beleženje IP naslova v dnevniške zapise imamo zakoniti interes zaradi zagotavljanja ustrezne stopnje varnosti spletnega strežnika in storitev, ki gostujejo na strežniku. (mnenje IP RS številka 0712-1/2018/96 - žal ni javno objavljeno, svoje vprašanje in odgovor nanj mi je posredoval kolega)
Forum
Na forumu beležimo tudi IP naslove posameznih prijav in objav.
Tu imamo enak zakoniti interes kot pri strežniških dnevniških zapisih. (mnenje JK Group)
Osebni podatki, ki jih obdelujejo pogodbeni obdelovalci
Spletna analitika
Za spletno analitiko uporabljamo servis Google Analytics (GA). Pri implementaciji tega sem se opiral na članek 5 Actionable Steps to GDPR Compliance with Google Analytics.
Nobenih OP
V GA ne shranjujte nobenih OP, kar pa je tako ali tako že prej bilo prepovedano po njihovih pravilih uporabe.
Anonimizirajte IP naslov
Za analytics.js
kodo to storite tako:
ga('send', 'pageview', {
'anonymizeIp': true
});
Več o tem in več možnosti v Googlovi dokumentaciji o IP Anonymization
Anonimizacija IP naslovov vam malenkost zmanjša pravilnost geografske segmentacije uporabnikov. Lahko se tudi odločite za pridobivanje soglasja za obdelavo tega OP, jaz se nisem.
Izključite Advertiser Features
Izključite Advertiser Features (AF).
Pridobivanje soglasja
Jaz bom od obiskovalcev pridobival soglasje za anonimno segmentiranje (demographics, interests).
Ko bom od obiskovalca imel soglasje, bom za tega obiskovalca ročno vključil AF v GA kodi.
Za analytics.js
kodo to storitev tako, da med
ga('create', 'UA-XXXXXX-XX', 'example.com');`
in
ga('send', 'pageview');`
vključite vrstico:
ga('require', 'displayfeatures');
Nejasnosti
Nejasno je, kaj je z anonimnim tracking IDjem, če ga GA uporablja res samo za anonimizirano spremljanje posameznega obiska. Več o dilemi v zgoraj objavljenem članku.
Jaz sem se odločil, da tega ne smatram kot obdelavo OP in tu še naprej smiselno uporabljam smernice IP RS o piškotkih. (mnenje JK Group)
Spletno oglaševanje
Za serviranje oglasov na forumu uporabljam DoubleClick for Publishers (DFP). Opisal bom samo za ta primer, ker drugih ne poznam, vendar se zadeva lahko smiselno prenese tudi na ostale servise.
Izključite personalizirane oglase
To storite v DFP v menuju Admin -> EU user consent.
Pridobivanje soglasja
Jaz bom od obiskovalcev za prikazovanje personaliziranih oglasov pridobival soglasje.
To storite tako, da za tiste obiskovalce, od katerih še niste pridobili soglasja, uporabite naslednjo kodo:
googletag.pubads().setRequestNonPersonalizedAds(1);
Ko ste pridobili soglasje, samo vrednost parametra metodi .setRequestNonPersonalizedAds()
nadomestite z vrednostjo 0
.
Sledenje soglasjem
Soglasij ne shranjujte v piškotke, saj boste tako težko karkoli dokazovali, saj se piškotki shranjujejo pri uporabniku, ne pri vas. Shranite IP naslov in čas pridobitve soglasja. Za hranjenje teh informacij imate zakoniti interes z namenom dokazovanja soglasja. (mnenje JK Group)
Jaz sem tehnično to rešil tako, da vam ob pridobitvi prvega soglasja dodelim unikaten hash (v piškotek s trajanjem 10 let), posamezna soglasja (glede na namen), tudi vsako spremembo (torej morebitno umaknitev soglasja), pa potem beležim v bazo skupaj z IP naslovom in časom spremembe.
E-mail marketing
Tega se na forumu ne grem, sem pa med raziskovanjem naletel na nekaj informacij glede tega, pa jih bom tudi delil z vami.
Za obdelavo e-poštnih naslovov za namen pošiljanja, recimo, e-novic lahko smiselno uporabite pravno podlago (zakoniti interes) iz zakonov, ki ste jih uporabljali do sedaj. Primer, svojim strankam lahko še vedno pošiljate obvestila (zakona in člena ne vem ZEKom-1, 158. člen, 2. odstavek), naročnikom na vaše novice lahko te novice še vedno pošiljate, seveda pod pogojem, da imate od njih dokazljivo soglasje, ki pa ste ga tako ali tako po zakonu (zakona in člena ne vem ZEKom-1, 158. člen, 1. odstavek) morali imeti tudi pred uvedbo GDPR, in tako dalje.
Pred nekaj dnevi sem v Facebook skupini Slovenski developerji zasledil povezavo na zanimiv rant glede tega: GDPR: You’re Doing it All Wrong!
Ostalo
Ali imate primer svoje implementacije tudi za kakšno drugo področje, ki ga na forumu nimam? Imate za zgoraj opisane implementacije mogoče boljšo rešitev? Se po vašem mnenju kje motim? Opišite to v odgovoru na to objavo, pa bom povezave do teh vaših implementacij zaradi boljše preglednosti objavil tule spodaj v seznamu.
- Vprašanje glede dobe hrambe OP? (Mika)
Pravila
Za odgovarjanje in komentiranje te objave smiselno uporabljajte pravila uporabe foruma. V odgovore pišite le konstruktivne odgovore, ki prispevajo k dobri debati. Komentarji, zahvale, zahtevki za dodatna pojasnila spadajo v komentarje objav. Za konkretna nova vprašanja odprite novo debato, ne hijackajte teme.
Seznam urejanj
- 23. maj 17:13 - dodal sklice na zakone glede e-mail marketinga
12 odgovorov
Super napisano.
Manjka sicer ena ključna stvar - doba hrambe podatkov.
Potrošnika je treba seznaniti, koliko časa se hranijo njegovi podatki, kar pa je odvisno od pravne podlage za hrambo.
Pri meni bodo glede na pravno podalgo roki sledeči:
V primeru oddaje naročila se vaši osebni podatki, torej ime, priimek, naslov, telefonska številka in e-poštni naslov, ter v primeru naročila na podjetje tudi ime in davčna številka podjetja, za potrebe trženja hranijo:
• 30 dni, v kolikor naročila niste dokončali oziroma ga potrdili
• 30 dni, v kolikor ste naročilo dokončali, a ga nato preklicali oziroma naročenega niste prevzeli
• 365 dni, v kolikor ste naročilo dokončali in naročeno blago tudi prevzeli
Po preteku omenjenega obdobja se vaši osebni podatki avtomatično v celoti izbrišejo, razen izdanega računa...
Za forum se mi zdi smiselno, da se uporabnika izbriše po 1 letu od zadnje prijave.
Me pa zanima, koliko časa se hrani e-mail korespondenco? V primeru spletne prodaje ne vidim razloga, da bi korespondenco hranil dlje od 1 leta, glede na to, da nimam pogodb, ki bi veljale daljše obdobje.
Odlična tema. Sem dodal med povezave v izvirno objavo. Glede foruma in hrambe podatkov uporabniškega računa je pa vprašanje, če je najboljša možnost, da bi se zadeve samodejno brisale po nekem pretečenem obdobju. Sem že imel primere, ko so še po več letih želeli obnoviti svoj izviren račun. Če po enem letu brišem vse podatke tega računa, nimam prav nobene možnosti za obnovitev v takih primerih. – Vini
Ima kdo informacijo glede pošiljanja newsletterjev kupcem? Oziroma zakonsko podlago, ki je Vini ne pozna? Je bil potreben explicit consent ali je bila dovolj navedba v splošnih pogojih?
Nekateri so že objavili svoje politike zasebnosti, najbolj zanimiv pristop ima Sensilab - https://www.sensilab.si/politika-zasebnosti
Ali se komu sanja, kaj bi lahko bil zakonit interes pri Facebook Custom Audience in podobnih, kjer praktično večina navaja, da je za takšne storitve obvezen opt-in? :)
@wackmofo
Potreben je explicit consent za vse.
Ni dovolj samo v splošnih pogojih
Zato tudi zadnje tedne imaš bombandiranje z ponovno potrditvijo.
Ker je dokazno breme na tebi, kot controllerju, in si vsi krijejo rit z ponovno reconfirmacijo, saj prej noben ni zbiral dokaza o privoljenju.
@Vini
NICE!
@OvcaX ja, zato mi je zadeva sumljiva, ampak glede na ZEKom-1, ki dovoljuje pošiljanje kupcem, se mi ne zdi sporno. Pri kupcih namreč lahko dokažem datum, čas in razlog prijave.
Zanima me, če se je že kdo ukvarjal kako ravnati v primeru ko ima spletna stran zgolj povpraševalni obrazec (osebni podatki se hranijo v bazi). Sam sem razmišjal, da bi na kontaktni obrazec dodal checkbox s katerim bi uporabnik potrdil, da ga lahko kontaktiramo (mu odgovorimo na povpraševanje - seveda ga ne mislimo avtomatsko prijaviti na newsletter). Pravico do pozabe in anonimizacijo pa bi izpeljal po principu, da jo lahko zahteva samo z maila navedenega v kontaktnem obrazcu? Gre moje razmišanje v pravo smer ali si delam premalo/preveč skrbi? Zasledil sem tudi da bi naj lastniki spletnih strani sklenili pogodbe s hosting providerji glede GDPR ne glede na to ali so na shared/VPS gostovanju? Nekateri providerji izdajajo samo za VPS kako pa je potem s shared gostovanji?
Vini, super spisano.
Mi pa manjka par sklopov:
- pravica do pozabe in izbrisa podatkov (eno je protokol, spisan recimo v pogojih, drugo pa tehnično zagotavljanje - kako boš izbrisal podatke iz vsepovsod ter bil zmožen dokazat da si to res naredil?)
- celotna veriga dovoljenj: glede na to da je na forumu kup ljudi, ki je pogodbeno vpet (one way or another) v obdelavo podatkov in ima dostop do backendov, baz, itd...
Govorim o scenariju tipa: podjetje XXYY za naročnika AABB izdela spletno trgovino. Ima adminski dostop, ki ga sherajo med sabo v podjetju, s tem vidijo naročila uporabnikov ter njihove osebne podatke. V podjetju so redno zaposleni, študentje in dva preko s.p.
Za SMTP za pošiljanje mailov s spletne strani so uporabili Gmail account, preko njega spletna stran pošlje mail kontaktnega obrazca in obrazca za iskanje službe, skupaj s CV datoteko, polno OP ter kopijo maila za naročila.
Za gostovanje uporabljajo enega od parih SLO ponudnikov, recimo mu YYZZ, pri katerem imajo zakupljen VPS. Tam se dela avtomatični backup baze (naj bi spadalo pod obdelavo osebnih podatkov IIRC, zopet mnenje IP), datotek na disku (recimo računov iz ERP). Pa ponudnik ima 20+ zaposlenih, študente, s.p. in zunanje sodelavce, ki skrbijo za HW.
Pa to gre še naprej, veriga je lahko še daljša :)
To sem malo upal, da bo kdo delil z nami, kako je rešil zadevo. :) Jaz ničesar takega ne furam, pa seveda potem nisem šel študirat nič v to smer. – Vini
Kako ne? Si edini ki ima dostop do baze? :)
Za izbris podatkov sem videl pri ostalih da (kao) zadosca neko obvestilo + kontakt, samo kaj pa naprej - bos izbrisal uporabnika, njegove zapise, ZSje (ok, tukaj jih ni vec), itd...
–
perunpro
Edini sem, ki dostopa do baze. Brisal bom pa samo osebne podatke uporabnika, nič drugega. – Vini
Ena stvar, ki sem jo ugotovil za Mailchimp: pri obeh strankah, ki ga uporabljajo, sem pri testnem eksportu opazil, da so na voljo tudi polja datum in ip za prijavo, dodatno (ker imam enablan double opt-in) pa je to še za potrditev. Torej to bi moralo že biti skladno z GDPR, ker imamo potrebne podatke o soglasju?
Če imate double opt-in je sigurno compliant. – LouD
Ce imas ti dostop do baze strank tvojega clienta, potem je tukaj double opt-in se najmanj, lol – perunpro
Kako pa veš, da nimam pogodbe kot obdelovalec? :) – SlimDeluxe
Je to dovolj? Ali bi morala tvoja stranka svojim strankam dopisati se da si pogodbeni podobdelovalec? – perunpro
Z eno stranko smo to naredili v politiki zasebnosti, potem pa je dal stran, ko je videl, da tega noben nima, čeprav zdaj vidim da jih mimovrste ima lepo zlistane :) https://www.mimovrste.com/osebni-podatki – SlimDeluxe
@wackmofo
Ker imamo tako super vlado smo mi v vicah in nimamo še novega zakona.
Bo pa predvidoma septembra zato jaz osebno sledim GDPR
Kako je zdaj s to kontakt formo (ne newsletter- tu je jasno) katera se ne shranjuje v nobeno bazo?
Ker če bi tu rabil consent, potem bi ga moral po neki kmečki logigi tudi pri objavljeni telefonski številki in fiksnem naslovu, saj te lahko kdo celo pokliče ali pošlje pismo katerega dostavi poštar Janez :)
Tvoj inbox je tudi vrsta "baze". Pomoje napiši tako kot je tu: https://pagefair.com/privacy/ , prva vrstica v tabeli. – SlimDeluxe
Hvala za tole :)
Lahko bi kak dan prej tole spisal ampak vseeno super ;) – LouD 23. maj 2018 ob 14:02