Hacker News new | comments | ask | show | jobs | submit login

Here's a link to the FAQ with more info: https://support.mozilla.org/en-US/kb/tracking-protection-pbm

And links to lists of what is blocked: https://wiki.mozilla.org/Security/Tracking_protection#Lists

I'm curious to know what the in-the-wild breakage rate for FF's blocking feature is. I use Ghostery myself and I find that maybe 1 in 100 are broken. I feel like that could be 1 in 1000 if blockers implemented a Google Analytics stub -- by far the most commonly required script for things to work.




I've run into the Google Analytics issue multiple times. It may be just because usage is so prevalent, so it's more visible, but it's bad when your website breaks because a third party script doesn't load.

In the situations I've seen, the issue was using GA without first checking it loaded correctly. Defensively coding third party requests, let alone all requests, should be second nature.

It raises two questions for me:

1. Is there some code out there being copied everywhere which assumes GA will always load?

2. How do I make sure this is never an issue in my projects?

I don't think (1) is an actual problem, and I don't know of any options for (2).

Bandwidth throttling doesn't directly help, although it may make it obvious which third-party scripts block the render of the page (which often seems related).

Ideally you would have good test coverage on the loaded page, and then randomly block requests to see what breaks. Mark resources as either hard or soft dependencies, make sure soft dependencies never break the page/functionality of the app, and make sure loss of a hard dependency degrades nicely.

Edit: I should also add, my most memorable run in with this bug was with a very well known application, and they were very quick to fix it once reported. I was surprised none of the internal devs had run into the problem, as I assumed most would run a blocker, but it may have been an early access release...


As a user, I would tend to agree; but as a developer, thinking about "what if the browser decides to kill this one script request but run the rest of the scripts?" is the last thing on my mind. I don't know, maybe I'm a lazy dev[0], but when you consider it's essentially the browser's selective compliance to the standards, how far down that rabbit hole do you want to go?

Now, you could argue that requests can legitimately fail at any time, and it's best to handle it. OK, as a lazy/efficient dev willing to entertain that, I'll design my page to put up a modal alert saying "There was an error loading this page. Click OK to refresh." if anything fails to load. Now my error-handling job is done, but privacy-conscious users will still be mad at me, demanding that I gracefully degrade for every combination of request-blocking (or in GP's case, request-tampering!) they can dream up.

Again, I'm sympathetic as a user, and I've even experienced broken pages due to Ghostery, but as a developer it's hard to blame them.

[0] And AFAIK have no hard dependencies on third-party scripts like GA.


This is why I think the concept of soft and hard dependencies is useful.

As a dev, it's nice that I can track what my users are doing with GA, but I would rather my users be able to use my application. This is definitely a 'soft' dependency because I do not have a hard requirement to use its functionality. If a critical piece of my application (a 'hard' dependency) fails to load then that is a bigger problem.

I don't think we have to degrade gracefully for every possible failure, but failing to render anything is a really bad failure mode. Your lazy/efficient dev is actually just providing a good user experience; if something bad has gone wrong, let the user know so they can refresh etc.

The thing about third-party scripts is that you have no control over them at all. By their nature, you can't even bundle them (that is a workaround for some options though)!

If your users are deploying your web-app behind the firewall, and outbound requests are blocked, if you don't handle these requests failing then the entire app becomes unusable regardless of if they use ad blocking or not.


Yeah, I got a little carried away ranting. It's probably reasonable to make sure your page works if GA doesn't load. There may be other third-party scripts that the developer views as essential but the user doesn't.

I found this searching for "google analytics stub": http://ejohn.org/blog/fixing-google-analytics-for-ghostery/ . Supposedly Ghostery was already stubbing it in 2013. They might be missing some stubs for certain scripts though, because I've had something break 6-8 weeks ago, and it worked when I disabled Ghostery and refreshed.


im running tracking protection since an intern wrote it and ran into an issue a single time, so thats over 2 years of daily browsing for me. ublock origin which i also use atm (and before that other things) rarely break stuff i visit either..

ghostery and friends tend to break stuff more often.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: