Live data from Hacker News

You shouldn't hotlink someone else's JavaScript

beta.whatispolymath.com

51–60 of 102 posts

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

#51

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…

Oh, I totally agree - the link was just to answer the "what doesn't IE10 support" question, which you didn't really ask ;)

Having said that, the site in question is aimed at developers and designers, most of whom [1] will be using something other than IE. So this isn't the worst example out there.

[1] Yes, of course, this is pure conjecture, and I don't have any figures to back that up. Doesn't stop it being true, though.

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

#52
post #15

Earlier quoted context omitted.

Well, I see it as a great reminder why one shouldn't trust scripts hosted elsewhere into one's site.

I use Google and I'm comfortable with that. The nice part about using Google is first off it offers speed advantages (as most people will have Google's JQuery lib cached already), secondly I don't expect Google to get hacked, and lastly we have Google's permission to do exactly that.

So, do you think your visitors have a problem with Google knowing about every visit to your site?

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

#54
post #52

Earlier quoted context omitted.

I use Google and I'm comfortable with that. The nice part about using Google is first off it offers speed advantages (as most people will have Google's JQuery lib cached already), secondly I don't expect Google to get hacked, and lastly we have Google's permission to do exactly that.

So, do you think your visitors have a problem with Google knowing about every visit to your site?

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

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

#55
post #52

Earlier quoted context omitted.

So, do you think your visitors have a problem with Google knowing about every visit to your site?

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 leaving your site usable.

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

#56
post #5

Ok there is a better way to handle this than adding some html to a page to make a banner, posting to HN, and hoping for the best. Check for referal headers and throw a 301.

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

The banner has even a close button, so it will not stay on top forever. It's extremely polite.

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

#58

Earlier quoted context omitted.

The standard pattern is never use external dependencies directly, but to keep copies and host them on your CDN. For dependencies you can control, it's obviously best to keep a local or CDN copy. However this trend of embedding js from all over the web is encouraged by the pattern that most of the big sites allowing you to embed content use: e.g. https://developers.google.com/+/web/badge/ Google, Twitter, FaceBook all…

One thing that will happen is that domains that get abandoned that used to host benign js will get taken over by the jerks. That's very hard to protect against, and with the rate at which start-ups encourage people to embed their tags I'm kind of surprised there hasn't been a significant incident like that.

Good point. I imagine you could make a pretty penny by hijacking credit card detail entry forms.

To evade detection you can even have the hijacking code only included on pages that actually collect credit card info.

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

#59

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…

If Google's CDN is unavailable it falls back to a local copy we host. Inline with this example: http://stackoverflow.com/questions/5257923/how-to-load-local...

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

#60
That's interesting way to warn users of the err in their ways. I recommend the CDN route for anyone who is standing up a web application for performance more than anything. With a CDN the page load time on my site went from 1.5 second to under .5 seconds. You also get the added benefit of someone not injection code into your website.
Post reply on HN