Would be more interesting if the link was encrypted client-side using the provided key. That wouldn't change the UX much and it means you can guarantee that the shared URL will remain private.
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.
> Keep your links safe and accessible only to authorized users
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.
This has got to be a scam. if your data need to be secure then use authorization and authentication. If you need to keep a link secret then don’t share it with some random website. This isn’t rocket surgery.
Along the lines of some other comments here, this would benefit from some documentation about privacy, terms, are they trying to make a business from this, what they’re doing with the data, etc.
I guess since you’re going to have to give a password to someone, you can tell them not to do that.
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
I ran a similar service when In was in high school. People were using it to distribute links in public settings that were meant for small circle of folks. Lots of club newsletters were distributed this way.
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.
I, too, ran a similar service in high school. It also got weirdly popular, and then spammers started using it and the FBI sent a shutdown notice to my server provider while I was working at a summer camp (with no internet access) and all my sites got taken down for a week :(
Especially since links can already be pretty private by default if they are random enough and not shared on any site where a crawler can access them. If you want actual security, you need to protect content on your end. If you don't really care and just don't want it publicly indexed, share it privately and keep it off the surface web.
I suppose it is the same concept as gumroad vendors. Most of them simply put an s3 url behind the gumroad paywall. Once you are done buying, the s3 url can be shared with anyone.
True, but most stuff I bought from gumroad, url never expires. Guess, we tech folks are conditioned to think too much into basics that non-tech folks don’t think about.
I would point out that this will likely be used 99% of the time by people who want to charge for access to content... that they don't themselves own.
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.)
Tangent: I would note that a "password protect an arbitrary link" service could actually be made into a "thin, just-in-time" form of one of these services... by not being a redirect service, but rather being a dynamic, fixed-URL-prefix-route reverse-proxy service.
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.)
Oh yes, of course! I had to remove links several times. Even around 2AM at night.
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.
What's your alternative? Nobody wants a corporate solution, but they do want free services that fly under the radar. Of course not all of them last forever, but what better choice is there?
It is crazy for someone to expect someone to use a service that has a 99% chance of getting shut down in a year when the domain name needs to be renewed. If there's no plan, there's no reason to use this for anything, ever.
I hear what you're virtue signaling, but people DO have a right to wonder what will happen if a link redirect service runs out of money and kills their links
https://news.ycombinator.com/item?id=28554400