Google To Host Ajax Libraries

ruphus13 writes "So, hosting and managing a ton of Ajax calls, even when working with mootools, dojo or scriptaculous, can be quite cumbersome, especially as they get updated, along with your code. In addition, several sites now use these libraries, and the end-user has to download the library each time. Google now will provide hosted versions of these libraries, so users can simply reference Google's hosted version. From the article, 'The thing is, what if multiple sites are using Prototype 1.6? Because browsers cache files according to their URL, there is no way for your browser to realize that it is downloading the same file multiple times. And thus, if you visit 30 sites that use Prototype, then your browser will download prototype.js 30 times. Today, Google announced a partial solution to this problem that seems obvious in retrospect: Google is now offering the "Google Ajax Libraries API," which allows sites to download five well-known Ajax libraries (Dojo, Prototype, Scriptaculous, Mootools, and jQuery) from Google. This will only work if many sites decide to use Google's copies of the JavaScript libraries; if only one site does so, then there will be no real speed improvement. There is, of course, something of a privacy violation here, in that Google will now be able to keep track of which users are entering various non-Google Web pages.' Will users adopt this, or is it easy enough to simply host an additional file?"

solution in search of a problem

[nguy (1207026)]

Compared to all the other crappy media that sites tend to have these days, centralizing distribution of a bunch of Javascript libraries makes almost no sense. I doubt it would even appreciably reduce your bandwidth costs.

Re:solution in search of a problem

[causality (777677)]

The "problem" already exists. It's "how can we collect more data about user's browsing habits?" You have to consider that Google is a for-profit business and hosting these files represents a bandwidth cost and a maintainence cost for them. They are unlikely to do this unless they believe that they can turn that into a profit, and the mechanism available to them is advertising revenue.

This is very similar to the purpose of the already-existing google-analytics.com. I block this site in my hosts file (among others) and I take other measures because I feel that if a corporation wants to take my data and profit from it, they first need to negotiate with me. Since Google is not going to do that, I refuse to contribute my data. To the folks who say "well how else are they supposed to make money" I say that I am not responsible for the success of someone else's business model, they are free to deny me access to their search engine if they so choose, and I would also point out that Google is not exactly struggling to turn a profit.

The "something of a privacy violation" mentioned in the summary seems to be the specific purpose.

Re:

[Shakrai (717556)]

This is very similar to the purpose of the already-existing google-analytics.com. I block this site in my hosts file (among others) and I take other measures because I feel that if a corporation wants to take my data and profit from it

Do you actually have to block it in your hosts file in order to effectively deny them information? I have it blacklisted in NoScript -- is that sufficient? I'd always thought it was called via Javascript.

Re:solution in search of a problem

[causality (777677)]

Do you actually have to block it in your hosts file in order to effectively deny them information? I have it blacklisted in NoScript -- is that sufficient? I'd always thought it was called via Javascript.

The file is indeed Javascript and it's called "urchin.js" (nice name eh?). Personally, I use the hosts file because I don't care to even have my IP address showing up in their access logs. This isn't necessarily because I think that would be a bad thing, but it's because I don't see what benefit there would be for me and, as others have mentioned, the additional DNS query and traffic that would take place could only slow down the rendering of a given Web page.

I also use NoScript, AdBlock, RefControl and others. RefControl is nice because the HTTP Referrer is another way that sites can track your browsing; before Google Analytics it was common for many pages to include a one-pixel graphic from a common third-party host for this reason. Just bear in mind that some sites (especially some shopping-cart systems) legitimately use the referrer so you may need to add those sites to RefControl's exception list in order to shop there, as the default is to populate the referrer with the site's own homepage no matter what the actual referrer would have been.

Re:solution in search of a problem

[Tumbarumba (74816)]

The file is indeed Javascript and it's called "urchin.js" (nice name eh?).

"urchin.js" is the old name for the script. Google encourages webmasters to upgrade to the new ga.js, which has pretty much the same functionality, but some other enhancements. Both those scripts feed data into the same reports. If you're interested, you can see what the scripts is doing by looking at http://www.google-analytics.com/ga.js [google-analytics.com]. It's pretty compact JavaScript, and I haven't gone through it to work out what it's doing. Personally, I use it on the website for my wife's children's shoe shop [lillifoot.co.uk]. From my point of view, the reports I get out of Google Analytics are excellent, and really help me optimise the website for keywords and navigation. I will admit though, that it is a little creepy about Google capturing the surfing habits of people in that way.

