|Warn users when a browser crash was due to third party code|
|Project Member Reported by firstname.lastname@example.org, Feb 7 2011||Back to list|
A large number of chrome browser crashes (40%) are due to third party code running in the browser process. (Or at least strongly suspected of being the underlying problem). I propose that when the browser has crashed in what looks like third party code, we notify the user of the potential conflict then and there. We have an about:conflicts page which surfaces this information to the user at runtime, which is great. However for crashes which occur very soon after startup user's wont notice this. Moreover when a crash does occur users don't know which of their third party modules were the offenders. If we called attention to the probable third-party software at the time of the crash, would would give users better visibility into why they just crashed, and how they might resolve it. (Since simply waiting for updates to Chrome is not likely to resolve the crash for them. And looking up the crashreport ID and filing a bug is fairly high overhead). We could probably accomplish this without the need for symbols, by walking the crashed thread's callstack and looking for suspicious module names.
Feb 8 2011,
I like your style of thinking. One question: how would you surface this information and when? If you show this at startup, you have the same problem as about:conflicts in that the user won't have a chance to read it. Side note: about:conflicts is integrated with chrome.exe --diagnostics now, so conflicts will show up there (if your browser is crashing at startup).
Feb 16 2011,
I was thinking we could display it in the "Woah! Google Chrome has crashed. Restart now?" dialog. (Putting it inside the "Chrome didn't shutdown properly" infobar would mostly work, however that wouldn't be effective for crashes shortly after startup).
Aug 24 2011,
Aug 25 2011,
... and I was going to open a new bug for this :) I think we should not restrict this to third party code (even though that's probably the simplest thing to implement). I mean, we can have client side code trying to figure out what's wrong, but we also can have server side code helping that process. We could have a system were the server provides feedback to the user based on the crash signature (I'm not dreaming, seriously). I also heard that soon we'll have to update breakpad anyway... We've seen a lot of cases where the crash is the result of malware running on the machine... sometimes quite obviously, but sometimes not so much. We could handle the obvious cases using the third party code logic, but that's not useful for some of the crashes (but the crash signature could provide a pretty good signal, again if we can get feedback from the server). The main difference with malware, is that we really should point the user in the right direction: scan the machine. Currently there are three options for this case: 1. Do nothing: The user is still in trouble, may uninstall or use another browser that doesn't crash, but the problem will still be there. -> Bad result. 2. We work around the problem so we don't crash. This is just papering the problem so that we have better stability numbers, or less noise to work with. The real problem (the user is screwed) is still there, feeling secure with our browser even though the machine was already infected. -> Bad result (and I hate it each time we do this). 3. Tell the user about it. At the end this could lead to a happy user and less crashes and noise for us. Sorry for semi-hijacking this bug.
Aug 26 2011,
Do we have many of these callstack signatures that we believe are purely due to malware but do not have malware DLLs on the stack?
Aug 26 2011,
I have seen multiple cases, but I have not made any attempt to actually quantify their prevalence. Eric mentioned that a large percentage of browser crashes (maybe ~10%) could be attributed to fairly easy to identify malware, so the total number is more likely way higher. As an anecdotal case, the top crash for M14 is due to malware that we can not identify by the list of loaded modules.
Mar 10 2013,
Sep 24 2015,
May 18 2016,
|► Sign in to add a comment|