Kako obrisati ono što ste anchorali?

Decision ledger je koristan jer se njegovi zapisi ne mogu naknadno mijenjati. Isto svojstvo postaje problem prvi put kad zapis sadrži osobne podatke, a netko traži njihovo brisanje. Odgovor se određuje pri projektiranju, prije prvog anchora, a ne nekim trikom na chainu.

Podijelite zapis na dva dijela

Sadržaj ostaje u običnom storeu pod vašom kontrolom: tablica u bazi, object store, što god koristi ostatak sustava. Tamo žive osobni podaci i tamo se mogu ispraviti ili obrisati kao svi drugi podaci. Chain prima samo commitment na taj sadržaj: hash jednog zapisa ili root Merkle stabla nad više zapisa koji se anchoraju zajedno. Zapis u ledgeru kaže što se dogodilo i upućuje na record preko identifikatora, a proof povezuje to dvoje bez objavljivanja sadržaja.

Običan hash nije dovoljan

Hashiranje imena, email adrese ili OIB-a djeluje sigurno, a često nije. Prostor mogućih ulaza je malen: tko može pogoditi kandidate, može izračunati njihove hasheve i usporediti. Dodajte nasumični salt svakom recordu, generiran po zapisu, i čuvajte ga uz podatak u vanjskom storeu, nikada na chainu. Commitment postaje hash od salta i sadržaja. Bez salta se vrijednost na chainu ne može reproducirati iz pretpostavke.

Što onda znači brisanje

Kad se zahtjev za brisanje prihvati, iz vanjskog storea brišu se sadržaj i njegov salt. Commitment na chainu ostaje, ali ne ostaje ništa što bi se moglo ponovno izračunati da mu odgovara. To je broj koji ne pokazuje ni na što. Ledger i dalje pokazuje da je zapis postojao na određenoj visini, u određenom slijedu, i da slijed oko njega nije mijenjan. Revizor tako i dalje može provjeriti da povijest nije prepravljena, ali ne može iz chaina saznati što je u tom zapisu pisalo. Za većinu poslovnih slučajeva to je upravo željena granica: integritet ostaje javno provjerljiv, a osobni podaci ostaju tamo gdje se njima može upravljati.

Što gubite i što tek treba odlučiti

Dvije posljedice treba zapisati u projekt. Prva: kad sadržaj nestane, nestaje i mogućnost da se dokaže što je pisalo. Brisanje i dokaz vuku u suprotnim smjerovima, a za neke zapise obveze čuvanja će reći što prevladava. Druga: smatra li se hash i dalje osobnim podatkom pravno je pitanje koje ovisi o slučaju, o ulazu i o tome što se još može povezati s njim. Tu procjenu daje službenik za zaštitu podataka (DPO), a ne arhitekt.

Praktično pravilo je kratko. Prije prvog anchora odlučite koja polja bi se ikada mogla morati brisati, držite ih izvan chaina i zapišite proceduru brisanja uz dizajn ledgera. Poslije je to migracija.

Koja polja u vašem ledgeru bi vam bilo žao što ste anchorali?