Re:

[Firehed (942385)]

Well that's just the dilemma. I use Google Analytics on all my sites, and sort of use the information to see what keywords are effective and most common. I don't then turn around and use that information to focus my content on those areas like any smart person would, but I don't really care if someone stumbles across my blog either (much more interesting are HeatMaps, not that I use that information in a meaningful way either).

However, it's not just Google that's grabbing that kind of information. Anyone

Re:solution in search of a problem

[alta (1263)]

I don't see what benefit there would be for me

There are benefits, they just may not be as direct as you like, or appreciated.

We use analiytics. We use it almost exclusively to improve the experience of our customers. We don't care how many people come to our site. We care how many buy... and we have internal reports for that. What we do care about is:
How many people are not using IE. (We found it was worth making sure all pages worked on most all.

How many people are at 1280*1024 or over.
We dropped the notion that we needed to program for 800*600, thereby letting people use more of those big ass screens they buy.

Where are most of the people located?
We now have an east coast and west coast server.

What pages are most viewed?
We made them easier to get to.

Who doesn't have flash?
It was 2.08%, but I'm still not going to let them put flash on my site.

Re:solution in search of a problem

[Daengbo (523424)]

You have to consider that Google is a for-profit business and hosting these files represents a bandwidth cost and a maintainence cost for them.

The bandwidth cost should be small since Google uses these libraries already and the whole idea is to improve browser caching. The maintenance cost of hosting static content shouldn't be that high, either. I mean, really.

Since the labor, hardware, and bandwidth costs all seem to be low, Google wouldn't be under pressure to make the investment pay. Google hosts lots of things that don't benefit them directly and from which they gain no real advantage except image.. Despite being a data-mining machine, Google does a lot of truly altruistic stuff.

Re:solution in search of a problem

[causality (777677)]

Since the labor, hardware, and bandwidth costs all seem to be low, Google wouldn't be under pressure to make the investment pay. Google hosts lots of things that don't benefit them directly and from which they gain no real advantage except image.. Despite being a data-mining machine, Google does a lot of truly altruistic stuff.

Low cost != no cost. While you definitely have a point about their corporate image, I can't help but say that recognizing a company as a data-mining machine as you have accurately done, and then assuming (and that's what this is, an assumption) an altruistic motive when they take an action that has a strong data-mining component, is, well, a bit naive. I'm not saying that altruism could not be the case and that profit must be the sole explanation (that would also be an assumption); what I am saying is that given the lack of hard evidence, one of those is a lot more likely.

Re:

[joelwyland (984685)]

No, seriously: as far as I can tell, nothing Google does is unrelated to data mining. What am I missing?

How about Sketch Up [google.com]? It's a 3d modeling application they offer for free. You don't have to interact with Google at all to use it (apart from the actual download).

Re:solution in search of a problem

[socsoc (1116769)]

Google Analytics is invaluable for small business. AWStats and others cannot compete on ease of use and accuracy. By blocking the domain in your hosts file, you aren't sticking it to Google, you are hurting the Web sites that you visit. I'm employed by a small newspaper and we use Google Analytics in order to see where our readers are going and how we can improve the experience for you. Google already has this information through AdSense, or do you have that blocked too? Again you're hurting small business.

You may refuse to give them your data, but if I had the ability, Apache would refuse to give you my data until you eased off on the attitude.

Re:

[Kickersny.com (913902)]

You may refuse to give them your data, but if I had the ability, Apache would refuse to give you my data until you eased off on the attitude.

Brilliant! He pokes you with a thumbtack and you retaliate by shooting yourself in the foot!

Re:solution in search of a problem

[telbij (465356)]

Is it really necessary to be so dramatic?

When you visit a website, the site owner is well within their rights to record that visit. To assert otherwise is an extremist view that needs popular and legislative buy-in before it can in any way be validated. The negotiation is between Google and website owners.

