Privacy en data

Begrensde geschiedenis, echt wissen

Een waarde die op tijdstip T wordt verwijderd of overschreven, is uiterlijk op T + bewaartermijn weg uit elke kopie die TapeDB bijhoudt: de lokale log, de R2-logsegmenten en oudere snapshots. Dat geldt ook in een rustige workspace. Jij bent verwerkingsverantwoordelijke; TapeDB draait in je eigen Cloudflare-account en Cloudflare is je verwerker.

defineTapeDB({ schema, migrations, retention: { days: 30 } }); // standaard 30, minimaal 2

Wat er wordt opgeslagen

Waar	Wat	Hoe lang
Durable Object-SQLite, één per workspace	De rijen van je modellen	Tot ze worden verwijderd
	De operaties en het tijdstip van elke write. Wie de write deed, wordt niet vastgelegd	De helft van de bewaartermijn (standaard 15 dagen)
	Ontvangstbewijzen voor herhalingen: willekeurige client-transactie-id, volgnummer, tijdstip en tijdelijk een hash van de operaties	Id, volgnummer en tijdstip zolang de workspace bestaat; hash verwijderd na de helft van de bewaartermijn. Vervangen R2-kopieën verdwijnen binnen de volledige bewaartermijn
	De bestandsindex: pad, grootte, contenttype en uploader	Tot het bestand wordt verwijderd
R2-bucket DATA	Logsegmenten, snapshots, een manifest	Vervangen kopieën verdwijnen binnen de bewaartermijn
R2-bucket FILES	Geüploade bytes	Direct verwijderd met het bestand
Socketstatus	Subject, rol, subscriptions, presence en topics van een verbonden client, in het geheugen en, boven 12 KiB, in het Durable Object	Zolang de socket openstaat
Claim-limiter	Een tokentelling per HMAC van het IP of subject van een aanroeper, nooit de waarden zelf	Tot de bucket weer vol is, standaard een minuut
Broadcast	Berichten	Niet opgeslagen

Ontvangstbewijzen bevatten geen rijwaarden of identiteit van de schrijver. De opslag groeit met één klein bewijs per transactie met een client-id. Gebruik willekeurige transactie-ids, geen gebruikers-ids. Bij het wissen van een workspace verdwijnen ook de ontvangstbewijzen.

Claim-tokens staan nooit in een URL: HTTP-requests dragen ze in Authorization, WebSocket-upgrades in Sec-WebSocket-Protocol. Log je request-headers in Cloudflare, sluit die twee dan uit. Gebruik een ondoorzichtige user-id als sub van de claim, geen e-mailadres.

Buiten de macht van TapeDB

• Point-in-time recovery van Durable Objects. Cloudflare bewaart 30 dagen herstelbare geschiedenis voor elk SQLite-Durable Object. TapeDB herstelt daar nooit uit, maar de werkelijke grens is de grootste van de bewaartermijn en 30 dagen. Daarom is de standaardbewaartermijn 30 dagen.
• R2-bucketlocks. Een lockregel op de bucket DATA of FILES voorkomt dat TapeDB verwijdert wat eronder valt. Zet er geen op de buckets van TapeDB.

Verzoeken beantwoorden

Verzoek	Hoe
Inzage en overdraagbaarheid	db.$export() of tapedb export --workspace <id> streamt elke rij en elk bestand dat de claim mag lezen, via de leesregels. Zie Exporteren.
Rectificatie	Werk de rijen bij. Oude waarden verdwijnen binnen de bewaartermijn uit de geschiedenis.
Wissen van een persoon	Verwijder of overschrijf hun rijen en verwijder hun bestanden met db.$files.delete(path), dat de bytes direct verwijdert. Oude waarden verdwijnen binnen de bewaartermijn uit de geschiedenis, en binnen 30 dagen uit het herstel van Cloudflare.
Wissen van een workspace	tapedb erase --workspace <id> --confirm <id>, of DELETE /engine/workspaces/:id met een owner-claim, verwijdert de R2-geschiedenis, de bestanden en de opslag van het Durable Object. Daarna antwoordt de workspace met 410.

Waar de data staat

Standaard plaatst Cloudflare het Durable Object van een workspace in de buurt van zijn eerste request, en R2-buckets waar ze zijn aangemaakt. tapedb init --jurisdiction eu houdt de Durable Objects en beide buckets in de EU-jurisdictie van Cloudflare, en tapedb deploy weigert een configuratie waarin die twee niet overeenkomen. Kies dit vóór de eerste deploy: later wijzigen adresseert nieuwe, lege workspaces. Cloudflare blijft de verwerker, dus je doorgifteafweging en de verwerkersovereenkomst van Cloudflare blijven van toepassing.