'Delen van verwijderde chats te herstellen bij WhatsApp'

Het is mogelijk om verwijderde WhatsApp-chats terug te halen. Dat concludeert beveiligingsonderzoeker Jonathan Zdziarski na het uitpluizen van zijn iPhone. Ook na het volledig verwijderen van de app is het nog mogelijk chats terug te halen, bijvoorbeeld via iCloud-back-ups.

De tekstgegevens blijven achter in de SQLite-database, een veelvoorkomend probleem volgens Zdziarski. Dit komt doordat SQLite databases niet volledig leeghaalt als deze worden verwijderd. Als bijvoorbeeld een deel van de database door de gebruiker wordt verwijderd, dan plaats SQLite dit deel op een zogenaamde 'free list', aldus de onderzoeker. Deze lijst wordt alleen niet meteen overschreven. Dit gebeurt pas als de ruimte nodig is op een later tijdstip. Daardoor blijven er vaak gegevens staan, soms maandenlang. Door meer gegevens weg te gooien, komen er ook meer op de lijst terecht.

WhatsApp verwijdert de gegevens dus wel, alleen verdwijnen deze niet uit de database, legt Zdziarski uit. Dit is problematisch, omdat de berichten tussen gebruikers wel 'ephemeral' oftewel tijdelijk zijn, maar niet op het apparaat zelf. Daar komt bij dat de nog leesbare databases ook meegenomen worden in een iCloud-back-up. Deze back-ups zijn niet versleuteld, zoals dat volgens de iOS-onderzoeker op de desktop wel het geval is. Daarnaast is een versleutelde back-up ook niet veel waard in combinatie met een zwak wachtwoord. De back-upfunctie waaraan Zdziarski refereert, staat overigens los van de iCloud-sync-functie in WhatsApp zelf.

Door deze factoren kan bijvoorbeeld een opsporingsdienst alsnog via het apparaat of via een back-up de inhoud van verwijderde berichten achterhalen. Volgens de onderzoeker is dit echter geen reden tot paniek, maar hij onderstreept dat het belangrijk is hiervan op de hoogte te zijn. Gebruikers kunnen maatregelen nemen door een lang en sterk wachtwoord voor iCloud te kiezen en dit niet in de keychain op te slaan. Ook het uitzetten van back-ups of het periodiek verwijderen van de app is een mogelijkheid.

Zdziarski beveelt WhatsApp aan om de SQLite-database zodanig te kenmerken dat deze niet in een back-up wordt meegenomen. Ook kan het bedrijf een techniek inzetten om gegevens te overschrijven voordat deze verwijderd worden. Daarnaast kan een SQLite-alternatief een uitkomst bieden, bijvoorbeeld door versleutelde CoreData te gebruiken. WhatsApp schakelde in april end-to-end-encryptie in voor al zijn gebruikers.

Reacties (51)

[Quacka]

wat is nu echt het probleem? Dat buitenstaanders bij de database kunnen?
Ik bedoel... Ik heb met iemand gechat en gooi chat weg. Is het dan probleem dat ik chat terug zou kunnen halen? Als buitenstaanders dat kunnen is het minder leuk.

[Anoniem: 84766]

Het is een probleem omdat WhatsApp end-to-end encrypt. Ze doen dit zodat nieuwsgierige oogjes niet kunnen meekijken. Nu is er een manier gevonden dat nieuwsgierige oogjes alsnog chats kunnen bekijken.

Beveiliging is zo sterk als de zwakste schakel. Deze zwakke schakel moeten ze oplossen.

Edit: eigenlijk is dit niet relevant want de db is sowieso niet beveiligd.

[Reactie gewijzigd door Anoniem: 84766 op 23 juli 2024 13:37]

[Armin]

Het is een probleem omdat WhatsApp end-to-end encrypt. Ze doen dit zodat nieuwsgierige oogjes niet kunnen meekijken. Nu is er een manier gevonden dat nieuwsgierige oogjes alsnog chats kunnen bekijken.

Toch is het niet helemaal eerlijk.

End-to-end encryptie beschermt het bericht onderweg tegen nieuwsgierige oogjes.

Dit "lek" zorgter voor dat iemand die jouw iPhone te pakken krijgt, en eventuele beveiliging zoals wachtwoorden en encryptie weet te omzeilen, de database kan bemachtigen en dan mogelijk nog (resten van) berichten kan teruglezen.

