make it clearer that crash files may contain private data and make it easier to opt out

Bug #1255165 reported by Stefan Handschuh
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
whoopsie (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

As far as I understand the whoopsie error report procedure, the coredump will be sent to ubuntu servers if daisy.ubuntu.com requests this after the initial report upload.
However, I consider uploading a coredump across the network (although its https) to be a secuity risk. For instance gtk applications contain a lot of private information in their coredump such as last opened filenames. The coredump is used to extract additional information which may help to fix the bug, which is fine but any information should be extracted from the core *locally* (i.e. on the machine, where the crash happened) instead of extracting them on ubuntu servers. The text of the error upload dialog states something like "do you want to help fixing the problem?" which indicates to me that sending the error is something positive. I haven't found any hint that says "do you want to expose private data to canonical?" in this dialog.
Altogether, I see no reason for sending a coredump.

information type: Private Security → Public
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Extracting information from the corefile on the local machine would involve downloading and installing all the corresponding -dbg packages for all packages and libraries associated with the crashed process. Many users do not have the bandwidth nor storage space to install gigabytes of -dbg packages to just run a quick stack trace.

Thus, this compromise of sending the corefile to our retracers, which do have the bandwidth and storage, and automatically strip the coredump from launchpad once the stack trace has been generated.

I personally feel that the safeguards are strong enough that I do choose to submit my own corefiles through this service, but that is because I have good visibility on how the corefiles are handled. I can easily understand how someone else may come to a different conclusion, though, without this visibility.

Thanks

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in whoopsie (Ubuntu):
status: New → Confirmed
Revision history for this message
Gary Houston (ghouston) wrote :

This is a good reason to make sending corefiles a non-default feature. Is it even possible to send a crash report without an attached core dump? I only noticed the feature to disable crash reporting entirely.

Another problem is that core dump files can be enormous, and perhaps a computer with a slow network connection may not be switched on long enough to allow the upload to ever complete. I logged that separately at https://bugs.launchpad.net/whoopsie/+bug/1179364, but it seems that bugs there aren't monitored.

Revision history for this message
Stefan Handschuh (handschuh) wrote :

From my point of view, daisy.ubuntu.com is a black box. And I would like to be warned before sending private data to such a black box instead of being encouraged. The only way (I am aware of) to avoid the exposure of private data is to not create/collect it.

What Gary says is also important. Especially upload bandwidth seems to be "limited resource". Whoopsie could be patched to ignore "CORE" requests from daisy, which should be the default. If one wants to send the core dumps so badly, a solution might be to have an opt-in selection (with an appropriate warning).

summary: - CoreDump should never be sent
+ make it clearer that crash files may contain private data and make it
+ easier to opt out
Revision history for this message
Gary Houston (ghouston) wrote :

I think this is really a request for apport, which shows the error dialog, instead of Whoopsie, which if I understand it correctly just uploads anything dumped in /var/crash to daisy.ubuntu.com. It's quite a neat system, and I may find these crash reports in /var/crash useful now that I know how to unpack them.

I have some other suggestions (I'm assuming that the crash reports are still useful without the core dump included):

* Add a second checkbox in the crash dialog for "include core dump".
* Add a warning beside this checkbox like "The core dump contains the program and the data it was working with. It's size is 4032MB which may take some time to upload."
* If the core dump is larger than a given size (configurable somewhere, maybe a couple of MB by default) then untick the option in the dialog so that it's not included by default. Or maybe untick the box by default in every case.

Revision history for this message
Gary Houston (ghouston) wrote :

Interesting quote from http://www.washingtonpost.com/business/technology/report-nsa-intercepts-computer-deliveries/2013/12/29/dc14c3da-70a2-11e3-bc6b-712d770c3715_story.html?clsrd

One of the most striking reported revelations concerned the NSA’s alleged ability to spy on Microsoft Corp.’s crash reports, familiar to many users of the Windows operating system as the dialogue box which pops up when a game freezes or a Word document dies. The reporting system is intended to help Microsoft engineers improve their products and fix bugs, but Der Spiegel said the NSA was also sifting through the reports to help spies break into machines running Windows. One NSA document cited by the magazine appeared to poke fun at Microsoft’s expense, replacing the software giant’s standard error report message with the words: “This information may be intercepted by a foreign sigint (signals intelligence) system to gather detailed information and better exploit your machine.”

Changed in whoopsie (Ubuntu):
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.