If you want to think of your HTTP requests as your data, then you'd probably best get off the Internet entirely. No one is every going to pay you for it.

Also:

To the folks who say "well how else are they supposed to make money"

Red herring. No one says that. No one even thinks about that. Frankly there are far more important privacy concerns out there than the collection of HTTP data.

Re:

[robo_mojo (997193)]

When you visit a website, the site owner is well within their rights to record that visit.

Yup. I have no way to stop them, afterall.

The negotiation is between Google and website owners.

Nope. If the website owner wanted to transmit information to Google, he can do so by having his server contact Google, or by dumping his logs to Google.

Instead, if the website owner sends code to my browser to give information to Google, I am within my rights to refuse to do so.

Alternatively, the website owner in qu

Re:solution in search of a problem

[dalmaer (725759)]

I understand that people like to jump onto privacy, but there are a couple of things to think about here: - We have a privacy policy that you can check out - There isn't much information we can actually get here because: a) The goal is to have JavaScript files cached regularly, so as you go to other sites the browser will read the library from the cache and never have to hit Google! b) If we can get browsers to work with the system they can likewise do more optimistic caching which again means not having to go to Google c) The referrer data is just from the page itself that loaded the JavaScript. If you think about it, if you included prototype.js anyway then we could get that information via the spider... but it isn't of interest. We are a for profit company, but we also want to make the Web a better faster place, as that helps our business right there. The more people on the Web, the more people doing searches, and thus the better we can monetize. Hopefully as we continue to roll out services, we will continue to prove ourselves and keep the trust levels high with you, the developers. Cheers, Dion Google Developer Programs Ajaxian.com

How valuable is one data point per year?

[JavaRob (28971)]

but now you also have the traffic pattern data for any of those sites that didn't use google analytics already, that's definitely valuable.

No, they don't. Look again at how caching works. The first time a given browser hits a site that uses Prototype, for example, it'll pull the JS from Google (so Google sees that single site). The browser then hits 20 other sites that also use Prototype... and Google has no clue, because the JS is already cached.

In fact, the cache headers specify that the JS libs don't expire for A YEAR, so Google will only see the first site you visit with X library Y version in an entire year.

Is this information really that valuable?

Mind you, this assumes you're hard-coding the google-hosted URLs to the JS libs, instead of using http://www.google.com/jsapi [google.com] -- but that's a perfectly valid and supported approach.

If you use their tools to wildcard the library version, etc. etc. then they get a ping each time that JSAPI script is loaded (again, no huge amount of info for them, but still you can decide whether you want the extra functionality or not).

Re:solution in search of a problem

[maxume (22995)]

In theory, cache hits wouldn't give Google an information at all. So when the api works the way it is supposed to, it doesn't reveal anything.

Someone could even put up a site called googlenoise.com or whatever, with the sole purpose of loading the useful versions of the library into the cache from the same place.

Well doh

[Roadmaster (96317)]

Will users adopt this, or is it easy enough to simply host an additional file?

Well duh, it's dead easy for me to just host another file, so easy in fact that web frameworks usually do it for you by default, but that's missing the point: the point is that for the end-user it would be better, faster and more efficient if I went to the trouble of using google's hosted version, instead of using my local copy. That, indeed, would be more work for me, but it benefits the end user.

Only a partial solution

[CastrTroy (595695)]

This is only a partial solution. The real solution is for sites using AJAX to get away from this habit of requiring hundreds of kilobytes of scrip just to visit the home page. Couldn't you design a modular AJAX system that would bring in functions as they are needed? That way, someone visiting just a couple pages wouldn't have to download the entire library. Have each function in it's own file, and then when an AJAX call is done, make it smart enough to figure out which functions need to be downloaded to run the resulting Javascript. The problem with Google hosting everything, is that everybody has to use the versions that Google has posted, and that you can't do any custom modifications to the components. I think that what Google is doing would help. But the solution is far from optimal.

Re:Only a partial solution

[Bobb Sledd (307434)]

Yikes...

Maybe it is possible to get TOO modular. Several problems with that:

1. With many little files comes many little requests. If the web server is not properly set up, then the overhead these individual requests causes really slows the transmission of the page. Usually, it's faster to have everything in one big file than to have the same number of kilobytes in many smaller files.

