Brisanje in izvoz zgodovine klepetalnika: Varen nadzor uporabnikov

Zgodovina pogovorov v klepetalniku je za uporabnike priročna: omogoča jim ponovno branje odgovorov, poznejše nadaljevanje pogovora ali predajo informacij podpori. Vendar lahko ista zgodovina vsebuje številke naročil, opise težav, kontaktne podatke ali druge občutljive podatke. Tisti, ki shranjujejo pogovore, zato potrebujejo več kot le neopazno stikalo »zgodovina«. Uporabniki morajo razumeti, kateri podatki obstajajo, kako jih lahko vzamejo s sabo, jih izbrišejo ali prekličejo nadaljnji dostop.

Ta vodnik prikazuje izvedljiv produktni in tehnični model za spletne klepetalnike. Združuje uporabniško izkušnjo, najmanjšo možno količino podatkov, varno preverjanje identitete in sledljiva stanja sistema. Ti napotki ne predstavljajo individualnega pravnega svetovanja; konkretne obveznosti so med drugim odvisne od namena, pravne podlage, sistemske arhitekture in zadevnih podatkov.

Štiri funkcije namesto enega samega stikala za zgodovino

»Upravljanje zgodovine« je preveč nejasen pojem. V uporabniškem vmesniku in v ozadju (backend) je treba ločiti štiri različne namene:

• Pregled: Uporabniki berejo shranjene pogovore, priponke in prepoznavne metapodatke v razumljivi kronologiji.
• Izvoz: Prejmejo kopijo v berljivem formatu ter, če je to za posamezen primer smiselno ali pravno zahtevano, dodatno še v strukturiranem strojno berljivem formatu.
• Brisanje: Odstranijo posamezne pogovore ali celotno dodeljeno zgodovino. Vmesnik pojasnjuje obseg, roke in možne izjeme.
• Preklic dostopa: Razveljavijo povezave za skupno rabo, znane naprave ali žetone za ponovno vzpostavitev seje, ne da bi pri tem nujno takoj izbrisali vse vsebinske podatke.

Ta ločitev preprečuje nevarne nesporazume. »Odjava« ne izbriše podatkov o pogovoru. »Skrij zgodovino« ni enako brisanju. In potekla povezava ne pomeni samodejno, da so podatkovni zapisi v ozadju izginili. Poleg tega si velja prebrati naš vodnik o varnem nadaljevanju pogovorov v klepetalniku.

Začnite z jasnim podatkovnim modelom

Preden ekipe oblikujejo gumbe, morajo popisati shranjene objekte. Pogovor se pogosto ne sestoji le iz sporočil. Poleg njih so tu še identifikatorji sej, časovni žigi, povezave do datotek, varnostni dogodki, zahtevki za podporo, povratne informacije in tehnični dnevniki. Za vsak objekt so potrebni dokumentiran namen, odgovorna oseba, pravilo hrambe in pot brisanja.

Splošna uredba o varstvu podatkov (GDPR) v 5. členu med drugim navaja najmanjšo količino podatkov in omejitev hrambe. 15. člen zadeva pravico do dostopa, 17. člen pravico do izbrisa s pogoji in izjemami, 20. člen pa prenosljivost podatkov na ustreznem področju uporabe. Iz tega ne izhaja, da mora vsak vmesnik klepetalnika ponujati enake funkcije. Vendar morajo produktne ekipe podatkovne tokove zasnovati tako, da je mogoče upravičene zahteve zanesljivo obdelati.

Ustrezno preverjanje identitete pred izvozom in brisanjem

Kdor omogoči dostop do zgodovine le prek ugibljive povezave ali ponovno uporabljenega identifikatorja seje, tvega odtekanje podatkov. Hkrati pa preverjanje identitete ne sme splošno zahtevati več osebnih podatkov, kot je potrebno za konkretno dejanje. Končne Smernice EDPB 01/2022 o pravici do dostopa obravnavajo med drugim identifikacijo, obseg in varno zagotavljanje kopij. Odstavek 6 12. člena GDPR dovoljuje dodatne informacije za potrditev identitete, če obstajajo utemeljeni dvomi o identiteti.

V praksi se obnese na tveganju temelječa stopnjevitost. Prikaz psevdonimne kratke zgodovine na isti napravi lahko zahteva veljavno, kratkotrajno sejo. Celoten izvoz, nepreklicno brisanje ali preklic vseh naprav pa bolj upravičujejo ponovno avtentikacijo. Aktualna Smernica NIST za upravljanje sej opisuje ponovno avtentikacijo, časovne omejitve in prekinitev seje kot samostojne kontrolne mehanizme. Končna stopnja varnosti se mora prilagoditi tveganju; pri tem zahteve NIST za ameriške zvezne organe niso splošna pravna obveza za vsako podjetje.

