Putting a password or an end date on a code

How the gate works, what it protects, what it does not, and what a visitor sees once a code has finished.

What a password actually protects

It stops somebody who has only the code. Scan it without the password and you learn that a password is needed and nothing else — not where it was going, not what is there.

It does **not** protect the destination. That page is still on the internet, and anybody who reaches it another way — a forwarded browser tab, a link in a history, a page that search engines already found — opens it without being asked anything. Anybody you give the password to can also pass it on.

So it is a control at the moment of the scan, not a lock on the thing behind it. That is worth knowing before you use it for something that would genuinely matter if it got out.

Setting one

Open the code, then **Ask something before sending people on**. Type a password and save.

You can read it back later from the same screen, which most tools cannot do — useful when you need to reprint a sign or tell a colleague. It is stored encrypted, so it is readable to you and not to anybody who got hold of the database.

Leaving the password field empty when you save something else keeps the existing one. To take a password off, use **Remove it**.

Guessing

Wrong answers on a code are limited. After enough of them we stop accepting attempts on that code for a few minutes.

The limit counts wrong answers only, so somebody hammering your code can slow guessing down without ever locking out a person who knows the password.

Being asked only once

Once somebody answers correctly, their browser remembers for that code until they close it. They will not be asked again on the way back.

It is remembered for **that one code**. If you have twenty protected codes, unlocking one does not unlock the others, even on your own domain.

Ending a code

A code can stop on a date, or after a number of scans. The date is read in your account's timezone, and it includes the whole of that day.

The scan limit is approximate: it stops within about a minute of the number you set rather than exactly on it.

**Set somewhere for it to go afterwards.** A poster cannot be recalled, so a code that has finished is better leading somewhere useful — next year's page, a shop, an explanation — than to a page saying it is over. If you set nothing, that is what people get.

Scans are still counted after a code finishes. That is deliberate: it is how you find out that a poster nobody has taken down is still being scanned two hundred times a month.

Putting one in front of a document

A password works the same way on a code that points at a PDF or any other file you have uploaded here. Scan it, answer, and the document opens.

The file's own address is protected too, which is the part that usually is not. Getting past the gate produces a link that is signed and good for a few minutes, so the address in somebody's browser history or network tab is not a permanent way around the password. Most tools that sell this leave the file's address open, and the password stops the first visitor and nobody after them.

You can still reach your own files from your media library while signed in, whatever gate is on the code.

It is not encryption. Once somebody has downloaded the document it is an ordinary file and they can forward it to anybody — nothing served over the web can prevent that. If you need a file that stays protected after it has been downloaded, it has to be encrypted with a password the reader types into their PDF reader, which is a different thing from this.

A limit each, rather than a limit in total

**So many scans each** is a different promise from **so many scans altogether**, and it is usually the one you want. A voucher good for one drink, a sample anybody may claim once, a guest list — all of those are one each, and a total limit gets used up by the first ten people through the door.

Set it and choose how scanners are told apart. Neither answer is a person, and it is worth knowing which way each one is wrong.

By browser, or by network

**Their browser** puts a small marker in the browser that scanned it. It is accurate for ordinary use and it is reset by anybody who clears their browser or opens a private window. This is the default, and it is the milder of the two.

**Their network** works out a fingerprint from the connection instead. Harder to get around by clearing a browser, and wrong in two directions at once: everybody in an office, a café or on the same mobile network shares one connection and will be treated as the same person, while a phone that rotates its address gets a fresh go for nothing. On a busy shared network it will turn people away who have never scanned the code.

We never store the address itself. The fingerprint is the same salted, non-reversible value the analytics already keeps, so switching this on records nothing new about anybody.

Automated traffic never uses anybody's allowance. Link-preview robots and crawlers all fetch the address, and on a one-each code the first of them would otherwise spend the only scan the person holding the phone had.

The age question

You can ask for a date of birth before sending somebody on — the usual case being a drinks menu on a table.

**It asks, and it believes the answer.** It is not age verification and it satisfies no legal requirement anywhere. If you have an actual duty to verify age, you need something that checks documents or banking, and this is not that.

Link previews and search engines

A protected code shared in Slack, WhatsApp or a message shows that it is protected. The preview never reveals the destination, and the gate is never indexed.