Maar dat kan ook zonder SQLLite. Immers ik kan ook een flash-lezer nemen en de ruwe sectoren van je flash gaan bekijken, en dan restanten van gedelete bestanden terugvinden.

Dus dit "lek" is op zich waar, maar een andere aanvalsvector.

En op flash geheugen is dit toch al niet tegen te gaan. Immers, zelfs al zou SQLLite het ondersteunen een bericht fysiek te wissen, bijvoorbeeld door de database entries met 0-en te overschijven, dan nog is er geen enkele garantie dat die 0-en op dezelfde fysiek sectoren worden weggeschreven. Immers flash geheugen (net als SSD's) werken zo niet ivm wear-leveling.

De enige manier om je hier tegen te beschermen is dus een (sterk) wachtwoord/PIN in combinatie met disk-encryptie. Plus uiteraard je database niet (onversleuteld) opslaan in een cloud.

Als ik heel eerlijk ben, vind ik de vinding dus op zich interessant (SQLLite kent geen fysieke purge), maar is het niet een nieuwe aanvalsvector op je chatberichten.

[Anoniem: 84766]

Helemaal mee eens. Vandaar mijn edit die ik er meteen bij had gezet.

Wat betreft Flash klopt het niet helemaal wat je zegt. Functies als TRIM en een GC zijn er juist voor om de cellen weer te legen, juist om performance degradatie tegen te gaan.

[SomerenV]

Als je een chat om wat voor reden dan ook verwijdert dan hoor je er van uit te kunnen gaan dat die ook écht weg is en niet slechts op papier. Maakt niet uit wie er bij kan, verwijderen hoort te betekenen dat iets ook gewoon niet te terug te halen is.

[firest0rm]

nee dat kun je niet verwachten.
een chat is altijd met 2 personen dat jij dan de chat verwijderd betekent niet dat dit het geval is bij een ander.
verder zijn er veel synchronisaties die draaien op de achtergrond.
Zelfde geld voor heel veel apparaten het echt verwijderen van sporen is heel moeilijk.

je kunt dus niet zo stellig verwachten dat het dan ook echt weg is.

[Reactie gewijzigd door firest0rm op 23 juli 2024 13:37]

[calvin]

Behalve wanneer je Delete chat doet in BlackBerry Messenger, als je daar delete chat doet, kun je alle berichten van het device van je chatpartner weg laten gooien.

[markimarc]

Zelfde met secret chats op Telegram

[Accretion]

Behalve als die persoon geen internet heeft?
Of simpelweg screenshots heeft bewaard.

[Viince1]

Als jij iets weggooit op Windows of Linux is het ook standaard terug te carven vanaf de harde schijf volgens precies dezelfde methodiek.
De data wordt namelijk in de MFT als 'vrij' aangegeven, maar de data is pas echt weg als het overschreven wordt.

De SQL-lite database werkt onder precies hetzelfde principe. Data wordt gemarkeerd als 'gereed voor overschrijven', maar blijft nog staan totdat deze overschreven wordt. Niks mis mee. Als mensen zich hier echt zorgen over maken kun je gewoon de encryptie op Android inschakelen, en bij iOS zit je default al goed.

verwijderen hoort te betekenen dat iets ook gewoon niet te terug te halen is.

Liever niet. Ik wil er niet aan denken hoeveel tickets de gebruikers zouden starten als ze hun verwijderde mail niet meer kunnen terughalen. Bovendien is wat je zegt in veel situaties simpelweg onmogelijk. Als ik mail verwijderd in mijn inbox, is deze nog prima terug te halen vanaf de exchange server. Dus nee, weg is niet weg.
Als je er verder over nadenkt wordt het helemaal mooi. Als ik nu jou een mailtje stuur, en jij verwijdert deze, moet ik dan ook de mail aan mijn kant verwijderen? Anders gaat je quote niet op.

[Freedox]

Dat de bedoelde ontvanger het bericht nog heeft is totaal niet te vergelijken met dat er nu zonder de zender zijn intentie sporen achterblijven op het apparaat, sporen die niet achter hoeven te blijven. Aangezien whatsapp zichzelf aan prijst als dienst met encryptie terwijl er zo'n gigantisch lek in zit, wat zoals hierboven vermeld zo om te draaien valt door die data te zero-en, dan hoeven we inderdaad niet te verwachten dat er nog data achter blijft die mogelijk makkelijk toegankelijk is. Zo hetzelfde als je Tails gaat draaien. Dan verwacht je ook dat ie wanneer gevraagd het geheugen en de schijf scrubt na gebruik. Als dat niet zou gebeuren komt er ook ophef. Dat is iets anders dan een Windows os waar we allemaal weten dat dit niet het geval is en er ook niet anders beweert is.

[Viince1]

Hoezo is dit dan zo'n gigantisch lek?
Wat is nu precies het aanvalsscenario waardoor de privacy van elke WhatsApp gebruiker nu vreselijk bedreigd wordt?

Aangezien whatsapp zichzelf aan prijst als dienst met encryptie terwijl er zo'n gigantisch lek in zit.

Er is niks mis met de encryptie die WhatsApp toepast. Dat staat hier echt volledig buiten.

dan hoeven we inderdaad niet te verwachten dat er nog data achter blijft die mogelijk makkelijk toegankelijk is

Van makkelijke toegang is echt op geen enkele manier sprake. Op iOS wordt de hele spullenboel default versleuteld, en dus kun je helemaal niks uitlezen zonder het wachtwoord te kraken van de gebruiker en je zult waarschijnlijk fysiek het apparaat in handen moeten hebben om de harde schijf op dit niveau uit te lezen, het OS gaat echt niet toestaan dat je bij de SQL database komt.

Bij (oudere versies van) Android hoeft versleuteling niet perse aan te staan, maar ook hier zul je de database op moeten sporen. Voor de duidelijkheid, je kan niet http://android-van-xx/geheime_database.html bezoeken. Hoogstwaarschijnlijk zul je dus ook hier weer:
1. Fysieke toegang moeten hebben tot de opslag van het device, of;
2. Geavanceerde malware deployen op een device en de database exporteren. Echter, als je in staat bent dit te doen, dan heb je eigenlijk de database niet meer nodig en kun je simpelweg WhatsApp live uitlezen.

Zo hetzelfde als je Tails gaat draaien. Dan verwacht je ook dat ie wanneer gevraagd het geheugen en de schijf scrubt na gebruik.

Het hele concept van Tails is de HDD niet te gebruiken zodat je geen sporen achterlaat, daarom heet het een live operating system. Tails gebruikt wel raml, maar dat is inherent gewist zodra de PC wordt uitgezet.

[Freedox]

Ram gewist als de PC uit is? Haha.
En waarom zou je malware moeten gebruiken als een simpele adb actie toegang verschaft tot het hele systeem? Mss moet je iets meer verstand van electronica verzamelen voordat je statements plaatst die van geen kant kloppen. Iedere idioot weet dat Ram nog uit te lezen nadat de PC al redelijke tijd uit staat, waarom denk je dat een echte hacker, en niet een blije script kid waar jij t over hebt, na zen werk de boor op zen pcb zet.

[Viince1]

Je had mij bijna, mooie bait +1.
Laten we het draadje maar stoppen.

[JP1980]

Dat is het zelfde idee als met de harde schijf. Verwijderde data is pas 'echt' weg als de sectoren opnieuw worden beschreven.

[b2vjfvj75gjx7]

Is het ook niet gewoon common knowledge om je DB niet op te slaan in de cloud?

Als je privacy zó belangrijk is, is het logisch dat je (ten eerste geen WA gebruikt...) en ten tweede geen backups maakt van je extreem privacy gevoelige WA gesprekken...

Overigens kan je gewoon instellen dat WA niet synched met de cloud; zie screenshot...

http://i.imgur.com/rvBF310.png

Weliswaar zie je backups op je sd-card staan (per dag geordend), maar als ik de SQLite DB open in een tool als Navicat, krijg ik de melding dat de DB encrypted is (andere tools geven dit ook aan).

[cruysen]

Klopt. Bij een harde schijf wordt alleen de verwijzing naar de data verwijderd. Dus als je schijf direct gaat lezen kom je nog steeds die data tegen.

Dit lijkt me echter een fout van het OS en niet van de software.
De OS zou de data moeten verwijderen/overschrijven als daar naar gevraagd wordt, deze heeft tenslotte ook de controle waar deze data staat.

[Stoelpoot]

Het is een fout van de achterliggende databasesoftware SQLite, als ik het goed lees. "Als bijvoorbeeld een deel van de database door de gebruiker wordt verwijderd, dan plaats SQLite dit deel op een zogenaamde 'free list'" Dit werkt dus ongeveer hetzelfde als een harde schijf, maar is onderdeel van de SQLite library.

[Laloeka]

Niet helemaal. Verwijderde sectoren kunnen direct weer overschreven worden door nieuwe bestanden. Dat is ook de reden dat file recovery software je waarschuwt niet de herstelde bestanden op dezelfde schijf weg te schrijven.

Echter in dit geval blijft de data dus gewoon in een bestand staan (de SQLite database), zelfs wanneer de rij uit de database gegooid is. Er komt gewoon een kleine markering in het bestand dat deze data niet meer geldig is om performance redenen. Het vervelende is dat dit SQLite bestand dan zonder extra encryptie op de iCloud servers gezet wordt, dus zelfs wanneer deze gegevens dan uiteindelijk op je telefoon overschreven worden door nieuwe data, zijn de berichten vaak nog lange tijd uit de SQLite database te reconstrueren die op de iCloud servers staan.

Dit kan opgelost worden door de SQLite database op te schonen wanneer Whatsapp berichten verwijdert heeft, al suggereert het gelinkte artikel dat dit een fundamenteel probleem is met iOS en SQLite.

Een andere verbetering die Apple kan aanbrengen is de iCloud backups te versleutelen met een sleutel die alleen de gebruiker kent.

Zo zien we maar weer dat end-to-end encryptie geen garantie geeft dat het complete systeem waterdicht is, wanneer de berichten bijna in plain-text op een iCloud server terechtkomen.

[Reactie gewijzigd door Laloeka op 23 juli 2024 13:37]

[Armin]

Dit kan opgelost worden door de SQLite database op te schonen wanneer Whatsapp berichten verwijdert heeft, al suggereert het gelinkte artikel dat dit een fundamenteel probleem is met iOS en SQLite.

Het is een beetje click-bait van de onderzoekers. Het "fundamentele" probleem is dat SQLLite geen ondersteuning heeft voor zo'n purge. SQLLite is niet voor niets 'Lite'

Maar men gaat volledig voorbij dat de database hoe dan ook toch op je telefoon flash geheugen wordt opgeslagen. En dat daar hetzelfde geldt. Je kunt wel op bestandsniveau zaken fysiek overschrijven met 0-en, maar is is nihil garantie dat die 0-en ook op dezelfde fysieke flash sectoren worden weggeschreven. Vanwege wear-leveling is het zeer waarschijnlijk dat dat niet gebeurd zelfs.

Zoals ik dus elders betoog, is de aanval dus op zich interessant, maar niet nieuw. Er is niks mogelijk dat niet ook al mogelijk was vanuit security oogpunt. Hoogstens iets makkelijker.

Disk-encryptie sluit het "lek" verder volledig (tenzij je uiteraard de database in de cloud opslaat zonder encryptie)

[Laloeka]

Echter zijn er maar zat apps op Android die SQLite databases kunnen opschonen en verkleinen. Het is niet onmogelijk, ondanks dat sommige SQLite implementaties het niet ondersteunen.

Het voordeel van het bestand opschonen is dat, zolang deze database meegenomen wordt in de iCloud systeem-backup, de records in ieder geval niet daar opgeslagen blijven.

Het grotere probleem daar blijft natuurlijk dat deze iCloud systeem-backup niet goed beveiligd is, zoals een lokale backup op je computer dat wel is.

[Viince1]

Je slaat de spijker op zijn kop. Dit is helemaal zo'n probleem niet. Nogal sneu om WhatsApp volledig hiervoor in de spotlight te zetten. In de hele blog is niks geroepen over de effecten van:
- Encryptie op OS niveau;
- De snelheid waarmee berichten worden overschreven;
- Dat deze 'hack' niet begrenst is tot Whatsapp, maar tot de meeste apps en files op je telefoon/apparaat/device.

[Anoniem: 668730]

Nogal sneu om WhatsApp volledig hiervoor in de spotlight te zetten.

Dit komt omdat WhatsApp end-to-end encryptie heeft ingevoerd. Hoe serieuzer ze zelf met privacy omgaan, hoe nauwlettender andere gaan controleren of dat wel klopt.

[Viince1]

Dat is geen argument, en zeker niet voor een "security researcher" (auteur van blog) wiens baan het is om onafhankelijk en objectief onderzoek te doen. Op deze manier wordt de context ontzettend scheef getrokken.

WhatsApp heeft dan wel end-to-end encryptie, maar dat is volledig losstaand van deze issue.

[Anoniem: 630165]

In zekere zin is dat op die manier te vergelijken ja.

Nu heb ik zelf een jailbreak op mijn iphone en icm iFile kan ik makkelijk sqlite databases of folders verwijderen (denk aan bv je Camera gallery/mappen - hier staan sommige fotos nog opgeslagen nadat je ze visueel uit je gallerij verwijderd hebt).
Ik denk dat dit op zich wel een interessant gebied is om te onderzoeken onder meerdere applicaties.

[Reactie gewijzigd door Anoniem: 630165 op 23 juli 2024 13:37]

[Anoniem: 428562]

Als je een SSD en OS gebruikt die beide TRIM ondersteunen is de kans dat data van verwijderde bestanden niet meer leesbaar is een stuk groter.

https://en.wikipedia.org/wiki/Trim_(computing)

[The Third Man]

Waarom encrypt whatsapp de data in de sqlite db dan niet met een random key, om vervolgens te alsnog de data verwijderen? Neem niet aan dat sqlite ook bij het overschrijven van records de originele data laat staan?

[WhatsappHack]

Ik denk omdat het encrypten op het toestel weinig zin heeft, gezien je de decryptiesleutel er dan ook bij moet opslaan. Per saldo is dat even veilig als plain-text, maar minder intensief.
(Al wordt er wel enige vorm van encryptie toegepast op die bestanden trouwens, IIRC; maar altijd het gevoel gehad dat dat meer is om kiddies te stoppen.)

Het wipen van de data is een ander verhaal. Dat zouden ze kunnen aanpassen.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 13:37]

