How to lock down a shared note

A note link is a URL, and URLs get forwarded. That is not a flaw in the design; it is what makes sharing easy. The fix is not to stop sharing, it is to add the right layer of restriction for what the note actually contains. Here are the layers, and how to choose.

Start with the access level

Before adding protection, make sure the link itself grants the right thing. An editable link handed to a wide group is not a protected note; it is a public document with extra steps. Set it to read-only unless you specifically want other people writing on the page.

• Read-only for anything you are announcing or distributing.
• Editable only when you want contributions from anyone who has the link.
• One-time for a single secret: the link burns after one view, so forwarding it is pointless.
• Private when the link is for you and should stay that way.

Add a password when the audience is right but the link is not secret enough

A password gate is the layer for the very common case where the people who should read the note are known, but a link that leaks should not be enough on its own. Passwords are hashed with argon2id before storage, so the server cannot recover one, only verify it.

Use an expiry when the note has a shelf life

A lot of shared notes stop being useful at a predictable moment: the end of a call, the end of a sprint, the end of a trip. A self-destruct timer deletes the note for everyone when it expires, which is much stronger than asking people to ignore an old link.

Pick the shortest window that covers the real need. An hour is right for a temporary credential. Thirty days is right for a sprint retrospective. If the note is genuinely permanent, leave the timer off and stop thinking about it.

Use end-to-end encryption when the server should not be able to read it

A password and an expiry both control access. Encryption changes something different: whether the content is readable to the service at all. When a note is genuinely sensitive, encrypt it, and accept that it requires an account because the key has to stay recoverable by you.

Encrypted notes are owner-only for editing. If several people need to write on one page, encryption and shared editing are a genuine trade-off rather than something you can have both of.

What none of these do

• They do not stop a screenshot. Anyone who can read a note can photograph it. Restriction controls access to the page, not to what a reader does with it.
• They do not hide that a link was visited. Restriction controls who gets in, not whether the request is logged.
• They do not help once a note is too public. A link pasted into a public channel is public. Lock it afterwards if you need to, but assume it was already read.
• They do not replace judgement. A restricted link forwarded to the wrong person is still the wrong person holding the link.

A checklist for before you share

1. Is this note going to need to change after I send it? If yes, share the link, not an export.
2. Who should be able to change it? Set the access level to match, not to what is convenient.
3. Does this content need a password, an expiry, or encryption? Pick the weakest layer that does the job.
4. Am I sending it to a group, or to one person? If one person, a one-time link is the honest choice.
5. Would I be comfortable if the link ended up in a screenshot? If not, the content is too sensitive to send this way.

None of this is exotic. It is a handful of controls that exist in the share dialog, and choosing between them takes five seconds the first time and almost no time after that.