Written for people who will check
How Keyway protects visitors
A link locker is a redirect platform, and redirect platforms attract phishing. Here are the specific defences, including where they stop working.
Scheme and structure
Only http and https are accepted. javascript:, data:, vbscript:, file: and blob: are refused. So are URLs carrying a username and password — https://evil@bank.example sends the browser to bank.example while the human reads evil.
Private and internal addresses
Loopback, RFC 1918, carrier-grade NAT, link-local and cloud metadata endpoints are blocked — including the disguises: decimal and octal IPv4, IPv4-mapped IPv6, 6to4 and NAT64 wrappers that embed a private v4 address.
IDN homograph detection
Internationalised domains are decoded from punycode and analysed. A label mixing Latin with Cyrillic or Greek is refused — that combination has no legitimate use and is how аpple.com is spelled with a Cyrillic а.
Domain denylist
Known malware hosts and IP-logger services are refused outright, matched against the hostname and every parent domain — never by a naive suffix match that would also catch notexample.com.
Heuristic flags
Shorteners, high-abuse TLDs, free subdomain hosts, IP-literal destinations and credential vocabulary raise a score. A high score queues a link for human review. It never blocks creation — heuristics are wrong often enough that auto-blocking would refuse legitimate creators daily.
Nothing is fetched server-side
Keyway never requests a creator-supplied URL. No preview fetch, no favicon scrape, no metadata unfurl. Classic SSRF is structurally impossible here rather than filtered — there is no code path that dials a destination.
What automated checks cannot do
Everything above is structural. It catches malformed URLs, private addresses, spoofed domains and known-bad hosts. It does not catch a convincing phishing page registered forty minutes ago on a clean domain, because nothing does — reputation systems are, by definition, behind.
That is why the second half of this exists:
- A report button on every unlock page. Not in a footer, not three clicks deep. No account, no email address.
- Reports read by a person. Report volume alone never disables anything — that mechanism is trivially weaponised by anyone willing to organise enough accounts. Volume escalates; a human decides.
- An audit trail. Every status change writes a row saying what happened, when, and why. That is what makes "why was my link disabled?" answerable, and an unexplained takedown visible after the fact.
- Burst detection. Two hundred links from one source in an hour is a spam operation, never a creator. Sources are grouped by a salted daily hash, so the pattern is visible without us ever holding an IP address.
Protections for visitors, specifically
The destination is never in the page. It is not in the HTML, not in a JavaScript variable, not in an API response. It appears in a single Location header after the server has confirmed the steps were completed. Nothing in the page can leak it because it is not there.
No referrer leaks to the destination. The final redirect sets Referrer-Policy: no-referrer. Without it, every site a creator links to would learn that their traffic arrives through a link locker, and which one.
Outbound links carry nofollow ugc. These are user-generated links to arbitrary destinations; passing ranking signal to them is how a link locker becomes a link farm.
Nothing auto-redirects. No countdown, no timed forward. You see the destination hostname and you click. Throwing someone at a URL they have not seen is the behaviour that makes this whole category feel untrustworthy.
Creator artwork is hosted by us. An avatar loaded from a third-party host would hand that host the IP address of every visitor to that page. Uploads are validated by magic bytes, never by the declared content type, and SVG is refused outright because it is an XML document that can carry script.
Where we are still exposed
A page claiming otherwise would not be worth reading. Three known limits:
New domains. A phishing site registered this morning passes every check here. Reporting is the only defence, and it is a reactive one.
Destination swapping. A creator can edit a link after it is shared. The denylist is re-checked on every edit and the change is audited — but a clean-looking new domain still gets through, exactly as at creation.
Legitimate hosts, malicious files. A link to a real Google Drive folder containing malware is indistinguishable from a link to a real Google Drive folder containing a font pack. We cannot inspect what we never fetch, and fetching creator URLs would create worse problems than it solved.
Safety questions
Can Keyway tell whether a destination is malicious?
Not reliably, and no honest service claims otherwise. We validate structure, block known-bad domains and flag suspicious patterns. A brand new phishing page on a brand new domain passes every automated check that exists — which is exactly why the report button is on every unlock page and why reports are read by a person.
What should I do if a link sent me somewhere bad?
Report it — the button is at the bottom of every unlock page, or use the report form directly. It takes no account and no email address. If you entered credentials anywhere, change that password immediately and enable two-factor authentication on the account.
Does a disabled link still redirect?
No. A blocked link shows a safety notice and forwards nobody. The destination is never sent to the browser, so there is nothing in the page to inspect either. Status is re-checked on every single request, so a block takes effect on the very next visitor.
How do I know a Keyway link is safe before I complete the steps?
You cannot know that any link is safe, here or anywhere. What Keyway gives you is the destination hostname before you click through — shown in full, never truncated, because the host is the part that tells you whether to trust it. Nothing redirects automatically and there is no auto-advancing timer.
Found a vulnerability in Keyway itself?
Email security@subtounlock.app. We will not take legal action against good-faith research, and we ask for a reasonable window to fix an issue before public disclosure. Our security.txt is at /.well-known/security.txt. Please do not test availability.
Something wrong with a link?
Report it. No account, no email, and every report is read by a person.