Show HN: Protect your links with a password
protectmylink.xyz
Keep your links safe and accessible only to authorized users
protectmylink.xyz
There is nothing inherently bad about .xyz... (that I'm aware of) It's just that because they're cheap they get used.
But anyway I'd expect if someone is naive enough to use this website they would also share the URL and password using a single channel, which would be the same as not "hiding" the URL at all.
Is the operator of this service also able to access the links?
If yes, then right away this claim is not true and merits caution: the random unknown owner of this service can now harvest links which were deemed sensitive enough to merit a password to access.
In the DB all links and password are encrypted. I only have access to the password if I access to the private url and then unlock the url
People also used it for selling files and things but as you've said it was trivial to defeat and only filtered out the least technical folks.
It was surprisingly popular.
I would certainly be running URLs through block lists, with a Report Abuse system if I were doing this today.
Though I’m a bit confused why this is even needed. The sort of thing most people want accessible via a link, but only for certain people, tend to already have unpredictable URLs. I’m not sure how
https://gaggledocs.com/documents/aboevdowugwhoaofh
Is different from
https://protectmylink.xyz/owndoavwyagdo + a password
Especially when the original url is still publicly accessible on the internet.
Additionally, you normally have much better authorization options in the app you’re linking to.
I guess you get the benefit of a changeable link, unlike the canonical one? But then a link shortener is almost enough already.
If you've ever wandered the skeevier parts of the internet (the parts that a teenager not yet experienced at writing search queries might find themselves on if they were trying to e.g. download a software crack/keygen), then you'll frequently find that the pages you land are run by middle-men trying to grab some margin for themselves.
You'll see sites that pretend to be e.g. a torrent tracker or direct-download website, but where all the links actually are indirected by a service like Adfly — a service that interstitials those links with pages full of ads, which pay out to the person who created the links.
And these links often don't even go anywhere after the interstitial; the sites make money off of people hoping the site will work and therefore trying the links at least a few times before giving up.
(This "dark pattern" of an Adfly link pointing at nothing, or at another Adfly link ad-infinitum, is so prevalent that most adblockers just block adf.ly altogether, since an adf.ly link almost never takes the user anywhere useful but is just stealing their attention to no end.)
That's not exactly the parallel here — but I think that's a dark pattern that everyone here has experienced at least once.
The pattern that is applicable here, is another one used by these same skeevy sites: the "unlock the Download button below by clicking the link above and filling out a survey" pattern.
In theory, some of those might even work. (I've been curious and tried a few times, and I've never seen one that actually ever unlocks the Download button. Maybe because I'm not willing to disable my ad-blocker for the "survey"...)
But this service seems perfectly positioned to be used by people building that exact scummy flow. "Go through stupid revenue-for-me-generating process A, and I'll give you the password required to follow link B." (Where link B likely isn't even to something the person themselves owns / has any right to be making money on, but just something they found hosted somewhere else and SEO MITMed themselves in front of.)
---
I would note that anyone that actually wants to charge for their own original content these days... would likely use a platform that both hosts the content and protects it behind a paywall. Gumroad, for example, or Patreon. (Or OnlyFans, even.) Unlike a link-redirection service, these platforms protect the content to ensure that only the people who pay for it will be able to access it — people can't just bypass it by sharing the redirected-to link. (They can re-upload a download somewhere, but that's a much higher barrier to most people, e.g. on mobile.)
Hypothetical design:
1. you generate a password-protected link for a base URL https://origin.example.com/foo — this gives you a generated link https://abc123.link-protector.example.com/ (where abc123 is the generated-link ID.)
2. All *.link-protector.example.com subdomains CNAME to a single service.
3. This service's backend is an auth-protected reverse-proxy. On each request, it checks for an auth cookie unique to the subdomain.
4. If the auth cookie is good (signed by the backend, non-expired), then you take the happy path, where all paths on the subdomain will proxy-rewrite to paths under the original path /foo of the original domain.
5. If you don't present a good auth cookie, then all paths on the proxy subdomain instead redirect to a special /proxy-cgi/auth route, that has an auth system mounted to it. On successful auth, that auth system backend sets the cookie for the subdomain, and then redirects you back to the original path you requested.
(Note that the distinct subdomains per link are necessary here, to stop a malicious user of the service from stealing the cookie of a sibling proxy. You could avoid this by only using one auth cookie for the base domain, and then having every request look up the userID from that auth cookie to map it to a set of links that userID has been authed for — but that's a lot more expensive architecturally than this sort of "the LB can figure it out on its own" design.)
With this hypothetical design, at least the protection wouldn't just strip itself off each time someone fills out the password. Re-sharing the base URL — or any other URL navigated to on the same site! — would just result in the person who receives it also needing to know the password.
I still doubt there's be many use-cases for such a service compared to a vertically-integrated platform like Gumroad/Patreon. People who want to sell the resource would likely still much prefer to use those, rather than stringing individual components together. But I suppose that a password-protected reverse-proxy service would at least let you e.g. turn a public-but-anonymous resource (e.g. a page on a Pastebin-alike) into a members-only resource for a group.
(Even better for that use-case, though, would be if the reverse-proxy service allowed not only password-based sharing, but invite-based or group-based sharing, where link viewers must SSO-authenticate to the reverse-proxy. This would be like Google's BeyondCorp Identity-Aware Proxy, but for stuff outside your GCP VPC, and with one-click setup.)
I received so many phishing reports from Vercel and Cloudflare and even the Italian government directly. It was really tough so I had to add Google's Safe Browsing API check to check for any phishing links. I wish I didn't have to but no phishing reports since then.
On HN, and especially regarding "infrastructure" services that you might depend on indefinitely for something, "what's the business model" isn't a question about how the service will be enshittified. Rather, it's a question of what incentive there is to keep a free service like this running. If there isn't one, then nobody should use the service, because it'll very likely get shut down as soon as it gets popular enough for its hosting costs to become nontrivial.