Hacker News Reader

Comment by tendiesfortwo | Hacker News Reader

I like this idea but wouldn't it be really easy to bypass? Once you pay for it, I imagine you get redirected and can just share the final URL destination for free.

View on HN

My guess is that this is that this is for use-cases where that's not a big concern, or at least where that concern is outweighed by the easy of use.

Some examples off the top of my head:

- I'm selling something to exactly one person - I met someone on discord and I'll sell them a writeup on how to do X in language Y for $5, or I'm selling an art commission or something. I use this service to send them a link.

- I'm selling a somewhat niche infoproduct - the "Expert's guide to using jq to parse stripe data" or something. I expect most people to find it via my blog or newsletter where I talk about jq a lot. I don't think many people will pirate it and I use this paid link to distribute it.

- I'm selling something time-bound, like "Joe's guide to the 2022 world cup tournament for programmers," and I expect that I'll make whatever money I'm going to make on this guide pretty quickly before people get around to sharing the link for free.

- I'm selling something that's paid now, but that I plan to make free next week. "Click this link to buy early access to my yadayadayada!"

If you want to actively prevent sharing of the post-paywall content, Gumroad and plenty of other options already exist for that use-case.

Also: any use case where the final destination link contains a one-time access code for something.

Yeah, this is it exactly. There are definitely valid criticisms of this kind of tool, but people need to understand that there are already a lot of small, niche creators doing this kind of thing manually, e.g. by accepting PayPal and manually emailing Google Drive links to purchasers.

These people obviously don't care much about piracy (and probably don't need to, either) and don't seem interested in setting up another service like Gumroad/Patreon/OnlyFans, so being able to trivially automate their existing manual processes sounds pretty handy.

AFAIK state-of-the-art is requesting a signed URL with a timestamp from whatever system can verify you paid, then presenting that to the file server, which validates the signature and can also elect not to serve links with a too-old timestamp (limiting the damage a leaked URL can do).

This could work for affiliate programs if somehow it is possible to attach an affiliate id into the link. I once created such a product, where affiliates share their payment links and earn on each purchase.

They could fetch the content of the destination URL server side and serve it under the generated paid URL.

Don't ask me about CORS, XSS, CSRF...

Let’s be real, 99% of uses of this will be porn or malware masquerading as warez. You do not want to be fetching those URLs. Removes any plausible deniability.

For third party sites like googledrive I think you're right but if it is your own site, you can restrict based on referer.

Even that is easily forged, although that takes care of some casual sharing arguably.

Yeah, the argument I guess is most people won't go that far over small payments like $2-5 kind of like how news sites have a paywall you can bypass with archive.is

This is a no code solution

For payed digital assets, usually the links are time-limited and/or limited in the number of times you can download.

Can that be done for links to youtube and other platform sites?

It seems to do that securely requires proxying the resource but that’s not a great idea for platform content (It would likely break the site: You would need to rewrite all static and dynamic links to resources in order to host the platform under a different domain. You would also be responsible for bandwidth fees for relaying the content.) and redirecting would expose the platform’s open url to the resource.

Reply on news.ycombinator.com