Project

General

Profile

Feature #7796

More user control over Whisperback information

Added by emmapeel almost 5 years ago. Updated almost 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/19/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Yes
Affected tool:
WhisperBack

Description

(reported through whisperback)

A bug report is sent without showing the "Technical details to include" tab.

By default, in that tab, "debugging info" is checked. "Debugging info" contains a lot of information that might allow to personally identify the user's computer (computer brand, model name, devices plugged onto the computer...).

The "Send" button should be activated only after the user has been on the "Technical details to include" tab, so that she is given a choice of sending the "Debugging info" data or not.

That could be implemented either by creating a two-step process or disabling the button until the tab is first clicked.


Related issues

Related to Tails - Bug #6343: List potentially identifying information sent in Whisperback reports In Progress 03/01/2014
Related to Tails - Bug #6769: Some serial numbers are not removed in WhisperBack reports In Progress 03/01/2014

History

#1 Updated by sajolida almost 5 years ago

  • Status changed from New to Confirmed

#2 Updated by intrigeri almost 5 years ago

  • Related to Bug #6343: List potentially identifying information sent in Whisperback reports added

#3 Updated by intrigeri almost 5 years ago

  • Related to Bug #6769: Some serial numbers are not removed in WhisperBack reports added

#4 Updated by intrigeri almost 5 years ago

By default, in that tab, "debugging info" is checked. "Debugging info" contains a lot of information that might allow to personally identify the user's computer (computer brand, model name, devices plugged onto the computer...).

I wouldn't say we're still leaking "a lot of information" there, but oh well :)

The "Send" button should be activated only after the user has been on the "Technical details to include" tab, so that she is given a choice of sending the "Debugging info" data or not.
That could be implemented either by creating a two-step process or disabling the button until the tab is first clicked.

I don't think that can realistically be seen as a solution to the problem this ticket is about. It looks like the good ol' "oh, let's force them to click through something they won't read or understand, in the hope to transfer the responsibility for their decision to the users" self-hand-washing operation, that we've seen too much e.g. in license agreement nag screens:

  • it will make bug reporting more painful for most users who are fine with leaking a bit of info to help us resolve their problem;
  • it will scare people away from sending these tech details, while we really need it to understand and address their problem, and in most cases it's no big deal to send it to us;
  • the tech details content is very long, and most users can't be expected to read it entirely, and even if they did, most of them won't have the technical expertise to make a sensible decision about it.

What might be a good solution is to better convey to users the (meta-)information they need to make a sensible decision in the context of their threat model:

  • what info is part of those tech details;
  • how much identifying it can be;
  • how it is sent to us;
  • who receives it;
  • what we do with that info (BTW, we could make progress on that: I've seen WhisperBack reports partly copied'n'pasted into Redmine as-is; I don't remember if tech details were part of it, but publishing full paragraphs sent to us privately should be a no-no IMO, e.g. wrt. stylography);
  • how leaking this info compares with the kind of trust they're already putting into us, simply by using Tails.

#5 Updated by sajolida almost 5 years ago

Same for me. I think that's a bad idea.

#6 Updated by emmapeel almost 5 years ago

Regarding redmine bug reports:

  • I like to edit the user's paragraphs, to adapt them better to the bug report.
  • Once I left a username because I thought it was of the nickname randomizer in irc.
  • Are Message-Ids ok?

#7 Updated by intrigeri almost 5 years ago

  • I like to edit the user's paragraphs, to adapt them better to the bug report.

Good! Rephrasing entirely would be much better, if you can handle it. And often enough, users phrase things in a way that's good for interacting with front desk, but not so good to interact with developers on Redmine.

  • Once I left a username because I thought it was of the nickname randomizer in irc.

Not sure if that nickname is part of WhisperBack bug reports, so you might want to double-check :)

  • Are Message-Ids ok?

I think it is better to avoid publicly tying clear-text information with identifiers of a private bug report. However, if adding this info to Redmine is useful for you in practice, then possibly it's acceptable. So... is it useful in practice? I mean, how often does front desk look into their mailbox for a specific bug report that's referred to on Redmine?

#8 Updated by sajolida almost 5 years ago

Good reasoning. Often when I add a report number in a ticket it is to
provide the developers a way to find the original logs. But actually,
since we are going in the direction of having only frontdesk people, and
not coders on . This doesn't make much sense.

So yes, let's not publish report numbers without a good reason to do so.

#9 Updated by emmapeel almost 5 years ago

intrigeri wrote:

  • Once I left a username because I thought it was of the nickname randomizer in irc.

Not sure if that nickname is part of WhisperBack bug reports, so you might want to double-check :)

Heh, no! it was a bug reported in irc. The user had a nickname I was also given once while connecting through Tails, so I thought it was ok to have it.

  • Are Message-Ids ok?

I think it is better to avoid publicly tying clear-text information with identifiers of a private bug report. However, if adding this info to Redmine is useful for you in practice, then possibly it's acceptable. So... is it useful in practice? I mean, how often does front desk look into their mailbox for a specific bug report that's referred to on Redmine?

Agreed with sajolida, it was more for others to find out. As we don't have an archive for the bugs I see no point actually.

In any case, I save mails related to bugs reported to redmine, so if anybody needs to contact a user can tell me about it. I am currently adding 'reported through Whisperback' only.

#10 Updated by intrigeri almost 5 years ago

Heh, no! it was a bug reported in irc. The user had a nickname I was also given once
while connecting through Tails, so I thought it was ok to have it.

Aaaah. Assuming it was on a public IRC channel, it's fine to re-publish the same information here.

#11 Updated by sajolida almost 5 years ago

  • Status changed from Confirmed to Rejected

Two people expressed themselves against this proposal, and none in favor. So let's reject this.

Also available in: Atom PDF