[The Third Man]

Ik bedoelde ook als wipe-methode. Of kan sqlite zelf ook garanderen dat de data gewipet wordt?

[Laloeka]

SQLite databases kunnen inderdaad opgeschoond worden, vaak met externe tools. Vergelijk het met een harde schijf defragmenteren waar je de lege sectoren verwijderd en alle data dichter op elkaar zet.

SQLite doet dit zelf niet omdat het een vrij intensief proces is, vooral voor databases zo groot als die van WhatsApp.

[Reactie gewijzigd door Laloeka op 23 juli 2024 13:37]

[The Third Man]

Ok, maar wordt bij een overschrijving van records dan steeds nieuwe ruimte gebruikt, of is de oude ruimte statisch aanwezig en blijf je binnen die ruimte? Want in het laatste geval zijn een wipe-per-record met random of encrypted data toch de originele data moeten wipen?

[Laloeka]

Ik las zojuist een waarschijnlijkere reden waarom SQLite dit niet doet op iOS. Dit is om 'wear' van het flashgeheugen tegen te gaan.

Daarmee is gelijk je vraag beantwoord: als een record aangepast wordt, wordt deze waarschijnlijk op een andere plek opnieuw weggeschreven.

[Blokker_1999]

Als je aan de database kan heb je vermoedelijk ook voldoende toegang om aan de sleutel te kunnen.