Za javne gradnike in prijavljena območja za stranke mora meja ostati vidna. Naš prispevek o identiteti in dostopu do podatkov v portalu za stranke pojasnjuje, zakaj se javni klepet ne bi smel tiho spremeniti v kanal za podatke o računu.

Izvoz mora biti razumljiv in v celoti pojasnjen

Dober izvoz ni le surov izpis iz podatkovne baze. Začne se s pregledom: obdobje ustvarjanja, vključeni pogovori, priponke, uporabljeni časovni pas in različica formata. Sledijo vsebine v jasnem zaporedju. Format JSON je lahko smiseln za strukturirano nadaljnjo obdelavo; HTML ali PDF pa je za mnoge ljudi lažje berljiv. Ali in v kakšnem obsegu je prenosljiva oblika pravno zahtevana, je treba preveriti za posamezen primer.

Če sistem izvoz ustvari nesinhrono, vmesnik potrebuje jasen status: »v pripravi«, »na voljo do …«, »poteklo« ali »spodletelo«. Povezava za prenise mora biti kratkotrajna, neugibljiva in po uporabi preklicljiva. Skrivnosti, kot so interni pozivi (prompti), dostopni ključi ali podatki drugih oseb, ne sodijo v paket. Pred zagotovitvijo mora filter na strani strežnika preveriti, ali povezave z zahtevki za podporo, deljenimi pogovori ali vsebinami tretjih oseb zahtevajo posebno obravnavo.

Brisanje kot avtomat stanj namesto takojšnje obljube

Gumb s sporočilom »Vse izbrisano« je problematičen, če iskalni indeks, shramba za analitiko, sistem podpore ali varnostna kopija še vedno vsebujejo kopije. Boljša izbira je majhen avtomat stanj (state machine), ki odraža dejanski proces.

Smiselna stanja brisanja

1. Zahtevano: Identiteta in želeni obseg sta potrjena.
2. Zaklenjeno: Zgodovina ni več dostopna za običajno uporabo; žetoni za ponovno uporabo in skupno rabo so neveljavni.
3. V obdelavi: Primarni pomnilnik, iskalni indeks, shramba datotek, analitični in integracijski cilji se zaporedoma čistijo.
4. Zaključeno: Predvideni aktivni sistemi so očiščeni; preostale varnostne kopije so podvržene dokumentirani rotaciji varnostnih kopij ali utemeljeni izjemi.
5. Delno blokirano: Enega od sistemov ni bilo mogoče očistiti ali pa morajo podatki do nadaljnjega ostati shranjeni. Primer se sledljivo eskalira.

Ne pozabite na odvisne podatke

Sporočila se lahko sklicujejo na datoteke, vdelave (embeddings), iskalne indekse, ocene kakovosti, zapise v CRM ali zahtevke za podporo. Zahteva za izbris zato potrebuje stabilno ID zahteve in idempotentne delovne korake: Ponovni zagon ne sme ustvariti novih kopij ali razveljaviti že opravljenih korakov. Za merilne podatke se je treba že pri zasnovi odločiti, ali se lahko ohranijo agregirane kazalniki, ki jih ni več mogoče povezati z uporabnikom. Več o tem si preberite v prispevku o analitiki klepetalnikov z vidika najmanjše možne količine podatkov.

Preklic ščiti predvsem na napravah v skupni rabi

V hotelih, prodajnih prostorih, delavnicah ali družinskih gospodinjstvih se osebe pogosteje menjajo na isti napravi. Zato bi moral »preklic dostopa« omogočati več kot le lokalno brisanje piškotka. Na strani strežnika morajo znani sejni žetoni, povezave za skupno rabo in po potrebi povezave z napravami postati neveljavni. Vmesnik mora razlikovati med »ta naprava«, »vse naprave« in »vse deljene povezave«.

Po preklicu gumb za nazaj ne sme prikazati občutljive zgodovine iz predpomnilnika. Predogledi v obvestilih, samodejno dokončanje v brskalniku in lokalni podatki brez povezave sodijo v preverjanje. Hkrati mora uporabnik prejeti jasno potrditev, kateri dostopi so bili zaključeni in ali so podatki o pogovoru še naprej shranjeni. Tako se preklic ne zamenjuje z brisanjem.

Potrditev izbrisa naj bo dostopna in tolerantna do napak

Nepreklicno dejanje potrebuje mirno in razumljivo potrditev. Razlaga WCAG 2.2 za merilo uspešnosti 3.3.4 se izrecno nanaša tudi na spreminjanje ali brisanje podatkov pod nadzorom uporabnika. Predvidena je vsaj ena možnost za razveljavitev, preverjanje ali potrditev. Katera različica ustreza, je odvisno od produkta.

