Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

Interesting idea, but I see two main issues with this.

First, anyone who pays and gets to the resulting link can trivially share that link; of course, you can always ask them nicely not to do so, and in some contexts that will work, but in general the security model just doesn't work unless you authenticate each paid user at the destination. You need to come up with an answer to this.

Second, if you market this as a link shortener which requires payment, I think you'll get backlash from people who currently use link shorteners to share links on Twitter and similar; from that perspective it feels like the kind of thing you'd see used by Twitter spammers/scammers. Suggested fix: flip it around, and present it as an astonishingly simple payment system based on URLs, which happens to behave like a shortener.

View on HN

I think #1 is a bit of a red herring. The security problem is not what this is solving. It's the ease of getting paid for some content, with less hassle overall.

Keep in mind that this is digital content so anyone could just rehost/resell/redistribute anything they bought or downloaded. But for something low-payment enough or the average silly download, why would they bother?

It's important to tell sellers that it's insecure so they don't assume it's locked, but please don't complicate this by adding DRM or sharing prevention. The most I'd do here is track downloads and let people kill their link and repost it if they sense abuse.

The difference: sharing the file violates the original author's copyright, but sharing the URL to it on the original author's site doesn't.

I actually wouldn't recommend adding DRM or sharing prevention. Instead, I'd just add a lightweight system to make it trivial to know who shared the URL. That will likely do wonders for getting people to play nice.

Optionally, you could add proxying through the gumroad site as an extra feature (perhaps at the cost of a higher margin on the sale), for people particularly concerned about the issue.

That second formulation is how I thought of it in the first place.

You could get around the link-sharing problem for those that wanted to avoid it by offering single-use URLs, and provide Gumroad either with a way of generating a new single-use URL for your resource, or a way to pull a new URL from your site. Both of these methods would require some degree of control over the resource, however (you wouldn't be able to do this for content hosted by third parties).

For those who aren't fussed about security, you could offer it as a really easy way to optionally pay for content - eg a rapid "Donate" method.

We used something like this for our content at Naughty America.

For each page request we'd generate a link to the file on BitGravity with a timestamp, expiration, and filename, and a hash generated from those concatenated with the requesting IP and a secret key. On BitGravity's end, they'd re-hash everything, and if it matched up they'd serve out the file.

Interesting, I didn't think about the implications of "donate."

Kind of tangentially, I wonder if there's value in letting a user select a charity to donate all of their sales to (no pressure on the user, just an option)?

To address the first problem, you should offer a passive solution and not require the user to set up anything special in the way of single-use URLs. In fact, I assumed the issue of payers sharing the end-link was such an obvious problem that the service would have already addressed this and had it built-in by default (but of course, MVP/first-release, I understand).

The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.

Sure, that would make sense for content that could be so served (for example, the pencil icon used as the example here) - but not all content is like that. What about content you want people to interact with (a blog post on your site, a special beta registration form)? You also take on all the problems of becoming a content distributor rather than a link distributor.

I agree with everything you said. If this were my project, these are all problems I'd be thinking about and trying to address. Looks like you're on the right path ;-)

I'm thinking about them hard. :)

and I would add that the content distributor problem is also a good one to solve (with your solution). May even be more profitable... a lot of people want to sell stuff, not link.

Another interesting variant might be: payment unlocks the destination link for X minutes. (After that, the true destination URL is changed somehow. Yes, that adds complication on the true hosting site or the necessity for Gumroad to proxy.)

So in a sense you don't care if people share the link for that period... maybe you even want them to, like a time-limited offer, so that they post to all their friends, "get it while it's hot!"

(The price could also rise or fall after each purchased open-period... perhaps even, depending on the number of downloads during the last open period.)

I like the idea of the proxy, why not have it so you do a direct link and gumroad takes a small percentage (1%?), and if you want it proxied gumroad takes a bigger percentage (5%-10%)?

Here's how I would structure things to mitigate link sharing. It won't prevent it entirely, but will reduce it about 100x without affecting UX.

Your links can be one of two things: 1) a webpage, 2) a file.

For a file, I wouldn't worry about the DRM, as a person serving the file can have their own system, or you can use the system I'm going to propose for serving a webpage.

Essentially just use an iFrame.

So you have your public link: gumroad.url this leads to a paywall which then sends you to an auto-generated one-time link of gumroad.paidurl. This url is a simple page that loads an iFrame with the real private URL.

So gumroad.paidurl and gumroad.url both go to a paywall when user 2 tries to access it. And either paidurl or url will be the one that's shared. Yes, people can circumvent it by looking at the source of the iFrame, but 95%+ of people won't bother, and it's a heck of a lot easier than downloading and displaying the page through AJAX or server side.

I haven't thought much about this solution, but wouldn't it be simple to just proxy the content back to the user? This would work fine for downloadable goods, maybe not so much for secret links to sites.

Think long term adjustment to the mentality of the site. If that link was worth something, why would the buyer just give it away? It's possible that the buyer would try to sell it and compete with the original seller, and all subsequent buyer might follow, but that would be something the original seller could take into account in pricing their product.

I agree that the link shortening aspect of this site cannot be it's product. Emphasizing that at all can detract from the truly novel idea that exists in selling and buying micro-properties of internet knowledge. People need to see the incredible nature of a site which allows you to sell information which has high demand and low supply, but has no other method of paid distribution. For everything too small to put in a book, and not small enough to just give away. I think its brilliant.

The service could send a special "auth" key along as parameter when forwarding. E.g.: http://example.com/secret.php?key=dh498

In secret.php on your server you could then ask the Gumroad API (via another http request) how often this key was already used and deny or allow access. This would be super easy to implement for the seller - just paste in ~5 lines of PHP code.

You could allow access to that link about 5 times. After that, display a link that says something along the lines of "Thanks for using us. This link has been used 5 times already. If you wish to access it again, click here and we will send you an email with another authorization code (or whatever)". That way your users don't lose access to their stuff, and you can keep track of abuse. It's not a perfect solution, but it's better than nothing.

Reply on news.ycombinator.com