jQuery 1.6.2 syntax error? You may be the victim of SEO.
jQuery By Dave Ward. Updated July 7, 2011
A reader contacted me this weekend to inform me that jQuery 1.6.2 had broken all of my old examples of using jQuery with ASP.NET services. Not good! How could such a simple update have caused this?!
I didn’t really expect that updating from jQuery 1.6.1 to 1.6.2 would break anything, much less break everything.
As it turns out, the problem didn’t have anything to do with jQuery 1.6.2 or my own code. However, while investigating, I ended up falling prey to the same treachery that led to the original bug report.
This is why we can’t have nice things
Google has been raked across the coals this year, with serious questions being raised about their ability to handle the mounting problems of hyper-SEO’d spam sites and content farms. Unfortunately, this weekend’s problem with jQuery 1.6.2 was yet another failure in Google’s ongoing struggle with that dross.
Hopefully, the situation will have improved by the time you’re reading this post, but as I’m writing this, the first organic search result for jQuery 1.6.2 is this one:
If you’re in a hurry to download a copy of the latest jQuery revision, that result looks legitimate enough, but look closely at the domain name. Notice that it’s .it, not .com. This domain is not owned or controlled by the jQuery Project.
Regardless, following the link to this search result takes you to what appears to be an authentic jQuery blog post:
As legitimate as it looks, that site is an entirely unsanctioned ripoff of the official jQuery site. Yet, this impostor has somehow out-ranked the official jQuery blog in Google searches for its own content.
That’s lame, but what’s the harm?
In my hurry, I didn’t notice the .it domain, much less that this seemingly authentic jQuery blog post was an automated copy of the real thing. I right-clicked the link to unminified jQuery 1.6.2, saved it locally, and went about my testing.
After unwittingly downloading this fraud’s copy of jQuery 1.6.2 and testing it in some of my old samples, I did indeed begin seeing JavaScript errors as my reader had reported. Closer inspection revealed that the errors were related to the jQuery script include itself though, not my own code.
So, what was going on? Following the errors back to their source, I found this at the very end of the jQuery script I had downloaded:
|
1 2 3 |
// Expose jQuery to the global object window.jQuery = window.$ = jQuery; })(window);Time to generate: 1.35903 |
Things were looking good until that final Time to generate bit at the very end. That is obviously not valid JavaScript. Likely, it was appended to the file by whatever tool was used to clone the official site.
When browsers hit a hard syntax error like this while parsing a script include, the entire script is ignored and no part of it makes its way into the DOM. So, this tiny error at the very end of thousands of lines of code was all it took to effectively disable the entire library.
Finding a legitimate copy of jQuery
So, where should you be looking for the authentic copies of jQuery 1.6.2?
- You can find unfettered copies of jQuery 1.6.2 on the (real) jQuery blog.
- The latest version is also available on the jQuery site’s download page.
- Finally, I’m a long-time proponent of the performance advantages that Google’s AJAX APIs CDN can bring to your site via its public CDN for jQuery. That CDN is another authoritative source for jQuery 1.6.2 (uncompressed, minified).
Conclusion
Posting criticisms of Google on a site that depends on search for over 60% of its traffic may be asking for trouble, but this is a flagrant failure on Google’s part. Algorithms be damned; they simply cannot allow a random AdSense splog to hijack well-targeted searches for the most popular JavaScript library on the planet.
Imagine how much worse things could have been if this site were actively evil instead of harmlessly inept. Injecting even a tiny bit of malicious JavaScript into such a ubiquitous library could have resulted in a minor catastrophe, as thousands of developers downloaded that subverted version and tested it on their sites.
Update: Thanks to Pierre’s helpful comment below, the issue that allowed the scraper’s site to outrank the original is now apparent: requests to individual post permalinks on blog.jQuery.com return a 500 error when requested with a User-Agent of Googlebot.
As frustrating it is to see a splog outrank the original, there’s no way to fault Googlebot for not indexing something that it couldn’t see. My original conclusion about this being a failure on Google’s part was obviously unwarranted.
Sorry about that.
Epilogue: As of last night, this is what I’m seeing returned for jQuery 1.6.2 searches now.
All’s well that ends well.
Similar posts
Your turn. What do you think?
A blog isn't a blog without comments, but do try to stay on topic. If you have a question unrelated to this post, you're better off posting it on Stack Overflow instead of commenting here. Tweet or email me a link to your question there and I'll try to help if I can.
2 Mentions Elsewhere
- jQuery Syntax Error Blamed on Search Engine Optimization | Bill Hartzer
- Google Panda - End of Organic Search? - SitePoint Forums
We’ve been actively looking into solving this issue over the past few days @jquery and will be taking action soon that will hopefully avoid users ending up on the fake .it site.
As you mentioned, authentic copies of jQuery 1.6.2 and our docs can be found on jQuery.com.
Hm, so you are saying that the ‘.it’ appeared in the organic search result? i.e. not a sponsored link? If so, I feel this is a HUGE issue that Google really need to handle…
Correct.
It’s a good reason why projects post crc hashes of the release to check against. Also its a good reason to down load directly from the Git repo. Least some intermediary is truly malicious and swaps out the zip file your down loading, it is after all http.
Moving to https might well solve the issue, it’s probably to expensive for SEO clone to get it a cert.
No it’s not: the fake site can just regenerate CRCs, the CRC can help against corruption (in the link or of the hosting server by third parties) or MITM targetting the downloaded file, but it does not help against a fully fake site, unless you have some kind of central authority holding all relevant signatures.
No, the SEO clone can just *not serve its content in https*. Users not using https-everywhere-type extensions will be none the wiser.
Then it’s probably too expensive for most OSS projects as well…
If you’re going to a rogue site then the rogue site will have hashes to match the fake content. https wouldn’t do anything, and SSL certificates can be obtained for free.
This should be easy to sabotage/fix for the real jQuery.com guys.
Since the fake .it-site hotlinks directly to the css and custom javascript from jquery.com they can add some code that will warn users that the site is a fake, automatically redirect all traffic to jquery.com with a 301, add canonical headers etc…
That’s a great idea. Even a bit of CSS like:
Would help eliminate that particular scraper until more permanent action could be taken.
I don’t think google is to blame. Certificates exists for one reason.
Exactly what good would a certificate do? They could get a valid, free SSL cert for jquery.it no problem. Visitors to their site on HTTPS would receive no warnings whatsoever.
Certificates prove that the server your browser contacted is the one it _tried_ to contact. They do NOTHING to prove that the site they tried to contact is the DESIRED site.
Certificates also tells YOU, the human, that site mycompanysite.com belongs to “My Company”. And also that mycompanysite.fake belongs to “NOT My company”, “NOT my name”, “NOT my mail” and so on.
No, they don’t. At all. Typical SSL certificates are issued in an automated fashion with zero verification of anything except control of the domain name. Besides relying on users to actually look at the certificate, your blind optimism relies on every legitimate certificate having a validated business’s/person’s name attached. They don’t, and they never will.
SSL certificates do not, in practice, accomplish what you seem to want them to. Please don’t act as if they do, you’ll just confuse others and make the already bad state of web security even worse.
That really depends on what you mean by typical.
In general, yes, you can purchase an SSL certificate from a company like RapidSSL and get some automated certificate kicked out. That’s all well and good, but usually those certificates are not identified as what’s called “EV” or “Extended Validation” certificates, which are (as far as I know) more thoroughly vetted by the issuing companies, and far more expensive for it. The effects to the user are presented rather prominently; see the difference — at least in Firefox — between https://bugzilla.redhat.com and https://www.paypal.com . The former will only show up with a blue identifier, indicating that it is a valid certificate signed by a trusted CA, but the latter will show up green, indicating that it is an Extended Validation certificate and that you are almost certainly dealing with exactly who they say they are. There’s apparently an entire standard behind this that requires some minimal procedure in order to even issue those.
In short, SSL certificates with EV *do* accomplish exactly what the parent suggested they do, provided the user is sufficiently educated (which isn’t a difficult task — basically just say “look for green vs. blue”) AND provided you trust the CA doing the extended validation… and, of course, provided none of these has been compromised, but that’s a wholly independent issue.
Besides those, RapidSSL at least will sometimes hold a certificate and require manual intervention by one of their staff, presumably to ensure there are no potential issues with issuing certain certificates like someone trying to phish people or something. I don’t know about the other CAs and their partners, but it seems like it’d be somewhat hazardous to trust them if they don’t have similar practices. (Which might be the point!)
I am 100% aware of all of this and it is entirely irrelevant to the point.
First, most users do not pay attention to the EV features. They just don’t. Even the “educated” users. EV certificates are a fundamental and predictable failure from user-interaction standpoint. To this day, most users don’t even pay attention to whether the sites they’re on are using HTTPS. Passive, easily-ignored hints do nothing to enhance security.
Second, the EV features are absolutely worthless regardless of user knowledge and attention if the site you _intended_ to visit (like, say, jquery.com) doesn’t have an EV certificate. Again, most do not, and never will. Besides being expensive, the validation requirements are onerous and effectively require an organized “entity” (itself a paperwork headache and nearly impossible for a non-business to accomplish in some jurisdictions). If they become less onerous, the entire point of EV certificates vanish anyway, and we’re right back where we started.
SSL doesn’t do what you want it to. If EV certificates became the only form of certificate trusted by browsers, then it might, but that will never happen, and would cause significant hardship to individuals, small businesses, and open-source projects if it did. It would also make the web as a whole less secure, as 15 years working towards ubiquitous end-to-end encryption and avoiding man-in-the-middle attacks would go down the drain.
By the way, this is how irrelevant EV is: Of Bank of America, Chase, Wells Fargo, and Citibank, only BofA and Citibank bother to use EV certificates. Collectively, those four banks hold more deposits than the next 46 US banks combined, and half of them are ignoring EV certificates.
I really think the blame lies with visitors of websites. Do people really depend on google’s algorithms that much now? I guess it is hard to teach people to be wary of everything on the internet. Yes, Mother Google’s algorithms need work, but the population needs work as well. Blogging about jquery.it just upped their rankings as well. Good work.
You’ll notice that there aren’t any links at all here to the
.itdomain (but several to http://blog.jquery.com). Unless Google has started OCR’ing screenshots and using that in their rankings algorithm, the splog isn’t getting any juice from this post.The point is to look at what you’ve arrived at and not just blindly accept whatever google throws at you. I never said one shouldn’t use search to find what they’re looking for.
Sure, people should look before they leap, but that doesn’t absolve the SEO asshat mucking up the methods and the effectiveness of the search engine for their own profit. Said asshats would gladly preempt viable and valid search results for what people are actually looking for, if they were able (as this one happened to be), just to have more visibility to peddle their spam. It’s terribly subversive and counterproductive for the end user; “hey, at least it makes money” should not be a valid defense here.
Why would you use a Google search for a domain you could just type in in your browser’s Url bar?
Google serves up reams of crap links now for every search, “well targeted” be damned. Hence become less and less useful.
Not everyone uses the Internet exactly the same way, with the same tools or the same workflow that you, me, or the next person does. Search is a very common starting point, even for known sites. Even on this developer-focused site, where every visitor knows the difference between search and directly navigating, I get quite a bit of traffic referred from searches for “encosia”. To each their own.
I don’t think a blame-the-user mentality is very constructive. There are countless developers and designers just getting started with jQuery every day who may use searches like that as their entry point.
It’s pretty common for users to open a search engine and specifically type in the URL they are trying to reach. I think search engines are ubiquitous enough that it’s reasonable to expect them not to mislead us.
Search usually has an advantage over typing in a domain manually: though autocorrect and PageRank, it helps avoid typosquatters and wrong TLDs. (Quick, is it jquery.org or jquery.com? They’re different sites. Smaller projects may have only bought one of the two TLDs, while some low-ranked squatter snags the other. In this case, the project apparently bought both, but used them for different purposes.)
It’s cause for alarm when you can’t trust the top Google result for the name of a highly-ranked project.
I hope someone goes cease-and-desist on the domain owner. For science.
Looks like the Scammer is redirecting to Official .com now. This guy really needs to grow up. What was he thinking? That he would make a “backup” copy of jQuery – Just in-case…REALLY? What an arrogant little child. He needs to take his energy to more product endeavors…
But that would require actually passion and effort. And all he wants to do is rip-off other peoples work for his own selfish gain. I say off to oblivion with his lot.
Google has a “Special Place” for domain like his (thieves). I hope that domain lands so far in the Search Blackhole that he gets 0 benefit from it. What a turd.
Does anyone have anymore information on this guy?
The real issue here is that it’s getting easier to rip off content than to create it and the people who are spending their time creating content don’t have that time to turn around and try to defend themselves from scrapers and given the symbiotic relationship that a search engine maintains with the content that people are looking for, it’s in the best interest of the search engine to figure out how to serve up the content that *creates* rather than merely *clones* value. As ease of cloning increases and cloning proliferates, it becomes increasingly critical for the search engines to not feed the rip-offs lest original/new content be found to be not worth producing.
I’m amazed at how many people jump to conclusions–and say that a bad Google search result or search spam is always the fault of SEO. SEO is not evil, and it is not all search engine spam. Most of the time the SEO that I do has to do with more with cleaning up bad or sloppy code and web design errors.
All search spam is SEO; not all SEO is search spam. That and many other tactics of SEO are pretty evil (or at least *not good*). Also, what sort of SEO do you do that *isn’t* cleaning up bad/sloppy code and web design errors when you’re not doing those?
In any case, it is prudent to blame SEO tactics for cluttering up the search results because SEO tactics (specifically, “splogs” and meaningless hyperlink pool pages) are cluttering up the search results!
Hello all
I work at Google as a Webmaster Trends Analyst to help webmasters with issues like this one.
Looking into this, the first thing I noticed is that the blog.jquery.com seems to be blocking Googlebot from fetching its pages, but the site responds normally for web browsers: it returns an HTTP 500 error headers for requests using a Googlebot user agent. You can use this yourself using a public tool like Web Sniffer to fetch the page spoofed as Googlebot ( http://web-sniffer.net/?url=http://blog.jquery.com/2011/06/3… ) or using Firefox with the User Agent Switcher and Live HTTP Headers addons.
Unfortunately this is a very common problem we see. Most of the time it’s a mis-configured firewall that blocks Googlebot, and sometimes it’s a server-side code issue, perhaps the content management system.
Separately from that, I also notice that the blog.jquery.it URL is redirecting to the blog.jquery.com, suggesting they are fixing it on their end too.
If an jquery.com admins want more help, please post on our forums ( http://www.google.com/support/forum/p/Webmasters?hl=en ).
Cheers,
Pierre
Thanks for the clarification, Pierre. I definitely can’t fault Googlebot for not indexing what it couldn’t see to begin with.
I’ll pass this on to the people who admin the jQuery blog.
While that is stupid, why are you downloading a copy and linking to it that way? Wouldn’t it be better to link from the google api website?
Not only will it be cached on people’s computers making it faster to load, but then you won’t have to use up your own bandwidth.
http://code.google.com/apis/libraries/devguide.html#jquery
Hi Matt,
Just read this.
http://encosia.com/6953-reasons-why-i-still-let-google-host-jquery-for-me/
Any idea on who wrote that? :)
– Naveen
Nice one Dave.
Interesting Read.
There is also the Microsoft CDN for those who don’t want to support the company whose algorithms let to this post to begin with ;)
• http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.2.js
• http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.2.min.js
• http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.2-vsdoc.js
You can also just use NuGet to pull the latest release directly into your solution:
• http://nuget.org/List/Packages/jQuery
• Install-Package jQuery
I’m not a huge fan of the Microsoft CDN, just because so few people use it and you lose a lot the nifty cross-site caching benefit that the Google CDN has with so many more primed caches.
+1 for NuGet though. I just wish there were some way to configure where it drops the scripts, for projects that don’t use ~/Scripts for scripts.
I agree Google’s CDN will be more beneficial, then at the same time if we all just started using the MS CDN it would only make things better :)
I agree, I have become accustom to using ~/public/scripts. Would be nice if NuGet allowed package authors to take arguments… some day soon I am sure.
Top marks to you for raising a really interesting issue and acknowledging the mistake in your post. I don’t think there is a particular problem with scraper sites as long as they don’t rank higher in searches than the originating site. Which is what you have said. Unfortunately this does not always seem to be the case with forum sites. As a coder I am constantly frustrated by scraper forum sites that just republish answers from other sites. Although, over time I’ve got to know which sites are scraper and which aren’t. Also – top marks to google for promoting Stack Overflow results for a similar complaint.
This problem seems to be not completely fixed yet.
It’s still happening with jqueryui.it domain…
Example query: http://www.google.it/#hl=en&sugexp=kjrmc&cp=12&gs_id=1a&xhr=t&q=jquery+ui+sortable&pf=p&sclient=psy-ab&source=hp&pbx=1&oq=jquery+ui+so&aq=0&aqi=g4&aql=f&gs_sm=&gs_upl=&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=b01777e5531065ea&biw=1680&bih=952