Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You shouldn't hotlink someone else's JavaScript

beta.whatispolymath.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: You shouldn't hotlink someone else's JavaScript

#71

Post by eric_the_read »

cl8ton wrote: post #67

A car dealer was hot linking to pictures of our cars from a sports car forum I belong to and using them to sell his same models on eBay. We changed to pics of Male Enhancement devices and medication and shared with other car forums, we all watched for days and the guy was pretty clueless on what was going on and apparently didn’t check his ads as often as he should. We even had a vote for what pic appears today poll.…

In the very early days of lolcats, I nearly got fired because an image macro I referenced in an email got replaced, several months later, with.... let's just say it was the sort of image that rivals goatse for disgusting.

Fortunately, my company's IT department had enough of a clue that when I explained what had happened, they agreed it was possible; it was a tense week, though, while they investigated.

I'm not saying the sort of reaction in parent isn't always appropriate, but just be aware that people's lives can be ruined to save a few dollars. I think the OP's solution is ideal: it alerts people to the problem in a very professional way, and provides solutions for the most common cases.

Re: You shouldn't hotlink someone else's JavaScript

#72

Post by jimktrains2 »

This isn't a finished blog post yet, so bare with me.

In http://jimkeener.com/posts/http I have two things which I think would be great additions to both HTTP and HTML.

The first are Content-Signature (signed with the TLS key perhaps)and Content-Hash (format: "hash-algo base64-hash-value") headers.

