I often find that Disconnect can be overly aggressive in the parts of a page that it blocks. When something is amiss when using a webpage whitelisting the site in Disconnect usually fixes the problem.
This also happens with Ghostery and to a lesser extent, Adblock. I switched from Ghostery to Disconnect and have found Disconnect to be a little better at not breaking some sites.
The worst sites I've ran into while using Ghostery/Disconnect are the ones that have a Google Analytics action tracking code in the middle of their Javascript methods (since the addons block GA) so the entire site/app fails to work.
Developers need to start testing their sites with these addons more to make sure silly errors like that aren't done (some optional tracking request failing to complete shouldn't make an entire app fail).
I’m the developer of Disconnect and agree with you, but …
To back up the op and gp, I’m seeing more and more sites that don’t degrade gracefully when their analytics service doesn’t load. I do think devs should check that their site still works when non-essential services fail to load because, even when the user isn’t running Disconnect or a similar app, this scenario is bound to happen — e.g., when there’s a network issue somewhere.
As the developer of Disconnect, if you're removing chunks of functionality the site developers expect to be there, you should be doing it in a way that doesn't break that functionality so absolutely.
You could cloak the cookies so they're pageview specific. Or inject your own functions in place of the ones that are being blocked.
Whether analytics is an essential service or not is a pretty up in the air question.
No. I'm suggesting that if you're writing an extension that changes the way javascript works across the web, you should do it in the least intrusive and breaking way possible.
An extension like this changes a javascript load error from a once-in-a-while event to a happens-all-the-time event.
I can't imagine a situation where you need to know analytics are being consumed in order to give users the data they want (unless the site in question is itself an analytics site).
To allow / cause your site to break when analytics aren't served is, in essence, attempting to enforce an unspoken contract between gathering user info and serving them data.
As far as I'm concerned, a site that doesn't work when analytics aren't served is a site I will literally never use.
Many companies consider controlling essential to do business.
But even if you disagree, you would do end user support a huge favor if you could mention that "It alters the webpages you visit and may break them." next to the download button.
Not a bad idea, but I'm thinking that most folks who are savvy enough to install Disconnect, Ghostery, NoScript, etc. are going to be aware that "stuff might break."
An online article, friends or family send people to Disconnect and they click the install button. After that it protects them by "disconnecting" from "tracking sites". I promise you most people have no idea how it works. Don't believe me, try it: if you see a normal person using Disconnect let them explain to you what it does, how it works and also ask what the Disconnect visualizer says about who is sending data to whom.
I would never, ever, spend time testing something that changes my code. Today it changes it one way, tomorrow another.
That's like trying to replace the screen on your phone and then complaining that it doesn't work and that Samsung/Apple should test their devices with your screen installation skills.
According to addons.mozilla.org, Adblock Plus for Firefox has almost 20 million users. You would "never, ever" perform tests using popular browser extensions that have tens of millions of users? How does your co-founder/employer/client feel about your position?
Indeed. I think I first installed Adblock because b.scorecardresearch.com was consistently the slowest element on a page, and it was somehow quite annoying (don't recall).
(Of course I now have no idea if they ever improved performance)
