keal - tror ikke Google og de andre kommer til å ta risiko ved å bare late som de sletter det som kreves. Sanksjonene er potensielt ekstreme og de store VET at de blir tatt om de jukser, de har allerede betalt noen hundre millioner i bot og vil neppe gjenta det.
Flott med litt engasjement Jeg er sikker på at vi kommer til å håndtere dette på en tilfredsstillende måte. Som både ivaretar behovet for beholde innlegg/tråder i forumet samtidig som all informasjon som kan kobles til en enkeltperson blir fjernet.
I Baneheia-saken ble Telenor kontaktet for opplysninger om bevegelsene til de mistenktes mobiltelefoner. Forespørselen kom så sent at det var en viss usikkerhet om de ville klare å hente fram informasjonen innenfor fristen for da de måtte, etter loven, slette dataene.
De rakk det innen fristen, men en pågående journalist presset Telenor på hva som ville ha skjedd om de ikke hadde rukket det innen fristen. Det ble, noe motvillig, medgitt (i åpne media, husker ikke eksakt hvor) at en reell sletting blir foretatt i databasen som er tilgjengelig online, men at det i helt spesielle situasjoner nok ville være mulig å hente fram en langtids-backup og finne informasjonen der, men at det ville kreve mye manuelt arbeide.
Jeg har null forestilling om at Google eller hvemsomhelst andre henter fram offline backups hver eneste gang noen sletter et innslag i sin personlige søkehistorie, slik at det samme innslaget kan slettes i (muligens en lang rekke) offline backups. Og jeg har null forestilling om at seriøse informasjonsleverandører som Google opererer uten noen form for backup (i forstand offline, offsite backup - en backup skal ikke kunne ødelegges av noen malware, og skal ikke ødelegges av brann eller naturkatastrofer). Det kan hende at Google reelt sletter informasjonen fra "arbeidskopien", ikke bare merker den som slettet, men det er alt.
Det behøver ikke å utgjøre så stor forskjell fra å bare merke den som slettet: Mest trolig har Google all info i en database, som naturligvis har logge-funksjoner. Før noen (modifiserende) operasjon foretas i selve databasen, skrives et "before image" til loggen, i tilfelle noe går galt før commit, slik at den gamle versjonen kan hentes fram hvis transaksjonen rulles tilbake (eller det skjer andre feil, f.eks strømbrudd, midt i oppdateringen). Slike logger blir alltid bevart: For å komprimere loggevolumet er det mulig i ettertid å analysere loggen og finne elementer som det ikke er noen mulighet for at kan rulles tilbake lengre. Komprimering er så ekstremt ressuskrevende at det ofte ikke blir gjort, og det blir stående i loggen hva som ble slettet, selv om det er ute av databasen.
For rene filer (ikke databaser) er det ikke mye tryggere. Filer "i parpirkurven" er ikke slettet i det hele tatt, de er bare merket for sletting. Selv når de slettes permanent blir som regel bare blokkene frigjort, tilgjengelig for gjenbruk; de blir ikke nullet ut. Konfiskerer politiet PCen din (eller krever de å få ta en total disk-kopi av nettstedet disker) får de tilgang til også blokker som er slettet, men enda ikke gjenbrukt. I mange kriminalsaker har politiet funnet viktige bevis i "slettede" filer på denne måten. I enkelte operativsystemer kan du slå på en mekansme som faktisk nuller ut alle diskblokker idet de blir frigitt, men for store filer kan da tiden for å slette dem bli "uendelig" lang.
En del applikasjoner, f.eks. epost-klienter, bruker ikke noen ekstern database, men organiserer selv innholdet i en eller flere filer på 'lignende' måte. Da gjøres ofte sletting ved å flytte blokker over i en liste over blokker til gjenbruk. For mange år siden brukte jeg Outlook Express, og da reddet jeg ut et brev som aldri skulle vært slettet ved å finne en bit her, en bit der, i postfila og klistre disse bitene sammen for hånd.
Nå vil neppe Google selv benytte seg av slikt, men hvis f.eks. overvåkingstjenestene krever innsyn, vil de trolig ta en total binær-dump av disken, og da får de også med seg innhold i blokker som er frigitt, men enda ikke nullet ut. Informasjon fra "slettede" filer har vært viktig bevismateriale i en rekke saker. (Vel å merke: Dokumenter "i papirkurven" teller ikke som slettet i denne sammehengen; de er "merket for sletting" uten at noen plass er frigjort.)
Det blir antagelig vurdert som "sikkert nok" hvis det slettes fra brukskopien, selv om man ikke henter inn alle offline, off-site bakcups og sletter også derfra, med masse manuelle operasjoner. Men vi har jo backup for at det skal være mulig å gjenopprette ødelagte data. Prosedyrene finnes, og ved en utilsiktet skade må backupen kunne hentes fram. Da kan den også hentes fram av andre årsaker - først og fremst om (ikke nødvendigvis norske!) myndigheter i en eller variant krever det
Har dere full klarhet i hva dere er juridisk sett forpliktet til å levere ut av informasjon dersom f.eks. PST står på døra og krever innsyn?
For noen år siden fikk et norsk nettforum (jeg husker ikke i farten hvilket, men kan grave det fram fra notatene om nødvendig) et slikt krav, ikke fra PST men "sivile" myndigheter. Jeg mener å huske at det var noe sånt som at en forumdeltaker avslørte at han hadde begått ulovlig import, ikke betalt en forholdsvis høy toll, eller noe slikt. Myndighetene krevde at nettstedet røpet identiteten til denne personen, hvilket ble nektet. Det ble sak, og nettstedet vant både i tingrett og lagmannsrett.
Hvis en tilsvarende situasjon oppstår på BB, har da BB en klar policy på hvordan man stiller seg til utleveringskrav fra myndighetene? Er dere forberedt på å gå til rettssak for å verne anonymiteten?
Jeg tror ikke saken med det andre forumet gikk til høyesterett, men en dom i lagmannsretten har likevel en viss prejudaktiv effekt. Hvis myndighetene prøver noe tilsvarende på nytt, bør det være noe som på ett eller annet felt skiller signifikant fra den tapte saken. Ville BB kunne etterkomme myndighetenes krav i visse tilfeller, ikke i andre? Hvor går grensen? Det er slett ikke vanskelig å lese mellom linjene at en del forumdeltakere utfører arbeide på eget hus som de strengt tatt ikke har autorisasjon for. Jeg nærmest tar for gitt at BB ikke røper til myndighetene hvem det gjelder. Men sett at det gjaldt f.eks. miljøkriminalitet, som ulovlig import og bruk av vernede tropiske treslag, eller en som stolt viser fram foto peishylla med en nyutstoppet svartstrupe ("sterkt truet" på den norske rødlista)? Hva om noen søkte andres råd for utvidelse av hans torturkammer? Nå kunne vel det bli fjernet av redaksjonen uansett, men siden det ikke er noen forhåndssensur kunne det stått tilgjengelig lenge nok til at myndighetene så det. Ville BB verne om anonymiteten til forumdeltakeren?
Eller man kunne gjøre som klassiske anon.penet.fi (en tidlig 1990-talls forløper for Tor, med mer enn 300.000 brukere, som var mye på 90-tallet): Da politiet krevde fullt innsyn (etter krav fra Scientologene) hadde de hatt så god til på forberede seg at da myndigetene sto på døra kunne de fortelle: Nei, vi har nettopp fullført fullstendig utblankeing av alle våre disker og backups; vi foretrekker å legge ned anonymiseringstjenesten framfor å røpe identiteten til 300.000 mennesker som har stolt på vårt ord om at de skal forbli anonyme.
anon.penet.fi var (som Tor i dag) en ren anonymiseringstjeneste uten eget informasjonstilbud. For et nettsted som BB, med masse egen informasjon, kunne naturligvis denne bestå, selv om all informasjon om kobling mellom signatur og epostadresse (evt. annen ID) ble fullstendig blanket ut.
Jeg jobber tett med Microsoft sitt engineering team, da vår bedrift er partner og i gruppen top 10 most important customers i Norge for Microsoft. I arbeidet med GDPR kan jeg garantere dere at data blir slettet hos Microsoft. Hadde sist for 2 uker siden Microsoft Black Belt team hos oss og diskuterte GDPR og løsningene de implementerer. Vi får innsyn i en god del utenforstående ikke får som en del av Customer sucsess program og andre samarbeid vi har med dem. For det første forventer Microsoft at det blir gjort tilsyn rett etter 25. Mai uavhengig av om det kommer inn saker på dem eller ikke, da de er en såpass stor aktør i markedet. Det er ganske imponerende hvordan de sporer data. Synlige ting er «enkelt , men det er tilfeller som at en GUID ligger i en log og blir lastet ned til en utvikler sin PC for eks i forbindelse med feilsøking som er vrien. Det er den type trackingsystem og system for da å sørge for sletting også på de enkelte PC som er imponerende og utfordrende, samt den type data lineage er utrolig utfordrende å gjøre.
Så å anta at de store aktørene ikke virkelig sletter er en feiltagelse. Det er også en stor markedsmessig fordel for MS og andre å være gode, da det gir en Edge i markedet. Det å kunne selge en god databehandleravtale har høy verdi.
Også jobbet litt opp mot Schibsted, som har intet mindre enn 100 ansatte i Norge som KUN jobber med GDPR. Så IT industrien har virkelig fokus på dette.
I arbeidet med GDPR kan jeg garantere dere at data blir slettet hos Microsoft.
Da er det tre alternativer:
1) MS har ikke offline, off-site backup av data - alt er online. Ved sletting av informasjon i database startes (tilnærmet umiddelbart) en prossessering av databasessystemets loggfiler for å fjerne alle innslag som refererer til de data som er slettet.
2) MS har offline, off-site backup, og ved hver eneste forespørsel om sletting innhentes samtlige offline, off-site backups. Databaser etc. startes opp og slettingen gjentas i hver eneste backup-kopi. Database-logger prosesseres slik at det ikke ligger igjen noe som helst logg-entry som viser verken innsetting eller sletting av disse data.
3) "garanti for sletting" er å forstå i en noe mer begrenset forstand, som ikke omfatter offline/off-site backups, database-logger etc.
Det mest sannsylige alternativet er 3). Det du tilsynelatende vil formidle er alternativ 2), som er så ressurskrevende at det virker ekstremt lite trolig. Alternativ 1) er ressursmessig mer realistisk (logg-redigeringen krever likvel svært mye ressurser), men det er fint lite realistisk å tro at MS operer uten offline backup, og at ihvertfall langtidslogger er off-site.
Hvis en IT-ansvarlig hos MS kan svare godt på hvordan sikkerheten til data ivaretas, f.eks. hvordan daglige logger og langtidslogger skrives, oppbevares og hentes inn, og kan gi en tilforlatelig forklaring på hvllke operasjoner som settes i gang når data slettes for å sikre at de også forsvinner fra alle backups av databasen selv og alle logger, da vil jeg muligens tro på påstanden. Det avhenger av hvilke detaljer som ikke forklares. (Eksempelvis hvor lang tid det kan ta før en off-site backup lastes inn for å foreta en batch slettinger, hvilken hardware som benyttes for dette, på hvilken måte innslag fjernes fra databaseloggen - av ytelseshensyn er den som regel en "flat fil" skrevet sekvensielt, som regel gigantisk stor og det er ikke trivielt å klippe ut biter mitt inni den.)
Som du kanskje skjønner, for alternativ 2: Æ stille mæ skjepisk.
Microsoft opererer ikke med online/offside backup. Det er et data fabric med litt over 40 regioner (land) hvor det er avhengig av data enten lokal redundans eller georeplikering. Det er ikke enkelte system vi snakker om det er hundrevis av integrerte systemer med ulike sammensetninger Av Local redundans, global redundans, global redundans med global read, eller global redundans med global read og Write.
Det er ikke en enhetlig database eller enhetlig backup men et fabric av ulike. Det er helt klart at backup ikke slettes umiddelbart, men må kunne slettes innen 72 Timer i alle system. Det er det som er så vrient og kostbart.
At local redundans blir i regionen er f. Eks kritisk da en rekke data gjerne ikke kan forlate en region eller i noen tilfeller spesifikke stater i USA. Men her er miks av cloud tjenestenes ansvar og databehandlers ansvar.
Det kan være vanskelig nok å få gjort en SQL DELETE på 72 timer i et slikt system
SQL DELETE er alternativ 3). Det blir stadig liggende igjen masse spor i databaseloggene om informasjonen som ble slettet. Rett nok er den ikke lenger tilgjengelig gjennom SQL-setninger, men den som har (/krever) tilgang til database-loggene kan få tak i den. For ordens skyld: "SQL DELETE" kan i ikke-SQL-systemer selvsagt hete noe annet, med litt ulike parametere etc., og jeg refererer til "SQL DELETE eller ekvivalent operasjon".
Replikering kan betraktes som "en slags form for" off-site backup, men bare for halvparten av funksjonene. Det kan beskytte mot f.eks. brann og naturskalder, og hvis(!) systemene er heterogene mot programvarefeil som er fatale for data. Men det gir ikke (i seg selv) noen beskyttelse mot "brukerfeil" (av type xkcd 327) eller malware som opererer på høynivå, når uønskede operasjoner er distribuert før problemet er oppdaget. La oss beskrive det som et modifisert alternativ 1) der man prøver å forklare brukerne hvordan enkelte problemer er handtert, mens man krysser både finge og tær for at ingen skal spørre om problemstillinger som ikke er handtert!
Selv om man på globalt nivå ser hver enkelt DDBMS-node som "online", er det sterk grunn til å tro at det i hvert lokale DBMS er backup-funksjoner som i større eller mindre grad er offline. (Vi kan betrakte en fullskrevet DBMS-logg, lagret på en separat disk eller helst en separat maskin, som en offline logg. Om den også er off-site kan vel skifte fra en DBMS-installasjon til en annen.) Det er naturligvis mulig å lage et DBMS som ikke har noen form for logging, men da har du heller ingen commit/rollback-funksjonalitet, og da kan man spørre seg om det i det hele tatt er et DBMS!
I et distribuert DBMS er som regel lokale systemer relativt autonome i måten de realiserer operasjonene på. Du bekrefter jo det, "ikke en enhetlig database eller enhetlig backup men et fabric av ulike". Det kan bety at man for å slette alle spor av data må inn i diverse ulike systemer, ulike logge-mekanismer, og fjerne logg-data på ulik måte ulike steder - og det innenfor 72 timer. Det kan variere mye hvor lang tid det tar mellom hvert skifte til ny loggfil: Så lenge DBMSet skriver på en logg kan du ikke bare nappe den ut for å slette innslag. Skal data slettes i databasen, av type SQL DELETE, må du gjøre slettingen, vente til loggfila er fylt opp så den frigis og det det startes en ny, før du kan komme til for å fjerne logginnslag. Ventingen kan ta opp en vesentlig andel av de tilmålte 72 timer!
Særlig i en heterogen, distribuert database vil jeg gjerne ha anledning til å stille kritiske detaljspørsmål rundt hvordan slettingen foretas i databasen selv og i loggene, for hver enkelt av del ulike systemene, før jeg stoler på at alle spor av slettede data er borte. Jeg vil også stille spørsmål ved hvordan man kan sikre seg, når det kommer en ny node med i nettverket, med annerledes, lokalt definert DBMS-teknologi, realiserer en delete som krever sletting i loggene.
Dessuten: I et typisk DBMS gjør man jo massevis av sletting som er helt ordinær, uten disse kravene til at alle spor skal være borte i løpet av 72 timer. I mange kontekster er man slett ikke interessert i det - en av grunnene til å bruke et DBMS er som i et system for handtering av kildekode (type Git / SVN / ...): Det skal være mulig å gå bakover i historien. Så det må finnes to ulike typer sletting: En for å tilfredsstille personvern-kravene, en for å slette men med mulighet for å inspisere historien. Hvordan er forskjellen mellom disse to handtert i alle de ulike DBMSene som er invovert i et et DDBMS?
Så fortsatt: Æ stille mæ skjepisk. Eller heter det skjematisk?
Semi-sidespor / fag-humor: En av mine kollegaer tok en PhD i optimalisering av søk i distribuerte databaser, og kommeterte midt i arbeidet, "Jeg visste i utgangspunktet at DDBMS-optimalisering er et NP-komplett problem, men jeg forstod raskt at det er en grov overforenkling."
Børhaug: Det er mange pålegg i forordningen, men hva med unntakene? Du peker til påleggene, men det er ikke slik at en borger kan kreve at staten fjerner en fra f.eks. strafferegistrene – som det ville være hjemmel for i GDPR, men som er unntak for. Likeledes kan man ikke kreve at en bank sletter en fra bankens registre rett etter en har tatt opp et lån så unntak gjelder private aktører også.
Og bland nå ikke SQL inn i debatten; det en detalj på siden av diskusjonen som ikke tar opp den originale problemstillingen.
De rakk det innen fristen, men en pågående journalist presset Telenor på hva som ville ha skjedd om de ikke hadde rukket det innen fristen. Det ble, noe motvillig, medgitt (i åpne media, husker ikke eksakt hvor) at en reell sletting blir foretatt i databasen som er tilgjengelig online, men at det i helt spesielle situasjoner nok ville være mulig å hente fram en langtids-backup og finne informasjonen der, men at det ville kreve mye manuelt arbeide.
Jeg har null forestilling om at Google eller hvemsomhelst andre henter fram offline backups hver eneste gang noen sletter et innslag i sin personlige søkehistorie, slik at det samme innslaget kan slettes i (muligens en lang rekke) offline backups. Og jeg har null forestilling om at seriøse informasjonsleverandører som Google opererer uten noen form for backup (i forstand offline, offsite backup - en backup skal ikke kunne ødelegges av noen malware, og skal ikke ødelegges av brann eller naturkatastrofer). Det kan hende at Google reelt sletter informasjonen fra "arbeidskopien", ikke bare merker den som slettet, men det er alt.
Det behøver ikke å utgjøre så stor forskjell fra å bare merke den som slettet: Mest trolig har Google all info i en database, som naturligvis har logge-funksjoner. Før noen (modifiserende) operasjon foretas i selve databasen, skrives et "before image" til loggen, i tilfelle noe går galt før commit, slik at den gamle versjonen kan hentes fram hvis transaksjonen rulles tilbake (eller det skjer andre feil, f.eks strømbrudd, midt i oppdateringen). Slike logger blir alltid bevart: For å komprimere loggevolumet er det mulig i ettertid å analysere loggen og finne elementer som det ikke er noen mulighet for at kan rulles tilbake lengre. Komprimering er så ekstremt ressuskrevende at det ofte ikke blir gjort, og det blir stående i loggen hva som ble slettet, selv om det er ute av databasen.
For rene filer (ikke databaser) er det ikke mye tryggere. Filer "i parpirkurven" er ikke slettet i det hele tatt, de er bare merket for sletting. Selv når de slettes permanent blir som regel bare blokkene frigjort, tilgjengelig for gjenbruk; de blir ikke nullet ut. Konfiskerer politiet PCen din (eller krever de å få ta en total disk-kopi av nettstedet disker) får de tilgang til også blokker som er slettet, men enda ikke gjenbrukt. I mange kriminalsaker har politiet funnet viktige bevis i "slettede" filer på denne måten. I enkelte operativsystemer kan du slå på en mekansme som faktisk nuller ut alle diskblokker idet de blir frigitt, men for store filer kan da tiden for å slette dem bli "uendelig" lang.
En del applikasjoner, f.eks. epost-klienter, bruker ikke noen ekstern database, men organiserer selv innholdet i en eller flere filer på 'lignende' måte. Da gjøres ofte sletting ved å flytte blokker over i en liste over blokker til gjenbruk. For mange år siden brukte jeg Outlook Express, og da reddet jeg ut et brev som aldri skulle vært slettet ved å finne en bit her, en bit der, i postfila og klistre disse bitene sammen for hånd.
Nå vil neppe Google selv benytte seg av slikt, men hvis f.eks. overvåkingstjenestene krever innsyn, vil de trolig ta en total binær-dump av disken, og da får de også med seg innhold i blokker som er frigitt, men enda ikke nullet ut. Informasjon fra "slettede" filer har vært viktig bevismateriale i en rekke saker. (Vel å merke: Dokumenter "i papirkurven" teller ikke som slettet i denne sammehengen; de er "merket for sletting" uten at noen plass er frigjort.)
Det blir antagelig vurdert som "sikkert nok" hvis det slettes fra brukskopien, selv om man ikke henter inn alle offline, off-site bakcups og sletter også derfra, med masse manuelle operasjoner. Men vi har jo backup for at det skal være mulig å gjenopprette ødelagte data. Prosedyrene finnes, og ved en utilsiktet skade må backupen kunne hentes fram. Da kan den også hentes fram av andre årsaker - først og fremst om (ikke nødvendigvis norske!) myndigheter i en eller variant krever det
Har dere full klarhet i hva dere er juridisk sett forpliktet til å levere ut av informasjon dersom f.eks. PST står på døra og krever innsyn?
For noen år siden fikk et norsk nettforum (jeg husker ikke i farten hvilket, men kan grave det fram fra notatene om nødvendig) et slikt krav, ikke fra PST men "sivile" myndigheter. Jeg mener å huske at det var noe sånt som at en forumdeltaker avslørte at han hadde begått ulovlig import, ikke betalt en forholdsvis høy toll, eller noe slikt. Myndighetene krevde at nettstedet røpet identiteten til denne personen, hvilket ble nektet. Det ble sak, og nettstedet vant både i tingrett og lagmannsrett.
Hvis en tilsvarende situasjon oppstår på BB, har da BB en klar policy på hvordan man stiller seg til utleveringskrav fra myndighetene? Er dere forberedt på å gå til rettssak for å verne anonymiteten?
Jeg tror ikke saken med det andre forumet gikk til høyesterett, men en dom i lagmannsretten har likevel en viss prejudaktiv effekt. Hvis myndighetene prøver noe tilsvarende på nytt, bør det være noe som på ett eller annet felt skiller signifikant fra den tapte saken. Ville BB kunne etterkomme myndighetenes krav i visse tilfeller, ikke i andre? Hvor går grensen? Det er slett ikke vanskelig å lese mellom linjene at en del forumdeltakere utfører arbeide på eget hus som de strengt tatt ikke har autorisasjon for. Jeg nærmest tar for gitt at BB ikke røper til myndighetene hvem det gjelder. Men sett at det gjaldt f.eks. miljøkriminalitet, som ulovlig import og bruk av vernede tropiske treslag, eller en som stolt viser fram foto peishylla med en nyutstoppet svartstrupe ("sterkt truet" på den norske rødlista)? Hva om noen søkte andres råd for utvidelse av hans torturkammer? Nå kunne vel det bli fjernet av redaksjonen uansett, men siden det ikke er noen forhåndssensur kunne det stått tilgjengelig lenge nok til at myndighetene så det. Ville BB verne om anonymiteten til forumdeltakeren?
Eller man kunne gjøre som klassiske anon.penet.fi (en tidlig 1990-talls forløper for Tor, med mer enn 300.000 brukere, som var mye på 90-tallet): Da politiet krevde fullt innsyn (etter krav fra Scientologene) hadde de hatt så god til på forberede seg at da myndigetene sto på døra kunne de fortelle: Nei, vi har nettopp fullført fullstendig utblankeing av alle våre disker og backups; vi foretrekker å legge ned anonymiseringstjenesten framfor å røpe identiteten til 300.000 mennesker som har stolt på vårt ord om at de skal forbli anonyme.
anon.penet.fi var (som Tor i dag) en ren anonymiseringstjeneste uten eget informasjonstilbud. For et nettsted som BB, med masse egen informasjon, kunne naturligvis denne bestå, selv om all informasjon om kobling mellom signatur og epostadresse (evt. annen ID) ble fullstendig blanket ut.
Så å anta at de store aktørene ikke virkelig sletter er en feiltagelse. Det er også en stor markedsmessig fordel for MS og andre å være gode, da det gir en Edge i markedet. Det å kunne selge en god databehandleravtale har høy verdi.
Også jobbet litt opp mot Schibsted, som har intet mindre enn 100 ansatte i Norge som KUN jobber med GDPR. Så IT industrien har virkelig fokus på dette.
Da er det tre alternativer:
1) MS har ikke offline, off-site backup av data - alt er online. Ved sletting av informasjon i database startes (tilnærmet umiddelbart) en prossessering av databasessystemets loggfiler for å fjerne alle innslag som refererer til de data som er slettet.
2) MS har offline, off-site backup, og ved hver eneste forespørsel om sletting innhentes samtlige offline, off-site backups. Databaser etc. startes opp og slettingen gjentas i hver eneste backup-kopi. Database-logger prosesseres slik at det ikke ligger igjen noe som helst logg-entry som viser verken innsetting eller sletting av disse data.
3) "garanti for sletting" er å forstå i en noe mer begrenset forstand, som ikke omfatter offline/off-site backups, database-logger etc.
Det mest sannsylige alternativet er 3). Det du tilsynelatende vil formidle er alternativ 2), som er så ressurskrevende at det virker ekstremt lite trolig. Alternativ 1) er ressursmessig mer realistisk (logg-redigeringen krever likvel svært mye ressurser), men det er fint lite realistisk å tro at MS operer uten offline backup, og at ihvertfall langtidslogger er off-site.
Hvis en IT-ansvarlig hos MS kan svare godt på hvordan sikkerheten til data ivaretas, f.eks. hvordan daglige logger og langtidslogger skrives, oppbevares og hentes inn, og kan gi en tilforlatelig forklaring på hvllke operasjoner som settes i gang når data slettes for å sikre at de også forsvinner fra alle backups av databasen selv og alle logger, da vil jeg muligens tro på påstanden. Det avhenger av hvilke detaljer som ikke forklares. (Eksempelvis hvor lang tid det kan ta før en off-site backup lastes inn for å foreta en batch slettinger, hvilken hardware som benyttes for dette, på hvilken måte innslag fjernes fra databaseloggen - av ytelseshensyn er den som regel en "flat fil" skrevet sekvensielt, som regel gigantisk stor og det er ikke trivielt å klippe ut biter mitt inni den.)
Som du kanskje skjønner, for alternativ 2: Æ stille mæ skjepisk.
Det er ikke en enhetlig database eller enhetlig backup men et fabric av ulike. Det er helt klart at backup ikke slettes umiddelbart, men må kunne slettes innen 72 Timer i alle system. Det er det som er så vrient og kostbart.
SQL DELETE er alternativ 3). Det blir stadig liggende igjen masse spor i databaseloggene om informasjonen som ble slettet. Rett nok er den ikke lenger tilgjengelig gjennom SQL-setninger, men den som har (/krever) tilgang til database-loggene kan få tak i den. For ordens skyld: "SQL DELETE" kan i ikke-SQL-systemer selvsagt hete noe annet, med litt ulike parametere etc., og jeg refererer til "SQL DELETE eller ekvivalent operasjon".
Replikering kan betraktes som "en slags form for" off-site backup, men bare for halvparten av funksjonene. Det kan beskytte mot f.eks. brann og naturskalder, og hvis(!) systemene er heterogene mot programvarefeil som er fatale for data. Men det gir ikke (i seg selv) noen beskyttelse mot "brukerfeil" (av type xkcd 327) eller malware som opererer på høynivå, når uønskede operasjoner er distribuert før problemet er oppdaget. La oss beskrive det som et modifisert alternativ 1) der man prøver å forklare brukerne hvordan enkelte problemer er handtert, mens man krysser både finge og tær for at ingen skal spørre om problemstillinger som ikke er handtert!
Selv om man på globalt nivå ser hver enkelt DDBMS-node som "online", er det sterk grunn til å tro at det i hvert lokale DBMS er backup-funksjoner som i større eller mindre grad er offline. (Vi kan betrakte en fullskrevet DBMS-logg, lagret på en separat disk eller helst en separat maskin, som en offline logg. Om den også er off-site kan vel skifte fra en DBMS-installasjon til en annen.) Det er naturligvis mulig å lage et DBMS som ikke har noen form for logging, men da har du heller ingen commit/rollback-funksjonalitet, og da kan man spørre seg om det i det hele tatt er et DBMS!
I et distribuert DBMS er som regel lokale systemer relativt autonome i måten de realiserer operasjonene på. Du bekrefter jo det, "ikke en enhetlig database eller enhetlig backup men et fabric av ulike". Det kan bety at man for å slette alle spor av data må inn i diverse ulike systemer, ulike logge-mekanismer, og fjerne logg-data på ulik måte ulike steder - og det innenfor 72 timer. Det kan variere mye hvor lang tid det tar mellom hvert skifte til ny loggfil: Så lenge DBMSet skriver på en logg kan du ikke bare nappe den ut for å slette innslag. Skal data slettes i databasen, av type SQL DELETE, må du gjøre slettingen, vente til loggfila er fylt opp så den frigis og det det startes en ny, før du kan komme til for å fjerne logginnslag. Ventingen kan ta opp en vesentlig andel av de tilmålte 72 timer!
Særlig i en heterogen, distribuert database vil jeg gjerne ha anledning til å stille kritiske detaljspørsmål rundt hvordan slettingen foretas i databasen selv og i loggene, for hver enkelt av del ulike systemene, før jeg stoler på at alle spor av slettede data er borte. Jeg vil også stille spørsmål ved hvordan man kan sikre seg, når det kommer en ny node med i nettverket, med annerledes, lokalt definert DBMS-teknologi, realiserer en delete som krever sletting i loggene.
Dessuten: I et typisk DBMS gjør man jo massevis av sletting som er helt ordinær, uten disse kravene til at alle spor skal være borte i løpet av 72 timer. I mange kontekster er man slett ikke interessert i det - en av grunnene til å bruke et DBMS er som i et system for handtering av kildekode (type Git / SVN / ...): Det skal være mulig å gå bakover i historien. Så det må finnes to ulike typer sletting: En for å tilfredsstille personvern-kravene, en for å slette men med mulighet for å inspisere historien. Hvordan er forskjellen mellom disse to handtert i alle de ulike DBMSene som er invovert i et et DDBMS?
Så fortsatt: Æ stille mæ skjepisk. Eller heter det skjematisk?
Semi-sidespor / fag-humor: En av mine kollegaer tok en PhD i optimalisering av søk i distribuerte databaser, og kommeterte midt i arbeidet, "Jeg visste i utgangspunktet at DDBMS-optimalisering er et NP-komplett problem, men jeg forstod raskt at det er en grov overforenkling."
Børhaug: Det er mange pålegg i forordningen, men hva med unntakene? Du peker til påleggene, men det er ikke slik at en borger kan kreve at staten fjerner en fra f.eks. strafferegistrene – som det ville være hjemmel for i GDPR, men som er unntak for. Likeledes kan man ikke kreve at en bank sletter en fra bankens registre rett etter en har tatt opp et lån så unntak gjelder private aktører også.
Og bland nå ikke SQL inn i debatten; det en detalj på siden av diskusjonen som ikke tar opp den originale problemstillingen.