[SN4K3]

Als ik iets in whatsapp verwijder dan kan ik dat ook gewoon nog terugvinden in de documenten op mijn telefoon, tenminste daar was ik een tijd geleden nogal verbaasd over dat ook foto's e.d. gewoon opgeslagen blijven staan.

[Anoniem: 382732]

En anders kan je het wel terug vinden op de telefoons van de personen waar je mee gecommuniceert hebt :-)

[WhatsappHack]

Volgens mij is dat beveiliging van het OS om te zorgen dat foto's die op de cameraroll staan niet door (rogue)apps verwijderd kunnen worden.

Je kan wel uitzetten dat spullen naar de cameraroll worden geschreven, tenzij je dit handmatig alsnog doet. (Kan per afbeelding of alles uit een specifieke chat)
Als je dat uitzet, dan is t wel direct helemaal weg als je t uit WhatsApp verwijdert; immers heeft je telefoon dan geen kopie gemaakt naar het fotoalbum.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 13:37]

[mahsalti]

Moet ik dit zien als een soort van "recycle bin" van SQLite? Ik kan mij voorstellen dat meerdere apps hier gebruik van maken?

Echter zie ik niet snel het probleem hiervan in tenzij iemand de code weet van je telefoon aangezien de storage sowieso encrypted is tegenwoordig op IOS apparaten. Dit is dus alleen echt uit te lezen als er fysiek toegang is op het apparaat.

