The article proposes one solution as being to essentially serve up different content to whoever is hotlinking the script, but then says "Obviously, I don't wanna do this." It seems like the clearest solution to me, so I don't know why it's a bad option.
The replacement solution worked for 3D Realms many years ago after a bunch of journalists, fansites, and forums would link to their game screenshots. When someone did, their image would be replaced with Duke Nukem dressed up as Uncle Sam, pointing at the screen, and captioned with something like "Duke wants you to host your own images"
I guess I'm one of those anti-social people, because my first thought was that anyone hotlinking a script from your server without permission is basically inviting you to deface -- uh, I mean, "creatively redesign" their website for them for free.
Instead of a nasty console message or popup, modify the script to ping back more detailed and useful information about where its being used. Then contact the developers.
Edit: you don't even need to write anything dynamic to receive the ping back, just have the script load an image from yoursite.com/specialprefix/the useresencodedbrowserurl/anythingelseinteresting/1.png then look in your server logs for any 404 errors with the prefix?
Isn't the site owner in charge of GDPR for the site? Aren't they already non-compliant by hotlinking a resource from someone where there's no agreement about personal data? Wouldn't it still be the site owner's responsibility not to let a 3rd party send even more personal data over?
I'm not an expert on GDPR at all so forgive me if these are dumb questions but how? I thought GDPR pertained to a user's personal info? Sending back info about the webpage the script is used on isn't the same. Also who would be in violation, the leachers or the OP? Does GDPR even apply if OP is just a random person on the internet and not a company operating in the EU?
I might be missing something, but people who hotlink your scripts aren't your customers or users, and you shouldn't have any obligations towards them. Can people hacking your site sue for GDPR violations to get you to delete the logs of their hack?
I would just add some console.log message explaining the issue you have with hotlinking the script. This will not disrupt users, but anyone who fires up their devtools will see that the site is getting shamed. And if their devs care just a little bit, I think they will find it embarrassing enough to host the script themselves.
Correct me if I simply have missed it, but is there an official NPM package available? I have seen https://www.npmjs.com/package/sorttable and perhaps some of the sites would drop the script tag if "npm install --save-dev sorttable.js" is in the instructions and they have a build step for their JS anyway. Just thinking out loud.
I've found that companies where they've done this (hotlinked) often have incompetent or overburdened people, and this shaming wouldn't even register.
Hotlinking code like that though is just plain stupid from the liability perspective. If they are a business, they should be worried about 3rd-party liability.
The fact that they are doing this makes the website hosting the script, a nice juicy target for watering hole/supply chain attacks.
What are they going to do if that happens? Its not like business insurance will cover that.
"Thank you for using SortTable from https://www.kryogenix.org/code/browser/sorttable/. If you, the site owner, would like to use SortTable without this notice, please download the script from [here](URL link) and add it to your server."
If you want to get fancy you can serve the modified script only if it's being hot linked and the original script if it's being used on www.kryogenix.org - or another website that has permission to use the script.
I think this is a brilliant solution - you can also make it the second row in the table that's being sorted (right after the table header). That way there's no breakage and it's a good enough deterrent.
I would go on further and make a link to a Stripe Checkout page that allows you to purchase a license subscription to remove the notice.
Probably the nicest way to handle this is to serve the JS slowly.
It doesn't break their page if you take ten seconds to serve the JS, but it makes their page slow, and nobody likes a slow page. And it's pretty obvious where the slowdown is coming from.
If it's easy, make it fast from your site and slow if the referer doesn't match or isn't present. Or just make it always slow, whatever.
This also has the natural consequence of limiting the bandwidth spent serving third-party hotlinked downloads. But the expense of the bandwidth is the primary problem with hotlinking, AFAICT from the article.
I could imagine two network interfaces, or two LBs, one internal and unmetered, another external, which serves a particular amount of megabytes per day, and throttles connections accordingly. Maybe even add some HTTP header, like X-bandwidth-limit: "Dear hotlinkers, I'm not going to spend more than $5 / mo on serving you; host your own copy."
> There are many CDNs, and using resources served from them is not a bad thing.
I disagree. Public CDNs (which is what I take the sentence to be referring to) can be convenient for prototyping, but should be completely avoided for production work. Due to HTTP/2+, cache partitioning, and the ease of private CDNs (which were difficult and expensive even ten years ago, whereas now it’s common for entire sites to be hosted on a private CDN), public CDNs no longer offer any benefit at all in most common/sensible scenarios, and negligible benefit in the near-worst-case scenario, but have performance costs (establishing an extra HTTPS connection) and introduce significant functionality and security risks.
Another solution: when the script is hotlinked, add a new row in the sorted table, saying "You're using a hotlinked version of sorttable.js - please host on your own webserver or purchase a license here". This way, the sorttable.js is not broken for any users, it's still usable, but there's an "ad" that's both a deterrent and an upsell.
Can't you disallow external links that will redirect to a dynamic error page?
Things like HTTP Referrer, coupled with a set of rolling dynamic headers so actual site visitors aren't impacted, or significant rate limiting, or a simple non-malicious HTTP widget injection that sends a simple message, stop the unauthorized hotlinking.
You could even take it a step further by evaluating at the packet header level but that's a bit of a setup.
Isn’t there a way to do this by looking at the Origin header or something? What you want is for the download link to work, but when the page is hot linked, the origin header won’t match and the link will be broken. That should be doable with a simple nginx rule.
You might not want to break the existing web link (if you don’t want to break existing sites). But you could move the link to the javascript code somewhere else which has this origin guarding behaviour.
Edit: There’s a better suggestion down thread. Put the javascript file in a zip file and let people download that. Brilliant.
In general the "best" solution here is to have URLs with a time-limited token. S3 and the likes make this pretty easy to set up, but there's no reason you couldn't roll your own solution.
Readit News
The replacement solution worked for 3D Realms many years ago after a bunch of journalists, fansites, and forums would link to their game screenshots. When someone did, their image would be replaced with Duke Nukem dressed up as Uncle Sam, pointing at the screen, and captioned with something like "Duke wants you to host your own images"
Pretty much the same narrative as what that Liberty Liberty Liberty guy did when he upped the semver noting a breaking change and pushed it.
Deleted Comment
Edit: you don't even need to write anything dynamic to receive the ping back, just have the script load an image from yoursite.com/specialprefix/the useresencodedbrowserurl/anythingelseinteresting/1.png then look in your server logs for any 404 errors with the prefix?
Correct me if I simply have missed it, but is there an official NPM package available? I have seen https://www.npmjs.com/package/sorttable and perhaps some of the sites would drop the script tag if "npm install --save-dev sorttable.js" is in the instructions and they have a build step for their JS anyway. Just thinking out loud.
Hotlinking code like that though is just plain stupid from the liability perspective. If they are a business, they should be worried about 3rd-party liability.
The fact that they are doing this makes the website hosting the script, a nice juicy target for watering hole/supply chain attacks.
What are they going to do if that happens? Its not like business insurance will cover that.
"Thank you for using SortTable from https://www.kryogenix.org/code/browser/sorttable/. If you, the site owner, would like to use SortTable without this notice, please download the script from [here](URL link) and add it to your server."
If you want to get fancy you can serve the modified script only if it's being hot linked and the original script if it's being used on www.kryogenix.org - or another website that has permission to use the script.
I would go on further and make a link to a Stripe Checkout page that allows you to purchase a license subscription to remove the notice.
It doesn't break their page if you take ten seconds to serve the JS, but it makes their page slow, and nobody likes a slow page. And it's pretty obvious where the slowdown is coming from.
If it's easy, make it fast from your site and slow if the referer doesn't match or isn't present. Or just make it always slow, whatever.
I could imagine two network interfaces, or two LBs, one internal and unmetered, another external, which serves a particular amount of megabytes per day, and throttles connections accordingly. Maybe even add some HTTP header, like X-bandwidth-limit: "Dear hotlinkers, I'm not going to spend more than $5 / mo on serving you; host your own copy."
I disagree. Public CDNs (which is what I take the sentence to be referring to) can be convenient for prototyping, but should be completely avoided for production work. Due to HTTP/2+, cache partitioning, and the ease of private CDNs (which were difficult and expensive even ten years ago, whereas now it’s common for entire sites to be hosted on a private CDN), public CDNs no longer offer any benefit at all in most common/sensible scenarios, and negligible benefit in the near-worst-case scenario, but have performance costs (establishing an extra HTTPS connection) and introduce significant functionality and security risks.
For a good article with some more detail: https://httptoolkit.com/blog/public-cdn-risks/
Things like HTTP Referrer, coupled with a set of rolling dynamic headers so actual site visitors aren't impacted, or significant rate limiting, or a simple non-malicious HTTP widget injection that sends a simple message, stop the unauthorized hotlinking.
You could even take it a step further by evaluating at the packet header level but that's a bit of a setup.
You might not want to break the existing web link (if you don’t want to break existing sites). But you could move the link to the javascript code somewhere else which has this origin guarding behaviour.
Edit: There’s a better suggestion down thread. Put the javascript file in a zip file and let people download that. Brilliant.