2. From a development point of view, I use several JS bits that require this or that library. I don't know why or what functions it needs. And I really don't care; I have my own stuff I want to worry about. I don't want to go digging through someone else's code (that already works) to figure out what functions they don't need.

3. If I do custom work where file size is a major factor or if I only use one function from the library, I guess then I'll just modify as I see fit and host on my own site.

I think what Google is doing is great, but I can't really use it for my sites (they're all secure). So unless I want that little warning message to come up, I won't be using it.

Re:

[Bobb Sledd (307434)]

Yes, you've hit the nail on the head.

But more specifically, my sites are military and all the content must come from trusted military web servers (better if it's the same one for all the content).

Beware the overhead.

[ClayJar (126217)]

Couldn't you design a modular AJAX system that would bring in functions as they are needed? That way, someone visiting just a couple pages wouldn't have to download the entire library. Have each function in it's own file, and then when an AJAX call is done, make it smart enough to figure out which functions need to be downloaded to run the resulting Javascript.

Actually, the trend is in the opposite direction. By including everything in one file, you can greatly reduce the number of HTTP transactions. Eliminating the significant overhead there can improve "speed" tremendously.

Additionally, if you're using compression, it is likely that one large file will compress more effectively than a collection of smaller files. (You *are* using compression, aren't you?)

Re:

[lemnar (642664)]

AJAX systems are modular - at least some of them are somewhat. Scriptaculous, for example, can be loaded with with only certain functions.

"With Google hosting everything," you get to use exactly the version you want - google.load('jquery', '1.2.3') or google.load('jquery', '1.2'), which will get you the highest version '1'.2 available - currently 1.2.6. Furthermore, you can still load your own custom code or modifications after the fact.

For those concerned about privacy: yes they keep stats - they e

nothing new here

[Yurka (468420)]

The DTD files for the basic XML schemas had been hosted centrally at Netscape and w3.org since forever. No one cares or, indeed, notices (until they go down [slashdot.org], that is).

Yabbut

[FlyByPC (841016)]

Yeah, but what if Google decides that nobody is using these -- or they can't legally host them for whatever reason -- or they just decide that they don't want to do this anymore?

I like Google too -- and this is nice of them -- but I like the idea of a website being as self-sufficient as possible (not relying on other servers, which introduce extra single-points-of-failure into the process.)

At the risk of sounding like an old curmudgeon, whatever happened to good ol' HTML?

dependence on Google is but one problem

[SuperBanana (662181)]

Yeah, but what if Google decides that nobody is using these -- or they can't legally host them for whatever reason -- or they just decide that they don't want to do this anymore?

Think broader. What happens when:

• Google decides to wrap more than just the promised functionality into it? For example, maybe "display a button" turns into "display a button and report usage stats"?
• Google gets hacked and malicious Javascript is included?

But, yes- you're right. This is a scary new dependency. For a company full of PhD geniuses supposedly Doing No Evil, nobody at Google seems to understand how dangerous they are to the health of the web. In fact, I'd suggest they do, and they don't care- because they seem hell-bent on making everything on the web touch/use/rely upon Google in some way. This is no exception.

A lot of folks don't even realize how Google is slowly weaning open-source projects into relying on them, too (with Google Summer of Code.)

Re:

[richardtallent (309050)]

Oh no! If Google decides they don't want to spend the $10/year this will cost them anymore, I might have to change a header and footer script! Or *gasp* use a search-and-replace to fix the URLs!

I'm *so* scared.

Google is supporting web apps and offering to host the nasty boring bits that need strong caching. How very evil of them.

And if Google is hacked, we're ALL screwed a hundred different ways. The average web developer *using* these libraries is more likely to have a vulnerable server than Google.

Re:dependence on Google is but one problem

[mckinnsb (984522)]

Being a Javascript programmer myself, I was wondering which post to reply to. I guess this one suits. There are a lot of issues I'd like to tackle, here.

Yeah, but what if Google decides that nobody is using these -- or they can't legally host them for whatever reason -- or they just decide that they don't want to do this anymore?