The second is allowing a hash and/or signature attributes on elements that have a src attribute. This would allow the UA to check if the file is already cached (across domains perhaps too, though I'm not sure how serious collision attacks would be) without having to check the server.

EDIT: I feel that these two features, in combo, would allow for a more secure method of using CDNs for things such as javascript libraries. They would also allow a better fallback method for loading local resources than what is used now.

    
    
    if (!window.jQuery) {
        document.write('   ');
    }

Re: You shouldn't hotlink someone else's JavaScript

#73

Post by benjamincburns »

TheAnimus wrote: post #50
oneeyedpigeon wrote: post #44

Earlier quoted context omitted.

http://caniuse.com/#compare=ie+10,firefox+24,chrome+29

Sure, I don't mind if bits don't work, if I miss out on some WebGL stuff or similar. But to just put up a big fuck you, to what is the second most popular or most popular browser as a whole isn't helpful. It reminds me of people using Java Applets for navigation in their frames webpage.... Actually I did that once, I was however 11, and this thing had a spinny thing. Sure, do cool stuff that requires features which s…

> Sure, do cool stuff that requires features which some browsers miss, use feature detection to flag that.

To be fair, graceful degradation is still a ton of work. It's fine if you're using neat-o features for superficial things (round ALL the corners!). However when you decide to rely on newer tech for more core site features, it means you wind up having to code, and test, twice. Once for the real features in the preferred environment, and once for the degraded features in the non-preferred environment.

If you don't have the resources but you still want to use the stuff with limited support, I think it's polite to include a "hey, we don't test for your configuration so feel free to give us a try, but we apologize if things don't work correctly" banner. I think it's also polite to warn your users where you know things are just painfully broken. "The experience is bad here for users with your configuration."

Re: You shouldn't hotlink someone else's JavaScript

#74

Post by benjamincburns »

jimktrains2 wrote: post #72

This isn't a finished blog post yet, so bare with me. In http://jimkeener.com/posts/http I have two things which I think would be great additions to both HTTP and HTML. The first are Content-Signature (signed with the TLS key perhaps)and Content-Hash (format: "hash-algo base64-hash-value") headers. The second is allowing a hash and/or signature attributes on elements that have a src attribute. This would allow the UA…

Well it just so happens that the IETF is working on the http 2.0 spec now. See https://github.com/http2/http2-spec

Re: You shouldn't hotlink someone else's JavaScript

#75

Post by jimktrains2 »

benjamincburns wrote: post #74
jimktrains2 wrote: post #72

This isn't a finished blog post yet, so bare with me. In http://jimkeener.com/posts/http I have two things which I think would be great additions to both HTTP and HTML. The first are Content-Signature (signed with the TLS key perhaps)and Content-Hash (format: "hash-algo base64-hash-value") headers. The second is allowing a hash and/or signature attributes on elements that have a src attribute. This would allow the UA…

Well it just so happens that the IETF is working on the http 2.0 spec now. See https://github.com/http2/http2-spec

Yes, that is what my response was in response to. In fact I believe I link to it (not the github version but on the ietf site).

However, I felt that some of the points I brought up in what I'd like to see were relevant to this discussion, even if the entire blog post isn't. This is why I highlight the points that are relevant in my comment.

Re: You shouldn't hotlink someone else's JavaScript

#76

Post by cl8ton »

eric_the_read wrote: post #70
cl8ton wrote: post #67

A car dealer was hot linking to pictures of our cars from a sports car forum I belong to and using them to sell his same models on eBay. We changed to pics of Male Enhancement devices and medication and shared with other car forums, we all watched for days and the guy was pretty clueless on what was going on and apparently didn’t check his ads as often as he should. We even had a vote for what pic appears today poll.…

In the very early days of lolcats, I nearly got fired because an image macro I referenced in an email got replaced, several months later, with.... let's just say it was the sort of image that rivals goatse for disgusting. Fortunately, my company's IT department had enough of a clue that when I explained what had happened, they agreed it was possible; it was a tense week, though, while they investigated. I'm not sayin…

100% agree with you, always weight damage it may cause.

In the case I mentioned, this was a well known bad actor in the auto circles known for ripping first time buyers off with shady tactics and misrepresenting facts.

Re: You shouldn't hotlink someone else's JavaScript

#77

Post by hfsktr »

ballard wrote: post #29
jacquesm wrote: post #12

And that's a pretty mild example of what could happen if you did. Hotlinking javascript is an excellent way to allow someone else to pull all kinds of tricks with your visitors and your image. For example, redirecting all your traffic to a shocksite. Every time you include some externally hosted javascript you open yourself and your visitors to a security risk. And on top of that, if you do it like this you're steali…

The standard pattern is never use external dependencies directly, but to keep copies and host them on your CDN. That way, you can run them through the ol' asset pipeline too... minifiers and possibly serve them straight from gzips. Gotta always remind ppl of https://developers.google.com/speed/ ... the OP scores 47 (out of 100)

I didn't even know that existed. After checking my site it's just a reminder how little I know.

Re: You shouldn't hotlink someone else's JavaScript

#78

Post by readme »

marshray wrote: post #35
jacquesm wrote: post #13

Earlier quoted context omitted.

Compared to what could have happened this is actually pretty mild.

Everyone these days is so polite. OK, that was a bit of an exaggeration. But back in my day the web had a whole site high-bandwidth site specifically for educating careless webmasters about the dangers of hotlinking: g o a t s e . c x. It was used to great effect on things like auction sites where the original page html was not allowed to be changed after listing.

I'm not sure if politeness is the motivator. Imagine if you had done that, for all hotlinks to your script. Then, it turns out a children's website is hotlinking your script.

Some idiot at Company X decides that it's actually your fault, since its your script that did it. To save face, they get an expensive lawyer to sue you. Next thing you know, you're a registered sex offender.

Re: You shouldn't hotlink someone else's JavaScript

#80

Post by nly »

PommeDeTerre wrote: post #55
UnoriginalGuy wrote: post #54

Earlier quoted context omitted.

It is specifically mentioned in our privacy policy. We also use Google Analytics, so that ship has sailed.

Nonsense. Users can very likely block Google Analytics on your site with ease, and without impacting the rest of your site's functionality. That's not necessarily the case when more critical content is served from Google's servers. Regardless of what your privacy policy states, the responsible thing to do is to at least give your users the option of opting out of such tracking by third-parties, all while still leavin…

> the responsible thing to do is to at least give your users the option of opting out of such tracking by third-parties

Reddit do this. You can choose to load their js from their own servers rather than a CDN.

Post reply on HN