On Thu, 2008-10-23 at 19:50 +0000, Martin Pitt wrote:
> That's of course important supplementary data, but on its own it is
> worthless to describe the problem, yes.
Of course, however along with...
> Stack traces can already contain pretty much anything, passwords, PIN
> numbers, secret project names, etc. passed around as function
> arguments or local variables.
Indeed. But I can visually inspect stack traces. I cannot do that with
the CoreDump. And just as I should have the option to not send the
CoreDump, I should be able to deselect sending any of the stack trace
attachments too. Of course I wouldn't once I have inspected them and
see they are clean. I would suggest that apport refuse to send a report
with too many things disabled.
Another option is to make (some of) the attachments editable. I'd send
a stack trace once I was able to "xxxxxx" out sensitive data. I'd even
suggest that of the CoreDump if it were not impractical 99% of the time.
> And in most cases, we even need more
> than that, the full core dump, to get a fully symbolic stack trace.
Yes, that's a fair point. It would be nice if the apport gui did
everything one needed to make sure fully symbolic stack traces were
sent.
> It is computationally infeasible to weed out stuff which is
> potentially sensitive.
Maybe. Maybe not.
> Right, that's why the user can inspect the report initially,
But they cannot inspect the most revealing aspect which is the CoreDump.
> it
> says "If you were not doing anything private", we don't mark bugs
> as public, and we disable apport in stable releases.
Yeah. I have seen that. The problem is, I think, that the average user
still does not understand the implication. My mom for example could be
looking for a recipe with firefox and it crashes. She wasn't doing
anything "private" although sending the CoreDump potentially will leak
the passwords she has told ff to remember and, as I have seen
personally, will leak cookies which I have seen financial institutions
dropping account information into.
I wonder how many ff bugs have CoreDumps in them which an LP
administrator/bug triage engineer has allowed to be public.
On Thu, 2008-10-23 at 19:50 +0000, Martin Pitt wrote:
> That's of course important supplementary data, but on its own it is
> worthless to describe the problem, yes.
Of course, however along with...
> Stack traces can already contain pretty much anything, passwords, PIN
> numbers, secret project names, etc. passed around as function
> arguments or local variables.
Indeed. But I can visually inspect stack traces. I cannot do that with
the CoreDump. And just as I should have the option to not send the
CoreDump, I should be able to deselect sending any of the stack trace
attachments too. Of course I wouldn't once I have inspected them and
see they are clean. I would suggest that apport refuse to send a report
with too many things disabled.
Another option is to make (some of) the attachments editable. I'd send
a stack trace once I was able to "xxxxxx" out sensitive data. I'd even
suggest that of the CoreDump if it were not impractical 99% of the time.
> And in most cases, we even need more
> than that, the full core dump, to get a fully symbolic stack trace.
Yes, that's a fair point. It would be nice if the apport gui did
everything one needed to make sure fully symbolic stack traces were
sent.
> It is computationally infeasible to weed out stuff which is
> potentially sensitive.
Maybe. Maybe not.
> Right, that's why the user can inspect the report initially,
But they cannot inspect the most revealing aspect which is the CoreDump.
> it
> says "If you were not doing anything private", we don't mark bugs
> as public, and we disable apport in stable releases.
Yeah. I have seen that. The problem is, I think, that the average user
still does not understand the implication. My mom for example could be
looking for a recipe with firefox and it crashes. She wasn't doing
anything "private" although sending the CoreDump potentially will leak
the passwords she has told ff to remember and, as I have seen
personally, will leak cookies which I have seen financial institutions
dropping account information into.
I wonder how many ff bugs have CoreDumps in them which an LP
administrator/bug triage engineer has allowed to be public.