Four field types encrypted, one left readable: the decision that prices per-user envelope encryption

The number that decides whether this is affordable is a count of field categories, not a key length. Four go through the cipher: the child's profile including name, traits, worries and what excites them; the contents of private stories; the free-text context an adult writes when ordering a custom story; and the notes a family keeps on what the product calls personalized moments ^[7]. One stays in the clear, the public catalogue, on the stated grounds that it uses fictional characters and holds nobody's real data ^[8]. Four in, one out ^[1].

The master key stays inside Google Cloud KMS and never leaves it ^[5]. Each user gets a data key that the master wraps, stored encrypted alongside that user's records in Firestore; the client fetches it once per session and then encrypts and decrypts field by field in memory, so Firestore sees ciphertext ^[5][6]. Unwrap traffic therefore scales with sessions rather than with rows or fields read ^[2], which is the part that makes per-user keys survivable for a small team. The bill lands elsewhere. For those four categories the database holds ciphertext only ^[6], so any filter, sort or index you wanted over that data has to live in whatever you left readable. That is why the product argument came before the cryptography, in what the author describes as a grilling session on the design ^[10].

The rule they settled on is that the channel decides, not the content: public means plaintext, private means encrypted, and a remix of a public story is born encrypted because it arrives through the private path ^[9]. A flat list of sensitive fields does not settle that case; a rule about where data enters does.

The account is staged in three phases: the encryption core, an adversarial audit that forced several hardening changes, and then a performance incident ^[15] that the standfirst attributes to that same hardening ^[16]. The material supplied here stops before the postmortem, so the mechanism is not available to check. The sequence is: build, get audited, harden, break. All of it ran in very early beta with the author's own account as the only real user in the database ^[12], on the reasoning that doing the same work later, with families' data already in production, would have been considerably more expensive and riskier ^[13].

Priced that way, the outage cost one account. The stack choice supports the same instinct: Firestore for data, Cloud Functions for server logic, Cloud KMS for the master key, and no home-grown key management ^[11]. The article also declines to publish resource names, repository paths or the exact details that would help someone attack the data ^[14], which is defensible and also the reason nobody outside can audit the hardest parts. What travels is the ordering, and the ordering is cheap only while the user count is one.