libreport's handling of 'sensitive' information in reports is a good idea, but the current implementation is kinda useless in practice.
There's a couple of major problems:
i) It has a fairly generous definition of 'possibly sensitive'
ii) It doesn't distinguish between different types of potentially-sensitive information at all
So in practice, almost every single report you ever submit has the 'possibly contains sensitive data!' stuff come up, which trains you in short order to ignore it, which means when you hit a report which *really does* have your password in plain text, you've been trained to click straight through and you go ahead and post it on Bugzilla. This has actually happened to real people, more than once.
Specific details on i): for instance, every single crash I've submitted in the last few months has had my username in the 'environ' data, and this is flagged as sensitive. libsecret.so is very frequently loaded, and the string 'secret' is flagged.
Either we need to get more strict about the flagging, and maybe 'whitelist' things that are _always_ there or just drop the username from the data (is it really any use to anyone?), or implement some kind of concept of 'sensitivity levels', or probably both. I can see it being a much better system if we don't submit your username in just about every report, and something that looks like a password sets off much more serious alarms than something that looks like a username.
this may be gnome-abrt not libreport; please re-assign if so. I don't know where the 'sensitive data' stuff is handled.
So I've implemented the whitelist, so far I have this words:
Do you have any other candidates for this list?
As mentioned above, the 'environ' tab of the 'sensitive data' dialog always/almost always highlights the line:
amusingly, the line:
right before it is *not* highlighted. Outright *suppressing* that may be better than whitelisting it, though, I suppose.
Filtering the saved information will require more code changes, so for now I'm going to put it to the whitelist (and hope, that noone considers their username as sensitive information).
well if you're going to take that approach you may as well just take 'username' out of the list of strings that trigger the 'sensitive info' path, rather than listing it in both the blacklist *and* the whitelist :)
Author: Jiri Moskovcak <email@example.com>
Date: Fri Sep 20 14:44:35 2013 +0200
added whitelist for sensitive data - rhbz#1009730 rhbz#896246
Signed-off-by: Jiri Moskovcak <firstname.lastname@example.org>
More lines to filter out:
*** Bug 896246 has been marked as a duplicate of this bug. ***
The other major usability issue is that although possibly sensitive text is highlighted, you usually have to horizontal scroll in order to see it, which is not practical in combination with the required vertical scrolling: you'd have to spend ages doing some sort of checkerboard pattern to inspect all the data and ensure you haven't missed anything highlighted.
Ideally there would be a quick way to jump between highlighted terms, but simply removing horizontal scrolling would help a ton.
"Ideally there would be a quick way to jump between highlighted terms"
There actually is one - I forget the details, but there is a button somewhere in the window which simply jumps from highlighted term to highlighted term. I missed it for a while too, but once I found it it looked pretty obvious.
(In reply to Adam Williamson from comment #11)
> "Ideally there would be a quick way to jump between highlighted terms"
> There actually is one - I forget the details, but there is a button
> somewhere in the window
The hidden jump buttons are located on the right bottom corner of the window right after the search text entry.
Oh that's good. It really ought to be much clearer, though.
'accountsservice' in various forms (it's a GNOME lib) is still a problem in current F20. and yeah, it'd be nice to make the 'jump to next sensitive item' arrows a LOT more obvious somehow.
I've created a pull request  which adds 'accountsservice' to the sensitive white list.
Upstream commit ffcca2e498bfbf761c8398a82c15e2b4dd1a6043 fixes this bug.