Then you go back to including a script tag in your header of your HTML document. All of these frameworks are free. They will likely remain free even though some are sponsored (mooTools). The speed improvement exists, but is moderate-to-minimal, since a packed full-inclusion library of mooTools runs you about 32kb. That's 32kb the user wont need to download again and again, but its just 32kb.

Think broader. What happens when: * Google decides to wrap more than just the promised functionality into it? For example, maybe "display a button" turns into "display a button and report usage stats"?

Even if the code is compressed and obfuscated, this "wrapped functionality" would become *glaringly* obvious to any javascript programmer using Firebug. The news would most likely spread like wildfire. Especially on /. The only thing they could track without really being monitored are which IP addresses are requesting the mooTools.js (for example) file. They could measure its popularity, but not *necessarily* what sites they are visiting. Granted- I haven't looked at the API yet, but if its just a .js file hosted on a Google server, there isn't really too much they can monitor that they don't already. Analytics provides them with *tons* more information. To be honest, this just seems like a professional courtesy.

There is a key point here I hope was visible - JavaScript is totally Load on Delivery, Executed Client Side. They can't really sneak much past you , and any efforts to do so would still remain visible in some way (you would see NET traffic).

* Google gets hacked and malicious Javascript is included?

Interesting, but I haven't seen Google hacked yet - not saying it can't happen, but I've not seen it. There is more of a chance of someone intercepting the expected .js file and then passing a different one- however, keep in mind that if you are doing *anything* that requires any level of security what so ever in JS, well, you have other, deeper fundamental problems.

But, yes- you're right. This is a scary new dependency. For a company full of PhD geniuses supposedly Doing No Evil, nobody at Google seems to understand how dangerous they are to the health of the web. In fact, I'd suggest they do, and they don't care- because they seem hell-bent on making everything on the web touch/use/rely upon Google in some way. This is no exception. A lot of folks don't even realize how Google is slowly weaning open-source projects into relying on them, too (with Google Summer of Code.)

