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?
The request would send back personally identifiable information (IP address), which if the OP stored (say in an access log), without establishing a legal basis, then it would be a GDPR violation. By OP, since the tracking is occuring on their server and not at the behest of some other data controller.
If OP has server logs, that is already happening anyway since the initial request to load the script is coming from the users' browsers, not from the site linking to it. That might be a reason in favor of disallowing the linking entirely even though it would negatively impact the users of the sites doing the hotlinking.
And just to be clear, a legal basis can be established even without user consent via Article 6.1(f) — "legitimate interests" [1]. Though it is a grey area and not well-tested in courts (AFAIK) how to balance those interests against the data subject's rights, in any particular specific context, such as the one currently being discussed.
For instance, I've seen plenty of claims that storing IPs in logs is fine for "security purposes", though I don't know of any court cases specifically affirming that.
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 mean, every single tracking pixel on the web is a GDPR violation, unless they've established a legal basis to do so. As basically all of noyb's complaints being upheld by DPAs shows, most fail to do so, clinging on to legitimate interest when they fail the balancing test, or consent when the consent form is too deceptive or tipping the scale to count as freely given
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.
> It’s a bit of an anti-social practice, to be honest
Isn't so-called "hot" linking an intended and useful feature of the web? Linking to something directly so that you don't need to copy it to a new server and pollute the URL space with duplicate objects?
Maybe someone can invent a way of caching or replicating web content so it doesn't overload the original server and its internet connection. There might even be a business opportunity, "Caching Distribution Nodes" or something....
> There are many CDNs, and using resources served from them is not a bad thing. That’s not what I’m talking about
I see.
That being said, I like the idea of hierarchical URLs that could address anything on a web page, including items that are linked from elsewhere. Maybe something like:
I read your comment and I thought this was going to be about "links"... but it isn't: it is about embedded resources like scripts or stylesheets. I am with the author on this one: it is really annoying and definitely "anti-social".
I've had people do this to me and then I go to update my stylesheet on my website and suddenly a ton of other websites I use are broken and I was like "wtf". After trying to get people to stop directly embedding it and realizing the problem was just too widespread, I ended up having to freeze an old copy of my stylesheet at the fixed URL that everyone was using and now I generate random URLs for my new stylesheet updates (that both look like something you shouldn't rely on and which do disappear later).
(FWIW, I will say that the random URLs are probably a better solution anyway as if you are going to have a stylesheet used by various pages of yours it is difficult to do an atomic upgrade of the resource and the pages that use it without momentarily breaking some content. My "random" URLs are actually hashes and it is honestly better than what I had before.)
Hashes are also what most static site generator and build system use nowadays. This allows for immutable caching which allows the browser to cache the resource indefinitely which just makes things simpler https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...
> Linking to something directly so that you don't need to copy it to a new server and pollute the URL space with duplicate objects?
1. Only if bandwidth is free. Which is not the case if you're sufficiently popular.
2. It makes you responsible for other people's web sites working correctly. Would you personally like to have that burden? The original article's poster isn't too happy about it.
3. It's bad practice because if the original host does not care about other people's web sites working correctly, who knows what your viewers will download next time? Perhaps a new and improved version that includes a bitcoin miner? Ok that's out of fashion. Perhaps a 0day exploit then?
4. Even if no bitcoin miner or 0day exploit, you're allowing a 3rd party to interact with your viewer. This is a privacy risk if you hotlink from the likes of Google or Facebook isn't it?
People who do this are probably just ignorant (under-skilled), not necessarily antisocial.
Doing this obviously risks your own site breaking if the linked source changes anything or goes away. That’s a serious risk which no reasonable web developer would knowingly accept.
I think the author is rather being cruel in their kindness. You don't enable other people's failings out of kindness, as you are damaging their future.
You have no obligation for other sites' users. The maintainers of those sites have that obligation, and if their site breaks due to hotlinking, it is 100% their problem. You aren't hurting their users; they are hurting their users.
You would be doing them and their users a service by teaching them a lesson. It's not just "anti-social", it's plain dangerous to integrate untrusted/uncontrolled code into your site.
Mostly I had issues with folks hotlinking some of my higher resolution images in their own site/blog/forum posts and claiming it was their work. I set up the rewrite rules after noticing a big spike in bandwidth utilization and seeing a bunch of requests in the logs. Referrer took me back to the offending pieces.
It was suggested to use some sort of shock image instead, now that would be antisocial!
The same origin policy restricts any load that would provide JS with data from a different origin. Note that I did not say it blocks all loads: this is specifically restricting JS access to content from other services. CORS was introduced so that it was possible to selectively provide JS with access to such data - previously you had to use JSONP which has bad security properties for the client and server. CORS is what lets JS on your site make an XHR to a remote API provider. Nothing stops you from simply creating an arbitrary element with an arbitrary src attribute (if relevant of course), and triggering a network load. It’s just that most such elements don’t convert the server response into data that can be subsequently accessed in JS, the ones that do (img, etc) can only be read via APIs that themselves enforce same origin restrictions (eg I can create an image element and point it to a remote server, then draw that image into a canvas. At that point the canvas element’s various read APIs will stop working as the canvas knows that it’s been tainted).
If you were to make non-same origin loads fail in the general case you would break everything.
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"