Dobri pogovorna okna konkretno navajajo »3 pogovori in 2 priponki« namesto le splošnega izraza »podatki«. Primarno in destruktivno dejanje sta vizualno ločljivi, dostopni prek tipkovnice in nista pojasnjeni le z barvo. Po pošiljanju dostopno območje stanja sporoči, da je bila zahteva sprejeta. Koš za smeti z omejenim rokom za obnovitev lahko ublaži napake pri upravljanju, vendar ne sme skrivaj nasprotovati obljubljenemu takojšnjemu izbrisu.

Predaja podpori brez senčnih kopij

Če se pogovor preda človeku, pogosto nastane ločen zahtevek za podporo. Ta objekt ima morda drug namen, druge dostopne vloge in drugačno pravilo hrambe. Nastavitev zgodovine v klepetalniku ne sme takšnega zahtevka niti nevidno izbrisati niti tiho prezreti. Pred predajo mora vmesnik pojasniti, katere vsebine bodo prevzete. Pri poznejši zahtevi mora sistem najti povezavo in primer obravnavati v skladu z veljavnimi pravili.

Če samodejno brisanje spodleti ali pa identiteta in obseg nista jasna, proces potrebuje varen človeški kanal. Prispevek o človeški predaji (Human Handoff) pri podpori na spletnih mestih opisuje kontekstne pakete in pravila eskalacije. Predati je treba le tisto, kar pristojni zaposleni resnično potrebuje.

Seznam za uvedbo za produktne ekipe in ekipe za podporo

1. Popišite vse podatkovne objekte in lokacije shranjevanja pogovora.
2. Modelirajte pregled, izvoz, brisanje in preklic kot ločena dovoljenja.
3. Za občutljiva dejanja izvedite ponovno avtentikacijo glede na tveganje.
4. Izvozne pakete strukturirajte razumljivo in nastavite varne čase poteka.
5. Korake brisanja naredite idempotentne in jih spremljajte z ID-jem zahteve.
6. Vključite iskalni indeks, datoteke, analitiko, integracije, predpomnilnike in primere podpore.
7. Preizkusite potrditvena okna in statusna sporočila s tipkovnico in bralnikom zaslona.
8. Simulirajte naprave v skupni rabi, potekle povezave in izgubljene naprave.
9. Vidno eskalirajte delne napake, ne da bi kopirali občutljive vsebine v dnevniške zapise.
10. Redno preverjajte pravila hrambe in brisanja z ekipo za varstvo podatkov in strokovnimi oddelki.

Najpomembnejši testi pred zagonom

Testni primeri ne bi smeli pokrivati le idealne poti. Preverite vzporedne zahteve za izbris, potek prijave med izvozom, že preklicane povezave, nova sporočila med potekajočim brisanjem in izpad povezanega sistema. Poleg tega preverite, ali izvoz vsebuje tuja sporočila iz deljenih računov in ali je izbrisana datoteka še vedno dostopna prek starega URL-naslova.

Za vsako dejanje je potreben pričakovani rezultat v vmesniku, API-ju in shrambi. Dober prevzemni test se zato ne konča pri zelenem sporočilu o uspehu. Nato preveri ključne hrambe podatkov, žetone in javne URL-naslove. Dnevniki dogodkov morajo dokazovati, da je bil korak izveden, ne da bi pri tem ponovno shranili izbrisano vsebino pogovora.

Zaključek: Nadzor uporabnikov je lastnost od začetka do konca

Zaupanja vreden klepetalnik uporabnikom ne omogoča le enostavnega iskanja zgodovine. Ločuje pregled, izvoz, brisanje in preklic, ustrezno preverja občutljiva dejanja ter prikazuje dejansko stanje obdelave. Ključna je povezava jasne uporabniške izkušnje s podatkovnim modelom, ki pozna vse odvisne sisteme.

Kdor te funkcije zgodaj vključi v arhitekturo, procese podpore in testiranje, zmanjša ročne izredne primere in se izogne lažnim obljubam. Pri načrtovanju preverite tudi, katere funkcije ChatReact ustrezajo vašemu spletnemu mestu in procesu podpore. Začnite s popisom podatkov in enim samim celovitim testom (End-to-End): izvozite zgodovino, prekličite dostope, sprožite brisanje in dokažite rezultat v vseh vpletenih sistemih.

Viri in nadaljnji napotki

• EUR-Lex: Uredba (EU) 2016/679, zlasti 5., 12., 15., 17. in 20. člen.
• EDPB: Smernice 01/2022 o pravicah posameznikov, na katere se nanašajo osebni podatki – Pravica do dostopa, različica 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Razumevanje WCAG 2.2 Merilo uspešnosti 3.3.4.