Privacy policy — Linkora
Who this policy describes
This policy describes the Linkora deployment you are using. “The operator” is the person or company running this server. The brand name and the public URL come from the server configuration, not from a claim that a particular domain or trademark is available.
Have counsel admitted in your market review this text before you rely on it as a binding public policy. It is written to match what the software actually stores.
Account data
If you create an account we store your email address, a display name, a password hash (Argon2id), your role, your plan, whether your email is verified, and the time the account was created. If you turn on two-factor authentication we store an encrypted time-based secret and hashes of one-time recovery codes. We do not store the recovery codes or the password in a form that can be read back.
Session tokens are random. The database stores a hash of the token. The cookie that carries the token is HttpOnly. A separate cookie holds a CSRF token that the application sends back on requests that change data.
Links you create
We store the destination URL, its host, an optional title, the short code, expiration, safety classification, and click totals. The destination cannot be edited later. If you shorten a link without an account, it is tied to an HttpOnly cookie so the same browser can manage it until you sign in. That cookie is set when you create a link, not when you only read the marketing pages.
Clicks
A click record contains the time, the link id, a classification (human, bot, prefetch, or automated), the referring host, and a truncated user agent. When IP storage is set to hash, we also store an HMAC of the IP address and a time after which the hash must be cleared. We do not store the raw IP in the click table, and we do not use browser fingerprinting.
The current retention figures shown on this page are read from the live configuration when you load it.
Donations
The public site does not sell plans and does not take card payments. If a Bitcoin address is published on the donate page, a gift to that address is optional. It does not buy a feature, raise a link limit, or create an account.
The application does not receive the Bitcoin transaction, does not store a wallet key, and does not store other cryptocurrencies. Only the address string, when an operator saves a valid mainnet Bitcoin address, is kept in the server settings.
Messages and reports
Contact messages and abuse reports store the details you submit, a snapshot of a matching short link, and an HMAC of the IP address when IP storage is on. Support and admin staff can read them. Access to a specific user or link record by staff is written to the audit log.
Verification and password-reset messages are sent through the SMTP server the operator configures. In production the message body is not kept in the database after handoff. In a development environment the body is kept in a local outbox so the flow can be completed without an email provider. That outbox is disabled when NODE_ENV is production.
Why we process this data
We process account and link data to provide the service you asked for (contract). We process security logs, rate limits, abuse reports, and hashed IP addresses to keep the service from being used for phishing, malware, and credential attacks (legitimate interests). We process legal-request records where a preservation or disclosure duty applies (legal obligation).
Rate-limit counters live in the memory of the API process. They are not written to the database. They are lost when the process restarts.
How long we keep it
IP hashes are cleared when their per-row retention time passes. Click rows, audit logs, closed abuse reports, and contact messages are deleted on the schedule in the live configuration. Open abuse reports are kept until they are resolved. Legal-request files and their event history are not deleted by the retention job.
Account deletion anonymizes the email, display name, password, and multi-factor secret immediately and revokes sessions. Deleted link destinations are cleared about 30 days later unless the account is under a legal hold or the link has an open abuse report. Short codes are not reused.
Your choices
You can export a JSON copy of your account, correct your display name, clear IP hashes on your links, and delete the account from the account page. You can also file an access, rectification, or deletion request that stays in a queue staff can see. Email address changes are handled by an administrator and are audited; they sign every session out and require verification again when verification is enabled.
Self-service deletion is refused while a legal hold is active. The response does not describe the underlying request.
If you are in the EEA or UK you may lodge a complaint with your supervisory authority. This software does not, by itself, appoint an EU representative or a data protection officer. The operator must do that where the law requires it.
Staff access and legal process
Support staff can look up a user only by a full email address. They can disable or block links and resolve abuse reports. They cannot change roles, assign plans, or open the legal-request log. Administrators can. Staff reads of an individual user or link are audited.
Requests from public authorities are recorded as a case with a reference code. Status moves through identity review, legal review, and only then approval. Each move requires a note and is stored as its own event. The software does not offer a one-click dump of user data on that screen. Disclosure is limited to what the reviewed request covers, and the note should say what was disclosed and to whom.
A preservation hold can be paired with a legal-hold flag on the affected account so routine deletion does not destroy the records the operator is obliged to keep. The hold is not a waiver of the person’s other rights.
Processors and transfers
The operator chooses where the database and the application run. Optional processors are the configured SMTP host and Stripe, and only when those features are turned on. There is no advertising network and no font or script request to a third party in the default build; type is served from this site.
If you publish this service to people in the EEA, UK, or Switzerland, document the transfer tool you rely on (for example the Commission’s standard contractual clauses) in your own notice. This page does not invent a transfer mechanism the operator has not signed.
Children
The service is not directed at children under 16, and we do not knowingly create accounts for them.
Sale of personal information
We do not sell personal information and we do not share it for cross-context behavioral advertising. If you are a California resident you may still use the account export and deletion tools, or the contact form, to make a request.