Security without theatre.

Account security

Short-link creation and management require an authenticated account. Accounts use an email address and password.

Passwords are stored as bcrypt hashes rather than plaintext passwords. Authentication uses signed first-party session information so the application can identify an authenticated user when account-only actions are requested.

Users are responsible for choosing a strong password and protecting access to the email account associated with Tryst Link.

Link and redirect controls

Link creation is restricted to authenticated users. Destination validation accepts web URLs using HTTP or HTTPS, and custom short codes are validated before they are stored.

Links can be disabled or deleted by their owner, and an optional expiry date can cause a link to stop redirecting after the selected time.

Tryst Link may also disable links or accounts when necessary to respond to phishing, malware, fraud, unlawful content, or other abuse. See the Abuse reporting page.

Data minimization on redirects

The application may record limited information when a short URL is opened: a timestamp, country code when available, coarse device class, and referring hostname when available.

The application does not write the visitor's raw IP address or full user-agent string to its click-event table. Hosting, networking, and security infrastructure may still process normal request metadata while serving and protecting the site. The distinction is explained in the Privacy Policy.

QR generation

QR content is generated client-side in the browser. The text, URL, Wi-Fi credentials, vCard data, or other content entered into the QR tool does not need to be sent to the Tryst Link application server simply to produce the QR image.

Normal requests required to load the QR page still pass through the infrastructure serving the website.

Infrastructure

Tryst Link currently uses Vercel to serve the application and Neon for PostgreSQL database infrastructure. These providers may process technical request or service data as necessary to deliver their infrastructure services.

Provider use does not remove our responsibility to minimize the data our own application stores. More detail appears in the Privacy Policy.

What this page does not claim

No internet service can promise perfect security. This page should not be read as a guarantee that the service is free from vulnerabilities, abuse, downtime, or malicious links.

Tryst Link does not currently claim that every submitted destination is automatically scanned or approved before a short link is created. Reports of harmful links can be sent through our abuse process.

Report a security vulnerability

If you believe you have found a security vulnerability in Tryst Link, email hello@trystlink.io with a subject such as Security report.

Please include, where possible:

• The affected URL, endpoint, or feature.
• A clear description of the issue and its likely impact.
• Reproduction steps that do not expose other users' data.
• Relevant request or response details with secrets removed.
• Your preferred contact details for follow-up.

Responsible testing

Security research must not create unnecessary harm. Please do not:

• Access, modify, download, or delete another user's data.
• Use phishing, social engineering, credential stuffing, or spam.
• Perform denial-of-service or other availability attacks.
• Upload or distribute malware through the service.
• Run high-volume automated tests that materially degrade the service.
• Publish sensitive exploit details before we have had a reasonable opportunity to review the report.

We do not currently advertise a paid bug-bounty program or a fixed response-time guarantee. A good-faith report with clear reproduction details is still welcome.

Security and abuse are different reports

A vulnerability in Tryst Link itself should go to hello@trystlink.io. A short link leading to phishing, malware, fraud, or other harmful content should go to abuse@trystlink.io.

For the rules governing use of the service, see the Terms of Use.