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 stealing bandwidth.
When including remotely hosted javascript make sure you have permission, make sure the other party is trustworthy and periodically review the linked script to make sure it does what is advertised (and that's imperfect, it could be you're seeing something else than other visitors).
"It would mean coordinating updates of the digest to all referencing sites though, which might make it practically impossible."
You just put the version number in the name somewhere and make deployments immutable. Otherwise you have everything you need for that already, technically, though you might want to add a fallback to a local clone of the resource or something so it isn't just a failure.
The security risk is precisely why a lot of new services provide embeddable content via iframes now, rather than JS. On the other hand, this still isn't perfect - we wrote about it today, actually: https://www.tinfoilsecurity.com/blog/protect-your-website-fr...
Iframes do suck. However, success of a whole crop of companies like Disqus depends on it sucking less. I am sure this is a known issue for these companies.
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:
Google, Twitter, FaceBook all want you to embed js hosted on their servers in your page in order to interact with their site, even if all that script does is then insert an iframe into the page. By including a button or widget like the one above you're trusting them not to take over your site in a manner similar to this example, track your users surreptitiously, or be compromised now or in the future.
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.
Interesting, Google has added more stuff to the speed test. My site has gone DOWN by 4 points since I last tested it due to failing some new tests.
Really great service by Google in general. I've managed to improve page loading times by 25%, cut number of connections in half (I merged all images into one unified file and then use CSS to display the relevant sub-sections), and reduce the total size of my page by over 10%.
Thank you. At first, I didn't see anything of interest and briefly wondered why I was at a site that had nothing to do with the HN subject.
It hit me that the submission was to a demonstration rather than an article, so I temporarily instructed Noscript to allow all domains used by the page. Sure enough, now the banner appeared.
But that speaks to another reason to not use too many scripts hosted by third-parties. It makes for a very cluttered list of domains for users of Noscript and similar to authorize. I just leave sites that have more than a small number. How many third-party analytics, tracking, tools, social sharing, voting, polling, comments, shopping, deals, and other tools do you really need to embed to make a web site these days?
I love when the list is just domain.foo and domain-static.foo and maybe google-analytics or another mainstream analytics domain.
Don't forget that sometimes you need to allow the site's CDN domain as well.
The problem with Noscript is that it doesn't seem to differentiate between allowing a domain when it's actually a site you're visiting (say, facebook.com) and when it's a domain that a completely different site is trying to load content from. A straight whitelist is too "dumb" for today's web.
google analytics is a definitive no-no. permabanned here and one of the reasons I run noscript and its kind in my browsers.
Not that I mind webmasters running analytics tools, but I'm concerned with google having access to too much personal data/metadata, those privacy issues are bad.
>We noticed that you're using Internet Explorer. Polymath currently does not support this browser because compatibility issues prevent us from delivering an ideal experience. We're working on fixing these issues.
People do realise that some company networks give you no control over which browser you can use right? I can't understand what feature they would need which is missing from IE10. Why not use feature detection? We've moved on from browser detection...
I think that's just code for "we don't want to spend the time and effort to properly test and debug our application on IE at this time, and we really don't want to get barraged with IE support requests either".
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 some browsers miss, use feature detection to flag that.
> 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."
> 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.
I'm glad you said this. I think you're stepping out from a trend/trope, which is to make fun of IE, to recognize the more nuanced reality of the situation.
Over the last few months, I've encountered some surprises. One is that although Firefox seems to be a memory hog, it's very reliable at this point. I didn't set out to like Firefox, but now I trust it as much as the old Netscape.
Another is that while I like the idea of Opera and Chrome, each has failed me now in a number of situations where we're not looking at an isolated glitch, but major performance problems. In particular, complex scripts can lock these guys up like a flash freeze, and Chrome has periodic catastrophic crashes:
This leaves me looking at Firefox and IE as the two real contenders. And while I've never wanted to be an IE fan, as only the unpopular kids on the schoolyard like IE, I think as an application, it's pretty stable. Its only real problem is security and if MS fixes that, I think it's going to be a great competitor for FF now that it's standards-based in the newest version.
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.
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.
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.
Polymath sounds like a cool idea BTW, but probably difficult to monetize. Somebody must pay the tutors for producing/curating the content, but people have gotten so used to educational material being free...
Linking to the file from a popular HN thread will likely only worsen the bandwidth issues for the owner :-). Perhaps link to the Github version instead, which is here: https://github.com/gdsmith/jquery.easing
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.
I had this exact same thing happen last week in one of my wordpress site, I had just inserted that script when developing to try it out and forgot to change it for a local file or a CDN afterwards.
As someone affected by this, I learned my lesson, but I was very happy about how the hotlinking was handled, I was a clear impossible to miss warning, with a clear and easy solution, I though it was only fair.
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.
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.
But if you do that you have to configure your server for it, and your server still has to handle the request. The file is 2KB gzipped; Serving the file or a redirection is basically the same thing.
Polymath might not be the only ones hotlinking... the alternative would be to track everyone who is hotlinking, get their email, and then notify them. Many will likely ignore this email.
So why should it be the responsibility of some guy who's bandwidth is getting stolen to be nice about notifying the guy who's stealing it - why didn't the site owner feel any obligation to send the .js hosting site owner an email asking if it was OK first?
Lots of services out there like browser-update.org tell you to load snippets of js over http from some random location they control. It's pretty unsafe unless you really know who's running the show over there and how secure their system is. Them being compromise could make every user site vulnerable.
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.
Remember: The first rule of Changing hot linked photos club is to never talk about changing hot linked photos.
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.
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.
Yep, I thought that too. The vast majority of website owners have had external developers build their websites. Often those developers are long gone and the website owners left to their own devices (or CMS's). The site owners are now confused and think they have been hacked and don't know where to turn to.
There is actually a business proposition here. You could contact George Smith and ask him for a list of all HTTP referrers. Then contact each site in turn and ask them if they need any help.
Even if they have it sorted already, it might be a good intro into some of these small enterprises.
and route the page to a java drive-by which redirects back afterwards and most of their visitors would've been infected. They are incredibly lucky that the owner of that script was nice enough just to add a simple banner.
It's always blown me away how willing people are to install remote JavaScript on their sites, including top sites that you would expect to be more cautious. A lot of internet retailers include dozens of third party JavaScript files on their pages for analytics, social widgets, retargeting, etc. The way they handle the risk is by using constant monitoring by security auditing firms to check for changes in any of the files (presumably from different locations, browsers, user-agents, etc).
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.
You'd think, but jQuery had to remove code.jquery.com/latest.js because people were linking to it from production sites and complaining when things broke.
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 stealing bandwidth.
When including remotely hosted javascript make sure you have permission, make sure the other party is trustworthy and periodically review the linked script to make sure it does what is advertised (and that's imperfect, it could be you're seeing something else than other visitors).