[SinergyX]

Nee, meer als basis van een harde schijf. Als jij data verwijderd op een schijf 'verdwijnt' het wel, maar effectief is alleen de index naar de fysieke data op de schijf weg, de 0 en 1 data staat nog steeds fysiek op de schijf en dus in principe te herstellen. Pas als de schijf die ruimte weer nodig heeft, wordt dit overschreven.

[Reactie gewijzigd door SinergyX op 23 juli 2024 13:37]

[airell]

Oracle gebruikt zo'n soort principe inderdaad wel als recycle bin. Het overschrijft deze blokken niet totdat de datafile vol zit. Het geeft de voorkeur om eerst die blokken te overschrijven dan de datafile te vergroten.
Tot die tijd kun je gedropte tabellen terughalen, mits je de recycle bin functionaliteit niet uitzet.

[eL_Jay]

Jan modaal geeft 0 om zijn of haar privacy (free software JWT), behalve wanneer de overheid deze in het maatschappelijk belang wil beperken

[TimMer]

Cruciaal verschil is dat ik dan zelf de keuze maak in plaats van een snuffelzieke ambtenaar die totaal niet weet waar hij mee bezig is en mijn privégegevens dus op straat liggen.

Overheid en ICT is altijd al een slechte combinatie geweest, maar anno 2016 met zoveel verregaande automatisering in ons leven helemaal.

