Norton Making Firefox Crash

My stepfather recently sent me an email:

Firefox keeps crashing and I keep receiving an apology and having to restore things. I switched off my computer and downloaded a new Firefox file but things are still the same.

I asked him for 10 crash signatures from about:crashes (sidenote: why does the “copy raw data to clipboard” button on about:support not also copy data about the last 10 crashes?) and found that the crash was in a DLL belonging to Norton Confidential. Symantec say they should have a fix by the end of the month. (Incidentally, Socorro is awesome.) Although I don’t know what their update uptake rate is.

There are loads of reports in SUMO about this. Scoobidiver says that this issue alone accounts for 8% of all Firefox 18 crashes. Every time this happens, I wonder how many people, who do not have Mozilla employees in their family to email, simply give up on Firefox because “it keeps crashing”, not knowing that a) it’s not our fault and b) there may be a fix coming in a few weeks?

Should we be even more aggressive in blocking crashy binary addons as soon as we see a crash-stats spike?

[Update: here’s his follow-up:

I have Norton 360 but if I disable it while on Firefox, does this leave me vulnerable? Would I be better using Internet Explorer and waiting for the system to be fixed?

Norton Confidential actually does password encryption (?) and phishing protection (which we already have), but people are scared to disable any of this stuff because the anti-virus companies have made them afraid.

Another comedy point: look at the titles of the top 4 Google hits for “Norton Confidential.]

