How Linktary verifies a link

How Linktary verifies a link

Every Linktary short link is verified to origin before it goes live. This article is the complete technical description of that process: what we fetch, what we look for, how we score it, and what each verdict means. We publish this because our verification is the product — and a verification system you can't inspect isn't worth trusting.

Step 1: the bounded chain fetch

When you create a link, Linktary fetches the destination with a strict budget:

• At most 5 redirect hops, following Location headers hop by hop.
• 8 seconds total for the whole fetch; slow or unresponsive destinations

don't get to stall the pipeline.

• HEAD first, then GET — we try a cheap HEAD request and fall back to

GET when the server refuses it.

• 1 MB body cap — we only need the first bytes of a response to sniff

its real content type.

• 50 subrequests max per verification (the platform's safety ceiling for

one operation).

The fetch never runs on the click path. Verification happens once, at creation — plus whenever the owner explicitly asks for a recheck. When someone clicks your link later, the redirect is a single database read. That's deliberate: the hot path must be fast and deterministic, and it must never depend on a third-party server responding in time.

Step 2: the signal taxonomy

Each fetched chain is scored against four signal families. Every signal has a code, a severity (block / warn / info), and a numeric weight. The weights are what make the verdicts reproducible: the same chain always scores the same.

Chain signals — what the redirect path itself says:

• redirect_loop (100, block) — the destination redirects in a loop, a

classic evasion pattern.

• too_many_hops (20, warn) — 4 or more hops; unusually long chains are a

phishing pattern.

• cross_domain_hop (30, warn) — a redirect jumps to a different

registrable domain mid-chain.

• https_downgrade (40, warn) — the chain drops from HTTPS to plain HTTP,

where traffic can be intercepted.

Host signals — what the domain names say:

• ip_literal_host (50, warn) — a raw IP address instead of a domain name.
• idn_punycode_host (40, warn) — internationalized-domain lookalike risk.
• mixed_script_host (40, warn) — the hostname mixes character scripts

(Latin and Cyrillic, say) to mimic a trusted name. This one is checked on the pre-normalization hostname, because URL parsing encodes IDNs — the precise diagnosis wins over the generic punycode signal, never both.

• suspicious_tld (30, warn) — a top-level domain frequently abused in

phishing campaigns.

Content signals — what the bytes say (final hop only):

• executable_content (100, block) — the destination delivers an executable

program, the highest-risk content.

• archive_content (40, warn) — a downloadable archive file.
• content_mismatch (30, warn) — the server claims one file type but the

bytes are something else (we sniff magic bytes) — a cloaking pattern.

• executable_extension (30, warn) — the final URL ends in an executable

file extension.

Domain-age signals — how new the destination is:

• new_domain (25, warn) — registered within the last 30 days.
• young_domain (10, warn) — registered within the last 90 days.
• rdap_unavailable (0, info) — the registration age couldn't be checked.

Lookup failure is neutral, never blocking.

Threat-intelligence feeds (Google Safe Browsing, urlscan.io) can be wired in later through a provider interface that already exists in the engine; today the engine is fully self-contained and needs no API keys.

Step 3: score → verdict

The score is the sum of all signal weights. The thresholds are public and fixed:

If the engine itself fails — the destination times out, the network errors, something unexpected breaks — the result degrades to CAUTION, never to an error and never to a silent pass. Link creation never fails because the verification engine had a bad day; the cautious verdict is the default.

Step 4: the trust report

Every verdict is published on a public trust report at linktary.com/v/<code> — no account needed. It shows the verdict badge, the full redirect chain hop by hop, the plain-language explanation of every signal, the score, and when the check ran. Agents get the same data as JSON at /v/<code>.json.

The trust report is the point of the whole design. Anyone who receives one of our links — a colleague, an IT admin, a suspicious recipient — can open it and see exactly why we vouched for the destination. A verification nobody can audit is marketing. Ours is inspectable.

The design principles, summarized

1. Verify at creation, never on the hot path. Clicks are a single

database read. Verification gets a bounded budget and never touches the redirect.

2. Publish the machinery. Signal codes, weights, thresholds — all

public, all reproducible.

3. Fail cautious. Engine trouble is a CAUTION verdict, not an error

and not a free pass.

4. Show your work. Every verdict ships with a public, machine-readable

trust report.

Transparency is the moat. Anyone can build a shortener; the reason to trust ours is that you can read exactly how it thinks. For the question every CISO asks next — what can Linktary see, and what can't it — read The honest crypto design and the /security page.