Mozilla published an unexpected security patch this week, bumping Firefox up to version 57.0.3.
(You probably weren’t expecting a browser update between Christmas and New Year, but it’s good to know that security fixes don’t take second place in holiday season.)
Officially numbered Bug 1427111, the good news is that this wasn’t a vulnerability that gave crooks the ability to launch an attack, implant malware, or rootle around for personal data on your hard disk.
It was, however, an ironic bug: if Firefox hit a bug and crashed, it could then hit another bug and upload crash report data even if you’d told it not to.
Technically, this counts as data leakage, but because the data was sent directly from your browser to Mozilla’s servers, rather than to somewhere unknown or unpredicatable, we’ll accept that the risk was modest:
Fix a crash reporting issue that inadvertently sends background tab crash reports to Mozilla without user opt-in
As bugs go, this one doesn’t sound terribly serious – not least because many users have Mozilla’s crash reporting turned on anyway, as a way of helping the development team.
You can check your own settings on the
about:preferences#privacy page, in the section about data collection:
However, as Mozilla notes, there is a small risk of personal data escaping in a crash report, not least because the information uploaded comes from the memory space of a program that has already misbehaved by crashing in the first place:
[W]e need to be mindful that crash dumps contain the contents of the crashing tab. With low frequency they may contain private or identifying information.
That’s why some users (we’re amongst that number) err on the side of caution and deliberately turn off crash reporting, for all that it might benefit the community to have it enabled.
And therein lies a dilemma for Mozilla: the organisation may already have collected data that wasn’t supposed to be uploaded, something that this update can’t reach back in time and fix.
Worse still for Mozilla, it can’t now tell which crash dump data was collected on account of the bug, and which of it was collected with consent.
Mozilla has therefore said it aims to get rid of information it’s not sure it ought to have collected, writing that “[o]ur goal is to have this data deleted in the next ten days”.
We think that’s a silver lining to this bug.
After all, we’ve seen mailing lists ask for ten days to remove us from their address database when we’ve unsubscribed – and that includes mailing lists that didn’t ask for permission to add us in the first place – without even offering to remove any else they might know about us at the same time.
What to do?
- To check that Firefox is up to date, and to trigger an update if it isn’t, just go to the
About Firefoxmenu option.
- To revisit your chosen settings for crash reports, put the special URL
about:preferences#privacyinto the address bar.
4 comments on “Browser data leakage bug – Mozilla to delete info just in case”
I’ve used Firefox for years, sometimes wishing it worked better. But since 57.., I’m a believer again. This fix only proves Mozilla is trying.
I struggled with Firefox over the last few years and moved to Comodo IceDragon (a Firefox fork) to get acceptable performance (mainly memory issues).
Upgrading my Windows 7 machine from 4 to 8GB helped a bit, but …
When that machine’s graphics chip died I declined to use Windows 10 on my new machine and installed Lubuntu 16.04 LTS (which has Firefox 57 bundled).
I am now finding that as Tom says I can be “a believer again” – Firefox just seems to be organisationally and structurally more likely to be good and do good.
Is this performance due to:
– Improvements to the Firefox architecture
– Lubuntu and Linux memory management
– A Laptop that is 6 years younger (significant processor upgrade but same RAM)
Those error/crash reporting functions slow the browser to a relative crawl. FF will load the page 1/2~3/4 of the way, then take a average of 10~20 seconds, just to load the rest.
A 10 second to 20 second pause half way through every page on average? Never seen that myself, with or without crash reporting (which only kicks in if a tab crashes). How sure are you that you have [a] measured the delay accurately and [b] found the right explanation?