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.
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