You're correct. Here's how we think about this:
If someone wants to get a particular Leanpub book without paying for it, they have a much easier way to do it:
Buy it.
Download it.
Click the "request refund" button.
We have no DRM or even watermarking in our PDF, EPUB and MOBI files, so this bad actor could even post the files online. (Here's an article we've written setting out our position on piracy and DRM: http://help.leanpub.com/en/articles/117407-should-i-worry-about-piracy-does-leanpub-do-anything-to-protect-me-from-piracy).
(If the above process happens too much with one account, we ban it. However, it's pretty easy to make a new account.)
What we do rely on is the following:
Most of our customers are honest.
Our refund rate for almost all our books is under 2%, and this is particularly impressive given that these are self-published, often in-progress ebooks.
We think that the fact that we pay high royalties (80%) to our authors, and that we surface this during the checkout process helps contribute to this. (However, this could just be a case of fundamental attribution error, and it could have nothing to do with us at all!)
Now, in terms of stopping bot attacks like you propose, there are basically two choices:
a) Require authentication for downloads. This would be the most secure, and also the most inconvenient for our customers. (New readers would have to use a forgot password workflow if they want to download the book later, etc.) We have considered doing this for the very reason you bring up.
b) Rely on obfuscation of download links. Yes, this is "security through obscurity", which is obviously not true security.
So, we choose option (b), and we use pretty good obfuscation. Our short URLs are a UUID which are base 64 encoded (using URL-safe characters). So, if you wanted a given book, and that book had, say, 10,000 previous purchases, you would have to guess one of the 10,000 UUIDs in a 2^128 (3.4028237e+38) number. This would take you a while, and chances are the IP address(es) which were making the requests would be noted and banned first. (Guessing random UUIDs is a lot harder than it would be if we made the filenames something like http://leanpub.com/s/1.pdf, http://leanpub.com/s/2.pdf, etc :)
For us, it is not worth causing all our legitimate customers some inconvenience just to implement slightly better security--especially since this can be circumvented by simply abusing our refund process.
Instead we just choose to treat our readers as we like to be treated when we are customers: with respect, and not like criminals. We hope that this policy is appreciated by our customers (both readers and authors), just as we appreciate both of their business.
We quite often say variants of "thanks for being a Leanpub customer" at the end of emails to readers and authors, and we actually do mean it. So, we try to act that way as well...
Peter Armstrong
P.S. Obviously, if option (b) plus detection proves to be unworkable as Leanpub grows, then this issue will be revisited, and we reserve the right to switch to option (a) at any time. However, we're happy that we haven't had to make this switch yet, and hope to continue this way for many years to come...
If you have any feedback or questions about this article, please email the Leanpub team about it at hello@leanpub.com!
If you have any questions or thoughts on writing and self-publishing with Leanpub, please join our global community of authors in our Authors Forum here!
Are you interested in self-publishing, and creating your first Leanpub book? Here are some quick tutorials for our most popular writing modes: http://help.leanpub.com/en/articles/3088382-quick-walkthroughs-for-getting-started-on-a-leanpub-book
Are you looking for great deals on Leanpub ebooks, ebook bundles, and courses? Sign up for our Weekly and Monthly newsletter sales here!
To learn about amazing new books and authors, subscribe to our YouTube channel here: https://www.youtube.com/leanpub
You can also follow Leanpub in lots of other places!
