When I read to the end I found that author proposes a mechanism that is far less convoluted than google's and devoid of this similar problems.
It's better to have less code in your page and more code in google's script - that way they can patch it without me getting involved. As it is now they added the try/catch block (really helps if users run ad-block or some such) but most web admins have not updated their stuff.
Though he accomplished it by altering the requirements. His solution does not work seamlessly with HTTPS sites -- it requires a server-side changes to the code. That's a pretty big issue for a script that's supposed to "just work."
But it doesn't "just work" - it breaks it the face of some firewalls and pops an exception if user has adblock. I actually had users complaining about the latter, this is not a theoretical problem (I fixed it with try/catch myself, but it should not have been a problem to start with and demonstrates brittleness of google analytics).
In other words it's a tradeoff between http/https transparency and odd errors on user's end. Pick your poison. :-)
These "broken" firewalls are becoming increasingly common. Besides that, IE8's private browsing mode automatically blocks Google Analytics and similar tracking services (and ad networks?). Look for that to be increasingly common in web browsers that care more about the end user than they care about advertisers.
By the way, what was "broken"? In this case, everything worked out fairly well for everybody except the website owner and Google, who are likely indifferent to the negative result. Google Analytics doesn't provide any functionality to the user so it doesn't matter to him if the script fails to load or not. The page probably loaded a little faster and his web browser is probably using a little less memory. He probably also got to preserve just a little bit more privacy. The IT team that deployed the firewall got paid to do so and plus they can feel good knowing that their firewall is probably blocking some actual XSS attempts. That reduces IT costs for the company. The manufacturer likely got paid a lot of money for the firewall and the sales guy probably made a nice commission on it.
All 3rd party javascript is broken. It's simply a fact. 15 years into the Web, still nobody has learned to check their external references before using them. Even google gets it wrong pretty much every single time.
If you really need to use somebody else's script on your site, the only thing you can do to protect yourself is to also add global exception handling to the page.
It would be nice if we could expect giant companies that publish Javascript APIs for a living to actually check that their Javascript works in most standard cases, but that's just not the way it works in the real world.
Got any pointers to "gotchas" articles or guides for cross-site JS widgets/includes? If not, want to write one? I've been looking for some blog articles on this recently for our team.
That's how most everybody does it, and it's guaranteed to throw ugly script errors any time a network error causes the .js file download to fail.
It's really easy to work around though. Somewhere in that .js file, simply declare a variable, or better still a method that sniffs for DOM dependencies like "does this div that I need to function actually exist". So you end up with something looking like this instead:
I read all of your blog a while back, maybe a year ago, when there was a long sabbatical. Most of the posts were about how to do the biz thing while all over the place, geographically, as I recall.
I see you're back!
But no more globe trotting posts? I'd love some updates to that part of your life, since I'm having to deal with such a situation myself.
Trotting around Venice, CA at the moment, after I got sorta ejected from the UK for coming and going too frequently. Lived in Basque country for a year, moved (unsuccessfully) to England. But yeah, I guess I haven't been writing too much about travel of late.
11 comments
[ 2.9 ms ] story [ 33.0 ms ] threadIt's better to have less code in your page and more code in google's script - that way they can patch it without me getting involved. As it is now they added the try/catch block (really helps if users run ad-block or some such) but most web admins have not updated their stuff.
In other words it's a tradeoff between http/https transparency and odd errors on user's end. Pick your poison. :-)
By the way, what was "broken"? In this case, everything worked out fairly well for everybody except the website owner and Google, who are likely indifferent to the negative result. Google Analytics doesn't provide any functionality to the user so it doesn't matter to him if the script fails to load or not. The page probably loaded a little faster and his web browser is probably using a little less memory. He probably also got to preserve just a little bit more privacy. The IT team that deployed the firewall got paid to do so and plus they can feel good knowing that their firewall is probably blocking some actual XSS attempts. That reduces IT costs for the company. The manufacturer likely got paid a lot of money for the firewall and the sales guy probably made a nice commission on it.
If you really need to use somebody else's script on your site, the only thing you can do to protect yourself is to also add global exception handling to the page.
It would be nice if we could expect giant companies that publish Javascript APIs for a living to actually check that their Javascript works in most standard cases, but that's just not the way it works in the real world.
It's really easy to work around though. Somewhere in that .js file, simply declare a variable, or better still a method that sniffs for DOM dependencies like "does this div that I need to function actually exist". So you end up with something looking like this instead:
That way, your thing will only run if it has fully loaded and has a reasonable chance of actually working.Here's an old article I wrote with some other ideas:
http://www.expatsoftware.com/articles/2008/05/one-rule-of-dh...
Some of our widgets actually do it the other way:
With the embed script itself doing what it needed to initialize things further.I read all of your blog a while back, maybe a year ago, when there was a long sabbatical. Most of the posts were about how to do the biz thing while all over the place, geographically, as I recall.
I see you're back!
But no more globe trotting posts? I'd love some updates to that part of your life, since I'm having to deal with such a situation myself.
This might help a bit: http://www.blogabond.com/jason