13 thoughts on “Norton Making Firefox Crash

  1. “Should we be even more aggressive in blocking crashy binary addons as soon as we see a crash-stats spike?”

    Yes! Definitely. This is killing us.
    This is the type of thing that is alienating and eroding the user-base and we’re letting it happen.
    Just the other day I ended up troubleshooting with a guy in the comments section of an article. He was frustrated because he’s been a faithful Firefox user for a long time and has it on all of his computers/laptop and with 18 they all started crashing. He had no idea Norton was the cause. He was ready to give up and switch.
    This seems to be happening so consistently, how could we not have acted on this already?

  2. > Should we be even more aggressive in blocking crashy binary addons as soon as we see a crash-stats spike?

    It’s got to be case-by-case, taking into account the impact that disabling the addon would have (in this case low, if Firefox already does everything natively anyway), the percentage of relevant users (i.e. those with Norton Confidential installed) who are experiencing the crash and how frequently it is crashing for them (data which I don’t have). You could even make it intelligent based on the crashes that happen for a specific user – i.e. when restarting after a crash tell the user that addon x caused the crash and has been disabled (with option to re-enable).

    In general though, yes, publicly disabling crashy addons is a good thing, especially if it makes companies do more testing before releasing an addon.

    > look at the titles of the top 4 Google hits for “Norton Confidential

    In my top 10 results, I see three that are specifically talking about crashes in Chrome, and no mentions of Firefox (without clicking through).

  3. In my top 10 results, I see three that are specifically talking about crashes in Chrome, and no mentions of Firefox (without clicking through).

    I was just noting they all contained the word “crash” – not the sort of publicity you want when someone searches for your product…


  4. I tried to get it blocked with my request in bug 831122 but it seems that the responsible persons want to wait until the crash spike is gone due to users moving to other browsers.

  5. “Should we be even more aggressive in blocking crashy binary addons as soon as we see a crash-stats spike?”

    >> Yes, the same way you are already blocking dangerous plugins like vulnerable versions of Java: case-by-case, blacklist-based.

  6. I wonder if we need to provide more information to users when they do crash. i.e. rather than “I’m so embarrased we just crashed. Want to restore?” We can look at the crash signatures and query scoro for a useful message. “Looks like this crash is caused by Norton Antivirus. Want us to disable it? Or click here to learn more…”

  7. We are just about (next week, I hope) to push out a Socorro feature that will email a user when they crash (assuming they have given us their email address). This will contain a link to the SUMO article on “how to troubleshoot your crash” among other things. You can see the email copy on

    Longer term, we would like the emails to have more tailored information about what caused the crash at least in some cases (“Norton crashed your browser. Here’s how to disable it.”) , but it’s a start.

  8. 1) We have been discussing a block for this, but it would be pretty rude to take them off the picture while we are working with them closely at the same time to get their code fixed, and they have promised to ship updates for this soon. Also, this problem was actually caused by us forgetting to rev the UUID of an important interface when changing it (which we promise add-on devs to not do), so the fault is even on us. Should we punish Norton/Symantec for our misbehavior?
    2) There’s a bug going on about adding recent crashes to about:support, see

  9. 1) Thanks for the input; I agree that if it’s our fault, then we should take the knocks. I can’t wait for that UUID-rev-checking pre-commit hook!

    2) Awesome.

  10. The lack of ownership of all blacklisting bugs is painful to watch. For example right now I’m looking at bug 497423 which was fixed several times over already, but remains open because there is nobody there who would close it.

    I strongly believe that Mozilla needs a procedure in place that identifies *who* is evaluating blacklisting requests and which puts a reasonable limit of how long it should take to make an authoritative decision. Bonus points for a set of guidelines more detailed than “case by case basis”.

    Also, I strongly disagree about delaying the decision based on any promise or expectation of a vendor fix. In all those cases where blacklisting can be limited to affected versions, blocking the affected version (and not blocking future fixed versions) strikes me as exactly the right thing to do.

    Finally, I don’t understand current connection between blacklisting an X and how many people are using X. The fewer people use it the *less* hesitation should be before blacklisting, right??

    A person who fixes friends-of-friends’ computers and who sees just how painful firefox is to whoever can’t manage all their malware firefox addons of all kinds.

  11. Good luck with this. I got in trouble when I complained on my blog about a troublesome third-party add-on from a well known anti-virus vendor.

  12. They promised a fix in October (for the end of the month), and only for Version 2013 if I understand the comments correctly. (They consider patching 2012). Now
    The bug itself has been on file since August.
    I don’t think this qualifies as “working closely with them”.
    Would have correctly updating the interface UUID you mentioned prevented this? Maybe it would have prevented the crashes given enough error checking in their code, but their software not knowing about the new interface details still wouldn’t work correctly.

    Per our very own guidelines, the thing should have been blocklisted already. I think that not doing so it is rather rude to the users!

  13. Why wait for a crash spike? Binary plugins that share memory space and/or run in the same process with your application are an inherently horrific idea. Block them all from embedding themselves in the browser. There’s no valid reason for them to be doing that. Ever. Make them run in their own process in their own memory space in their own window, and suddenly like magic all their problems are no longer the browser’s fault. There’s no downside.

    For one thing, embedding a third-party application into your application’s window severely violates user expectations. Here’s just ONE example of a (paraphrased) conversation that I have 2-3 times a day (with different users each time):
    User: “Why won’t my paycheck stub print? I printed it, and all I got was [the rest of the web page but not the only part I actually wanted].”
    Me: “It looks like what you’ve got there is a plugin.”
    [Sometimes I have to check the page source to verify that, but usually not. For those of us who know what to look for, plugins often make themselves obvious.]
    User: “Huh? No, this is my paycheck stub. I just want to print it.”
    Me: “You see this part right here, in this rectangular area?”
    User: “Yeah, that’s my paycheck stub.”
    Me: “That’s actually not part of the web page at all.”
    User: “When I print, it comes out blank.” [By “it” they mean the plugin area.]
    Me: “Right, the web browser can’t print that because it’s not part of the web page.”

    At that point the solution I give them varies depending on the plugin. If it’s a PDF, there’s usually a print feature available from the plugin, which can be accessed by looking in a completely different place from the browser toolbar button or menu item used to print ordinary web pages. If it’s Flash, taking a screenshot is the usual recourse. So complicated. So *gratuitously* complicated. People who don’t do IT for a living usually cannot figure it out on their own.

    If the “plugin” were unable to embed itself in the browser window and forced instead to behave normally like any other program (i.e., open a window of its own, with its own application title), then if a particular one didn’t have a print option on its toolbar or in its menus, users would at least be able to figure out that the problem is that Flash Player (or whatever) doesn’t have a print option. Also, users would be able to *find* the print option on ones that *do* have it (e.g., Acrobat Reader or whatever they’re calling it these days) — with it being embedded in the browser window, very few users can find the plugin’s print option without help.

    Plugin embedding also creates a transfer of problematic issues from the plugin to the host application. If the plugin has bugs that can cause crashes, the browser crashes. If the plugin has bugs that can be exploited for nefarious purposes, the browser is insecure. Basically any mistake the plugin programmers make harms the browser. I can understand why plugin makers would want that, but I don’t understand why browser makers are willing to put up with it. I can almost understand why somebody at Netscape thought it would be an okay idea back in the early nineties when the internet was mostly populated by academics and on the whole not very hostile and the browser crashed six times an hour anyway, but WHY do browsers still support such ill-conceived nonsense two decades later?

    Data that can’t be displayed by the browser itself should be saved to disk and/or handed off to a helper application that runs in a separate process, in its own memory space, in its own window. The user should be able to set a save/open/ask preference on a per-file-type basis. If the user prefers to open rather than save, figuring out which application to launch should be done using the operating system’s standard mechanism in the same way a file manager would do it.

    As for Norton, I have NO idea why anyone thinks that needs to be a browser add-on. If Norton wants to watch for new files being written to disk in order to scan them, fine, but there should be an OS-level API for that. The specific application shouldn’t need to even *know* that it is happening, much less participate. It shouldn’t matter whether the file is retrieved with Firefox, ws_ftp, wget, LWP, or Bob’s Epic File Downloader With Awesome Sauce. AV scanning should work the same way regardless of what application retrieved the file, and said application does not need to be disturbed with invasive buggy in-process meddling.

Leave a Reply

Your email address will not be published. Required fields are marked *