Wondering what to do (if anything) about hotlinking
kryogenix.org
kryogenix.org
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.
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?
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.
[1] https://gdpr.eu/article-6-how-to-process-personal-data-legal...
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.
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:
https://example.org/page.html/resourcename.ext
Then you could easily reference a page where the original item is located, and browsers could easily go there.
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.)
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?
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.
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.
http://www.glitchwrks.com/images/general/hotlink.gif
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!
still super effective.
wtf
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.