Show HN: Protect your links with a password

[jcabrera]

Keep your links safe and accessible only to authorized users

[bluish29]

The choice of.xyz tld is not the best choice for a security service. It is one of the worst tlds when it comes to scam.

https://news.ycombinator.com/item?id=28554400

[senectus1]

I own a couple of .xyz just for my own self hosting stuff... I got them cause they're cheap.

There is nothing inherently bad about .xyz... (that I'm aware of) It's just that because they're cheap they get used.

[jcabrera]

I'ts because .xyz is just cheap :)

[laurent123456]

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.

[Algemarin]

> 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.

[jcabrera]

Hey!

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

[dec0dedab0de]

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.

[thefilmore]

End-to-end encrypted, open-source, ~250 lines of code, password optional, and not just for links - https://plic.cc

[LVB]

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.

[jcabrera]

Thanks! I forget about it. I just added :)

[solardev]

If it's just a redirect, isn't it going to be bypassed as soon as the first user shares the real URL?

[graypegg]

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

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.

[jszymborski]

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.

It was surprisingly popular.

[hosteur]

That was my thought as well. Not sure what the actual value is here.

[n_ary]

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.

[shahzaibmushtaq]

Take this as a fun project to improve your coding skills.

[edoardo-schnell]

Plain text password?

[derefr]

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.)

[derefr]

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.

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.)

[LoganSnow]

Alternative that is open source and fully client side: https://jstrieb.github.io/link-lock/create/

[NayamAmarshe]

Great project! I too have an open source link shortener that supports password protected websites: https://maglit.me

[zoidb]

So many link shortners eventually shut down due to people trying to obfuscate illegal stuff. Have you had any issue yet with that?

[oron]

What's the biz model ?

[frankwiles]

I hear what you're saying, but people DO just put stuff out there for it to exist and aren't necessarily looking to monetize it. Crazy I know :)

[n_ary]

A hobby project does not necessarily have to be needed or valuable to everyone. The learning experience of the author is much more valuable.

[pvg]

Omit internet tropes.

https://news.ycombinator.com/newsguidelines.html

[import]

The website was inaccessible for me then I remember I’ve blocked xyz domains in my AdGuard