Might be good to add an example for salts, e.g. by salting the passphrase with the notebook slug.

I’d be interested in seeing how you would do this.

For the sake of this example I'd recommend changing the key to something more passphrasey, so that it's easier to recognize it as a customizable password (perhaps also throw in a "changeme").

Good suggestion, done.

This might be a good place to hint at the "Download text" option for each cell, in order to download and then attach encrypted data.

Respectfully, encode() has a terrible API :) It shouldn't return strings for base64 and Uint8Array for other encodings.

It always returns a buffer.

No, it doesn't. encode('foo', 'base64') returns a string. You're even using it specifically for that purpose in encrypt().

Ah, I see, I’ve inverted the logic for Base64 accidentally. I’ll fix.

Okay, fixed. Now it always returns a buffer, and Base64 is handled separately.

Maybe also mention that the secret key will be part of the notebook history, so that people won't rely on just deleting the cell? (never underestimate the ability of your users to do something stupid, after all)

If you’re following the instructions here, the secret key won’t be part of the notebook history (unless you deliberately paste it into a cell and you’ve already forked this notebook to save your changes). After generating a secret key by running the cell below, click the “click here” link to change the hash, and then use that new hash to encrypt your message. The key only exists in memory. I’ve also changed the notebook to use a text input so you don’t need to paste the secret message into the notebook to encrypt it.

> If you're following hte instructions here Well, guess I neatly demonstrated my own point about dumb users then :p

I think this is venerable to "https://crypto.stackexchange.com/questions/6273/aes-ctr-vulnerability-to-cryptographic-oracle/6275#6275" because we have unfettered access to the decryption oracle. I independently developed a fuller solution and went with AES-GCM for this reason. (https://observablehq.com/@endpointservices/notebook-secret), though thats not a guarantee I haven't made a different mistake.

Oops, no, the key is send in the URL, so an attacher cannot generate a cypertext and get it decrypted with the real key unattended.