A shared link can ask for a password
In the Share dialog a link can now be given a password. Whoever opens it is asked for it first — before the page, both downloads and Save a copy, though you, signed in, are not — and entering it once keeps it open in that browser for a day. It is kept only as a hash, so it can be changed or taken off but never shown, and a new one ends every earlier entry at once. It is set in the dialog or the API; no assistant can set or remove it.
A link anyone can open is the right thing most of the time. When it is not — a draft for one client, notes that should not travel further than the chat they were pasted into — a link can now ask for a password first.
Setting one
Open the Share dialog, choose Anyone with the link, and press Add a password. It takes eight characters or more. From then on the dialog says the link has a password and offers to change it or take it off; it never shows it, because it is not kept. What is stored is a scrypt hash with a salt of its own, so nobody — the owner included — can read it back.
A password protects a link only. A document shared with specific people already asks each of them to sign in as themselves, and a password on top of that would be a second key to the same door.
What the reader sees
The link opens on a small form instead of the document — for everybody but you: signed in as its owner, you go straight through. The right password sends them on to it, and a cookie remembers for a day that they gave it, so a reload does not ask again. The wrong one comes back with one sentence, the same for every wrong answer. Ten tries a minute from one machine, and thirty for the link from everywhere at once, and then the form asks them to wait.
Everything behind the link asks the same question: the page, its HTML and Markdown downloads, and the app's own reader, which is what Save to your account goes through. None of it is kept by the CDN once there is a password, because a cached copy of the unlocked page would be the document handed to anybody.
Changing the password ends every earlier entry at the moment it is changed: the cookie is a signature made with the password's hash, so a new hash makes every old signature worthless. Taking it off opens the link to anybody again.
From a script
PUT /api/v1/documents/:id/share takes password in the body — never in the address, where it would sit in every log the request passed through — and null removes it. The answer says has_password, never the hash. The command line reads it from the environment for the same reason, since an argument lives in the shell's history:
TP_SHARE_PASSWORD=… tp push notes.md --share --password
What an assistant can do
Say that a link has a password, and nothing else. No tool takes one: a password typed into a conversation is a password in its transcript. A share an assistant changes keeps the password it had.