It is a dependency, but its not that scary. Open source projects have always been, for better or worse, more or less reliant on outside momentum to keep them going. Joomla has conferences (that you have to pay to see), MySQL is powered by Sun, Ubuntu has pay-for-support. The fact that Google is willing to pay for kids to work on open source projects of their choosing (and granted, Google's selection), is not necessarily a form of control above and beyond the influence of capital. If I had millions of dollars, I would probably donate to open source projects myself - and they may be ones of my choosing - but I probably couldn't consider myself controlling them as much as helping them grow.

This is really nothing more than a professional courtesy offered by Google. They are right - its dumb for everyone to download the same files over and over again.

Furthermore, someone made a post earlier talking about JS programmers needing to learn how to use "modularity". We

Re:

[caerwyn (38056)]

I'll take the benefits of Google supporting open source over "GSoC is evil" paranoia.

If Google suddenly decides to stop hosting these, or touches them in some fashion, it's going to get discovered and fixed in well under 24 hours. Google hosting a file like this means that there are going to be a *lot* of eyes on the file.

Google is, as it currently stands, far from "dangerous to the health of the web". Outside of using their webmail fairly heavily, I could avoid using google quite easily- as could any other

I won't adopt

[corporal_clegg (547755)]

As a developer, privacy of my users is of paramount importance. I have grown increasingly concerned with Google's apparently incessant need to pry into my searches and my browsing habits. Where once I was a major Google supporter, I have trimmed my use of their service back from email and toolbars to simple searches and now even won't use their service at all if I am searching for anything that may be misconstrued at some point by guys in dark suits with plastic ID badges. The last thing I am going to do as a developer is force my users into a situation where they can feed the Google Logging Engine.

Speaking as a JQuery user...

[MikeRT (947531)]

If I were worried about bandwidth, why wouldn't I just use one of the packed down files? They're as small, if not smaller, than most of the images that will appear on a web page.

Re:

[thrillseeker (518224)]

Because the hundred other pages the visitor went to that session is also demanding their own copy of the library be downloaded. It's not your bandwidth this saves (only trivially it is) - it's the end user's download, and parse, of the same code for each of the dozen sites he visits that use the same library. The libraries Google has initially chosen are extremely popular - i.e. there are good odds that you have a dozen copies in your browser cache right now - each download of which made your browsing exp

You mean like YUI does?

[Gopal.V (532678)]

I didn't see no slashdot article when yahoo put up hosted YUI packages [yahoo.com] served off their CDN.

I guess it's because google is hosting non-google libraries?

Yahoo does this already...

[samuel4242 (630369)]

With their own YUI libraries. See here [yahoo.com] Anyone have any experience with this? I'm a bit wary of trusting Yahoo, although I guess it's easy enough to swap it out.

Host it yourself, add meta-tag

[by Anonymous Coward]

A far better solution would be to add a meta-tag to a call, which the browser could check to see if it has it. For security reasons you need to define it always to use it, so if you don't define it, there will never be a mixup.

Eg:

script type="javascript" src="prototype.js" origin="http://www.prototype.com/version/1.6/" md5="..............."

When another user want to use the same lib, he can the use the origin, and the browser will not download it from the new site. It's crucial to use the md5 (or other method), which the browser must calculate the first time it download it. Or else it would be easy to create a bogus file and get it run on another site.

Of course this approach is only as secure as the hash.

Umm, no

[holophrastic (221104)]

First, I block all google-related content, period. This type of thing would render many sites non-operational.

Second, I've always had this complaint with the whole external javascript files. When you're already downloading a 50K html page, another 10K of javascript code in the same file inline downloads at full-speed. The external file requires yet another hit to the server, and everything involved therein. It almost never makes any sense. Even as a locally cached file, on a broadband connection, downloading the extra 10K is typically faster than opening and reading the locally cached file!

But still, hosting a part of your corporate web-site with google simply breaches most of your confidentiality and non-disclosure agreements that you have with your clients and suppliers. It's that simple. Find the line that reads "shall not in any way disclose Confidential Information to any third party at any time, including consultants and contractors, copy and/or merge the Confidential Information/business relationship with any other technology, software or materials, except contractors with a specific need to know . . ."

Simply put, if your Confidential client conversations go over gmail, you're in breach. If google tracks/monitors/sells/organizes/eases your business with your clients or suppliers, you're in breach -- i.e. it's illegal, and your own clients/suppliers can easily sue you for giving google their trade secrets.

Obviously it's easier to out-source everything and do nothing. But there's a reason that google and other such companies offer these services for free -- it's free as in beer, at the definite cost of every other free; and it's often illegal for businesses.

Re:

[Bogtha (906264)]

Second, I've always had this complaint with the whole external javascript files. When you're already downloading a 50K html page, another 10K of javascript code in the same file inline downloads at full-speed. The external file requires yet another hit to the server, and everything involved therein. It almost never makes any sense.

It almost always makes sense. The external file only requires another hit to the server the first time you see it. From that point on, every page hit is smaller in size b

Re:Umm, no

[Just Some Guy (3352)]

Some of us are still stuck on, gasp, dial-up. And loading an external JavaScript file is STILL far slower than inlining it.

Your grasp of the web sucks. Here's what happens on the second page you load on that site:

1. Send request for the page.
2. Read the page, sees it needs a JavaScript file.
3. See that the JavaScript file was already cached locally.
4. You're finished loading the page, so let people interact with it.

I use maybe 20KB of JavaScript in parts of my site. Why tack an extra 20KB onto each and every pageload, meaning that each takes about another 4 seconds for someone on dialup? To satisfy the screwed-up sense of purity for some premature optimization fan who doesn't really understand the issues involved? No thanks. My site is optimized for real conditions.

Re:Umm, no

[Just Some Guy (3352)]

Step 3 is always "send a new request".

Nope. You're flat-out, demonstrably wrong. Try watching an Apache log sometime. You see a visitor load a page, all its JavaScript, and all of its images. Then you see them load another page, and this time they only fetch the new HTML. There are no other GETs or HEADs - just the HTML.

Inlining script isn't hard, either:

Of course not. The issue is whether it's a good idea (it's not), not whether it's easy (it is).

Re:

[Just Some Guy (3352)]

However, I do have this piece of software called a "web browser" and another called a "packet sniffer".

