Having read the book Dealers of Lightning about Xerox PARC and Kay,I think Smalltalk 72 was the original smaller simple language, with which children were taught.
Then others at Xerox added more professional stuff, the kind programmers would want, which resulted in Smalltalk 76 and so on. These were not as approachable for children anymore allegedly.
Nowadays there's Squeak which is a Smalltalk implementation, which influenced Scratch I think (first version of Scratch was written in Squeak).
Search the internet for Adam Kay's documents on Squeak and educating children, helps to put on context what he had in mind (if you, like me, just install Squeak and expect a stunning tutorial... it's not like that, at least I didn't find).
Kay also said, having an IDE only takes you to the 70s from the 60s too... So there's work to be done yet.
I recall reading it, and strangely I felt that making of the game is just a side-happening, while the author was on pursuit to get into movie industry rather.
Am interesting contrast, given most people know and are amazed by the game in retrospect.
Decryping is ephemeral though. No request body gets stored, except in RAM. Malicious operators etc, well that's always a possibility, but they supposedly have controls for that. And as others noted, they are not the only players in the path of serving your data.
I was pondering about using simple decentralized databases that are kept synchronized asynchronously.
I arrived to a design where SQLite databases would be synchronized by Kafka. Kafka is really robust, and has a friendly semantics when configured to be in-order delivery.
The catch is, you don't issue writes to SQLite anymore. You write Kafka messages, and have to prepare to resolve concurrency problems at read+write-to-db time. For example, user registration is not an atomic action anymore - you write a registration attempt message, and then it might race with a concurrent registration attempt from an other node (say due to retries and random load balancing).
You resolve the race in message-reception time (doable due to stable order on multiple reader nodes). I expect this would work nice, but needs you to rethink all actions that used to be synchronous db writes.
I worked at Google and have no idea what they mean by stacked change. You could push multiple changes to a single CL, but those were rarely reviewed independently.
Maybe they mean keeping a stack of CLs ready, while waiting for a review? I often had 1-2 CLs based on.. rebasing was fun sometimes.
Or they mean diffbasing these subsequent CLs, for an early review? That was useful, but due to volatility dependent on the first review, a bit risky.