Feature #7796

More user control over Whisperback information

Added by emmapeel 2014-08-19 06:22:12 . Updated 2014-09-16 03:42:05 .

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

0%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
1
Affected tool:
WhisperBack
Deliverable for:

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.


Subtasks


Related issues

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

History

#1 Updated by sajolida 2014-08-19 08:42:57

  • Status changed from New to Confirmed

#2 Updated by intrigeri 2014-08-19 09:38:13

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

#3 Updated by intrigeri 2014-08-19 09:38:25

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

#4 Updated by intrigeri 2014-08-19 09:50:34

> 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 2014-08-19 09:59:07

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

#6 Updated by emmapeel 2014-08-19 11:59:20

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 2014-08-19 12:19:45

> * 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 2014-08-21 10:03:37

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 tails-bugs@boum.org. 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 2014-08-22 08:24:03

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 2014-08-23 22:11:19

> 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 2014-09-16 03:42:05

  • Status changed from Confirmed to Rejected

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