[WhatsappHack]

Om dit te kunnen spl0iten (groot woord ) heb je óf volledige toegang tot de telefoon nodig, óf tot iCloud als daar backups op gemaakt worden... dan lijkt het me niet echt een heel high-impact probleem, zeker niet voor het leeuwendeel van de gebruikers. Ik bedoel... Als iemand zulke toegang weet te krijgen, dan kan die op dit moment natuurlijk niet alleen verwijderde berichten terughalen en lezen: maar ook alle niet-verwijderde als je gewoon de app of backup opent. En je kan er niet vanuitgaan dat enkel die verwijderde interessant waren (voor inlichtingendiensten)...

Desalnietteplus kunnen ze natuurlijk inderdaad wel kijken of dit geoptimaliseerd kan worden om enige window of opportunity te verkleinen; maar iCloud-backups en Google Drive backups zullen binnenkort gelukkig ook encrypt gaan worden. Werd wel tijd, maar beter laat dan nooit. Dan zou dit probleem dus ook opgelost moeten zijn voor het cloud gedeelte, enkel de database op het toestel zelf is dan nog "kwetsbaar".

Als je veel whatsapp't zullen die entries in de database denk ik behoorlijk rap overschreven worden overigens. Ligt er net aan hoeveel je precies verwijdert.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 13:37]

[Anoniem: 636203]

Je moet altijd je backup naar de cloud uitzetten als je niet wil dat belangrijke informatie bekeken kan worden. Of men moet zoals geadviseerd de SQLite database niet backup-en.

Tevens moet WhatsApp bij het deleten de records overschrijven met willekeurige data en daarna pas een DELETE FROM uitvoeren.

[jeroen3]

Dit is al sinds het begin der tijden zo. Het viel mij al op in mijn jailbroken 3GS dat de whatsapp database zo groot was. Hij verwijdert alleen de afbeeldingen, want die ruimte komt daadwerkelijk vrij.
De tekst blijft achter in de database, totdat je whatsapp opnieuw installeert en niet terugzet uit de backup.

Ik snap niet dat dit nu alsnog nieuws is.

[SB[NL]]

Verbaasd mij niets.

Er zijn nog steeds mensen die online diensten gebruiken en denken dat hun data "vluchtig" is en vertrouwen Snapchat, WhatsApp, Facebook, Google, Microsoft, Apple, Samsung, enz op hun "blauwe ogen" dat zij precies doen wat zij vooraf aangeven.

Al deze data zal via servers moeten lopen. Het bedrijf wil het liefst 24/7 kunnen waarborgen en dat data die verloren gaat (om wat voor reden dan ook), hersteld kan worden. Meestal cached en mirrored om de "User Experience" te verbeteren.

Je kan niet van twee walletjes eten als redundantie en caching een vereiste is om de gebruiker zo goed en snel mogelijk te bedienen en eventueel een vangnet te bieden tegen onbedoelde handelingen.

Ik wil niet dus niet meteen zeggen dat er altijd kwade bedoelingen achter zitten, maar dat er vast manieren zijn om hier gebruik, dan wel misbruik van te maken.