What I can read, and what I can’t.

There is nothing on this site you have to set up before you can use it. No encryption key, no recovery phrase, no twelve words to write down, no passkey unless you want one for signing in. Sign in, and you are finished.

This page used to say something else. It walked you to a panel that generated a key and made you confirm a recovery phrase, and until you had done that you could not fill in session intake — and, for a while, could not read the link to your own booked call, because it had been encrypted to the key you had not made. That is a strange thing to charge someone for booking a conversation. The panel is gone, for everybody including me.

It is gone for me too, and that part is recent. The panel survived here for a while as mine alone, because unpublished drafts were encrypted to a key only I held. I am the one person who cannot decline a ceremony on his own site, which makes it the worst place for one to live, not the safest.

Encryption did not go away with it. It moved to the server, where it needs nothing from anybody — and it therefore protects less. Section three says exactly how much less.

Signing in asks GitHub, Google or LinkedIn for your public profile and your email address. It is stored, unencrypted, and I can read it.

This section used to say the opposite, at some length: that the email scope was never requested, that there was no column to put one in, and that this was a stronger guarantee than any policy because it could not be changed by someone deciding differently next year. Someone did decide differently next year, and it is me, so here is the reasoning rather than a quiet edit.

Holding nothing is only the cheaper option when there is nothing you needed to do with it. There was: telling you where your confirmed session is happening, or sending you something we agreed I would send. The workaround was to encrypt it to a key you had to create first, which protected the link from a server that already knew the time, the topic, and that it was you. That is a poor trade, and you were paying for it.

What it is used for, exhaustively: replying to you, and sending you a link. There is no mailing list, no newsletter, no analytics on it, and no send infrastructure on this site at all — when I write to you it is from an ordinary mail client, by hand. It is never passed to anyone else.

It can read anything public: posts, comments, reactions. A public comment is public by definition — encrypting it would protect it from the one person who has to read it in order to moderate it.

It can also read direct messages, your email address, the meeting link for a booked session, and any notes I write up and share with you afterwards. The last two are recent: they used to be encrypted to your key, and a key you do not have cannot open a link you need. Anything that travels from me to you is readable here, because you are holding nothing to open it with and I am not going to make you.

It can read what you write when booking — the note about your situation on the session form. That was encrypted until recently and is not any more. Sealing it cost you nothing, which was the whole argument for it; what it cost was a key on my side to receive it, and a key I cannot decline to create is exactly the ceremony this page says does not exist here.

There is nothing on this site it cannot read. That sentence replaces a list, and the list is worth stating because this page made the stronger claim for months: your messages, your intake, my drafts and my private notes were all sealed to keys that only ever existed in a browser, and no code path here could open one.

Two things are still encrypted — my unpublished drafts, and the text of direct messages — and both are encrypted at rest, which is a weaker thing than what used to be here and is often written as though it were the same thing. The key is in this server’s environment. So the ciphertext is useless to somebody who steals a database dump, a backup or a copy of the disk, and it is not useless to me, to this server, or to anyone who can read its configuration. If a court asked me for your messages I could produce them. Under the old scheme I could not have.

Nobody has to do anything for that to work, which is the entire reason it is the arrangement here. The key is generated the first time it is needed and nobody is told, because there is nothing you could usefully do with the information.

Encryption hides content, not the fact of it — so even where something is encrypted, what remains visible is its shape: that it exists, roughly how long it is, and when it was written. Anyone who tells you otherwise is describing a different system.

It signs you in. That is all it does for you, it is entirely optional, and nothing on this site is behind it.

A passkey can also hold an encryption key, using an extension called PRF, and this page used to explain that at length — including the awkward part, which is that several major password managers implement PRF for their own vault and return nothing to sites like this one, with no way for you to tell which you have until you try. That mattered when you were being asked to depend on it. You are not, so it does not.

Sign in again with the same provider and everything is where you left it.

This section used to say then the data is gone — not recoverable by support, not by me, not by a court order, and for you that is no longer true, because you are no longer holding the only key to your own things. Your messages, your sessions, your meeting links and your saved reading are all readable by the server and come back with your account.

There is no exception to that any more. There used to be one — session intake was sealed to me and did not come back — and now it does, because it is stored the way you wrote it. Nothing you rely on disappears with a lost phone.

Something did disappear once, and not from a lost phone: when the keys were deleted, everything still sealed under them went too. If you booked a session while meeting links were encrypted to a key in your browser, that link is gone — the page for it says so, and says to ask me for it. The alternative was to leave bytes in the database that nobody on earth can open, labelled as though they were recoverable.

Losing the account itself — the GitHub, Google or LinkedIn you signed in with — is the one that still costs you, because that is the only thing proving you are you. There is no password to reset here, because there is no password.

No panel, no key, no recovery phrase — not for you, and not for me either.

A panel used to sit at the bottom of this page offering to generate one. It was narrowed to just me, and then removed, because a page that opens by promising you will never be asked to make a key should not end in a form asking someone to make a key. That the someone was the owner made it worse rather than better: I am the one person who cannot decline.

The last thing that needed one was my own unpublished writing, and the editor would not save a draft without it. What replaced it runs on the server with a key nobody types, sees or writes down — which is weaker, and is the trade section three describes rather than hides.

Sign in if you want to write to me or book a session. Nothing above changes depending on whether you do.