You have another one called "spyware", or perhaps "rootkit". Your experiment, conducted here on Ubuntu 8.04 with Wireshark 1.0.0, Firefox 3.0b5, and Konqueror 3.5.9, shows exactly the results I described and nothing resembling the results you invented to "prove" your point.

Oh, hey, look, it DOES make a request for external JavaScript files EVERY SINGLE PAGE LOAD, just like I said it does! Sure, it gets a 304 response, but you've still got extra overhead and latency for NOTHING.

304s would show up in my Apache logs, but they don't. Of course not! My browsers aren't making them.

And as someone else pointed out, it's faster to just pull it from the page than to load it from the cache in the first place.

As they incorrectly pointed out. Let's add some more facts to the discussion.

First, this (almost never incurred) overhead is

Cross-Site Scripting by Definition

[Rich (9681)]

Well, one effect of this would be to allow google to execute scripts in the security context of any site using their copy of the code. The same issue occurs for urchin.js etc. If your site needs to comply with regulations like PCI DSS or similar then you shouldn't be doing this as it means google has access to your cookies, can change your content etc. etc.

For many common sites that aren't processing sensitive information however, sharing this code is probably a very good idea. Even better would be if google provided a signed version of the code so that you could see if it has been changed.

Re:

[richardtallent (309050)]

These are static releases of library code written by others.

Google would only be able to execute Javascript on your user's page if they modified the source code of the library you were loading from them. Which would be a BIG no-no.

(Google does have a "loader" function available, but also just allows you to include the libraries via a traditional script tag to a static URL.)

Otherwise, cookies are NOT cross-domain and wouldn't be passed with the HTTP request, unless you were silly enough to CNAME your "js.mys

Re:Cross-Site Scripting by Definition

[richardtallent (309050)]

Do you *honestly* think that Google is going to modify the code for Prototype and slap some AdSense/Analytics goodies in there?

The library developers would have their hide if they attempted such a thing!

And I'm NOT wrong about cookies. Your site's cookies are not sent in the HTTP request, they would only be accessible via JavaScript--and again, without Google modifying the source code of these libraries to be malicious, they wouldn't be privy to those cookies.

Not that cookies store anything useful these days... almost everyone with serious server-side code uses server-side persisted sessions, so the only cookie is the session ID.

Dependency hell?

[jmason (16123)]

One site covering this [ajaxian.com] noted plans to 'stay up to date with the most recent bug fixes' of the hosted libraries -- this sounds like blindly upgrading the hosted libraries to new versions, which is a very bad idea.

As a commenter there noted, it's a much better idea to use version-specific URIs, allowing users to choose the versions they wish to use -- otherwise version mismatches will occur between user apps and the Google-hosted libs, creating bugs and the classic 'dependency hell' that would be familiar to anyone who remembers the days of 'DLL hell'.

Re:

[Spaceman40 (565797)]

Read, and be enlightened:

The versioning system allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. -- google.load() versioning [google.com]

Re:

[AKAImBatman (238306)]

how about removing 70% of the code which just encodes/decodes from XML

Done [json.org]. What's next on your list?

(For those of you unfamiliar with JSON, it's basically a textual representation of JavaScript. e.g.

{
name: "Jenny",
phone: "867-5309"
}

If you trust the server, you can read that with a simple "var obj = eval('('+json+')');". If you don't trust the server, it's still easy to parse with very little code.)

Re:Couldn't be...

[Jellybob (597204)]

Also, those hosted js files would be prime targets for people who want to spread their malware, so I sure hope they're safe...

Yes, you've gotta be careful with those incompetant sysadmins that Google are hiring.

After all, they're constantly getting the servers hacked.

Re:

[by Anonymous Coward]

Single-point-of-failure, DNS-cache-poisoning, host-file-redirects, etc. etc.

You are not thinking this through!

Re:

[jason.sweet (1272826)]

The Google Funding Bill is passed. The system goes on-line August 4th, 2009. Human decisions are removed from strategic search. Google begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug. Google fights back.

Re:

[richardtallent (309050)]

If someone could hack into the ISP's DNS server, it wouldn't matter where the fake code is being requested from.

And, frankly, they could do a lot more dangerous (and easy pay-off) things than just redirect requests for a Javascript library--such as redirecting ebay, paypal, etc. to a phishing site.