Privacy

What this service keeps about you, in plain words, and it is a short list.

Who runs this

Lamza is a self-hosted, free link-in-bio service running on a single machine. There is no company behind it, no analytics vendor, no advertising network and no content delivery network. Everything described below is stored on that one server, by that one operator, and nowhere else.

If you sign in

Your email address is the only personal identifier the account holds. It is used to find your account when you sign in and to confirm your own closure request, and nothing else — the service sends no email at all, because there is no mail server to send it from.

Your password is stored only as an scrypt hash with a random salt. Nobody, including the operator, can read it back.

Each signed-in device holds one session cookie. The server keeps a hash of the cookie’s random token, an expiry, when that device last used it, and the browser string it sent — enough to tell an iPhone from a laptop and nothing more. Your Account screen lists those devices and can end every one of them but the one you are reading it from; signing out, or changing your password, ends the rest the same way.

Two-step verification is optional, and off until you turn it on. Doing so adds a shared secret and ten hashes of the backup codes shown to you once to the same account row that holds your password hash — a row nothing that serves a public page can read. A sign-in then asks for your password and for a code your own phone computes from that secret; the codes are not stored, and nothing about them leaves this server, because there is nobody else in the picture.

If you own a page

Your handle, profile text, blocks, colours and settings are public content, shown exactly as your own switches describe them: a hidden link is hidden, a scheduled link appears in its window, and “keep me out of search” removes the page from the directory, the sitemap and the feed alike.

Your click analytics belong to you alone. That is enforced by the database’s own row level security policies, not merely by application code, so a bug in the site cannot hand another owner your numbers.

A page password is stored the same way as your own: an scrypt hash nobody can read back. A visitor who types it gets an expiring unlock token, stored hashed and tied to that browser — and setting or clearing the password retires every token already given out.

To keep dead links from sitting on your hub, this server visits every link you publish now and then and records only what came back: a status code. The site you link to sees a request from this server’s address and nothing about you or your visitors — no cookies, no names, no email. The checker is forbidden from knocking on private or internal addresses; its whole memory is one status number per link.

A hub can invite readers to leave an email address, if you switch that on. The list is readable by you alone — the database enforces it, not just the site — you may download it as a file whenever you like, and you may forget a single reader on request. It closes with the rest of your page if your account ever does.

The same goes for a note-box: if you switch it on, readers can write you a message that lands in your studio inbox and nowhere else. You read it, you may delete it, and this software never answers it for you.

If you only visit a hub

The page may record that it was viewed, or that a button was clicked: which page and button, the day and a coarse time bucket, an opaque random tag generated by your own browser and kept in its session storage (so one visit counts once instead of once per reload), and the bare host you arrived from — never the full address, because a referrer’s path can carry someone’s search or private link.

Visitor IP addresses are not stored with that event data, no tracking cookies are set, and nothing that can single out your machine is collected. The server does briefly note incoming addresses in memory, for minutes at a time, solely to throttle floods.

A hub may ask you to leave an email address; nothing is collected until you type one. What that hub keeps is the address and the hour you gave it, shown to nobody but the person running the page — and a locked page does not keep the address at all.

A hub may also offer a box to write a note in. What you type goes to the person behind the page alone, with the hour it arrived; an address you add there is kept beside the note as plain text, so that person can answer it if they want to, and it goes away when they delete the note — or when the page itself goes away.

The one exception: embeds

If an owner adds a YouTube, Vimeo or Spotify embed, that player — or the link beside it — is served by the provider itself, and any cookies the provider sets belong to the provider’s privacy policy, not this one.

If you report a page

A report carries the page reference and a reason code. To count each reporter once, the server stores a one-way hash of the reporting address used for nothing else. The reply says the same thing whether your report landed or was already counted, so the tool cannot be used to probe a page.

Backups and deletion

The database is dumped nightly to the same machine and the last fourteen dumps are kept, in files readable only by root; rotation deletes older ones. A dump therefore contains account emails and session hashes for up to two weeks after an account is closed.

Closing your account in the Studio deletes it immediately: the account, your page, every block, every recorded event, every session, and any redirect pointer your old handles left behind. Before you close it, the Studio hands you the whole page as a JSON file and your analytics as a CSV.