Project

General

Profile

Feature #12262

Make WhisperBack logs available to developers to query

Added by anonym about 2 years ago. Updated over 1 year ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/25/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

I'm finding more and more uses for @grep@ing our WhisperBack logs to collect aggregated statistics about our users, mostly related to hardware support, what Tails features are used, and frequency about certain non-fatal errors. The problem is that I don't have it myself, and instead have to ask sajolida or someone from frontdesk to do the query for me.

As a Tails developer I'd find it useful to be able to do such queries myself. At first I thought an encrypted Git repo would be perfect, but then I realized that retaining this sensitive user-submitted data forever is irresponsible. I'm not even sure we have a data retention policy (?). Any way, I'd be happy with data from the past two years.

Regarding implementation, it'd be cool if the tails-bugs@ Schleuder could archive all user emails somewhere (and we'd seed it with old email from frontdesk's inboxes) available to rsync with + a cron job that removes too old emails to enforce the data retention policy. Or something equivalent.

Note: intrigeri suggested to "subscribe to [the tails-bugs] list, filter email to a folder + auto-mark as read, and you'll have that for the future?". I guess I'll do (+ ask for a dump of tails-bugs@ from frontdesk) that if this ticket is rejected, but I'd find a solution that has the data retention angle incorporated better, and that can be reused by other developers. So, yeah, I'll do that if we reject this idea, but I don't think it's a good solution.


Related issues

Related to Tails - Bug #9960: Request tracker for help desk Confirmed 07/24/2015
Related to Tails - Feature #9803: Call for a meeting to refine requirements for help desk request tracker Resolved

History

#1 Updated by intrigeri about 2 years ago

  • Assignee set to anonym
  • QA Check set to Info Needed

Regarding implementation, it'd be cool if the tails-bugs@ Schleuder could archive all user emails somewhere (and we'd seed it with old email from frontdesk's inboxes) available to rsync with + a cron job that removes too old emails to enforce the data retention policy. Or something equivalent.

The way you see it, would these email be archived in cleartext, or encrypted? And if encrypted, to which key(s)?

#2 Updated by sajolida about 2 years ago

Pasting here what I wrote to anonym in private:

I would personally be fine sharing these reports with more people.

Now, I know that it's been a controversial topic amongst help desk and I
bet it would be amongst the project as a whole. But help desk hasn't
lead this discussion beyond the point of saying "OMG! Sensitive data!".
So, by lack of energy to lead this discussion myself, I'm in a policy
limbo here. Since then, this data has proven to be quite helpful in some
cases so I guess that the time is ripe now to have a good discussion
beyond "OMG!".

Still, I'm not sure it would be good for me to send this data elsewhere
without having some kind of a project-wide agreement on this. Maybe, at
least, about where and how long anyone should be able to keep them (and
add a line about this to the security policy).

If we can get help desk or the project as a whole take some policy
decision regarding this by email (likely quite painful) maybe the summit
would be a place for that (but it also sounds like not the most exciting
topic that could be discussed there).

#3 Updated by intrigeri about 2 years ago

FWIW I agree with everything sajolida wrote.

If we can get help desk or the project as a whole take some policy decision regarding this

IMO it's a decision that shall be made by the project, not just help desk. But the outcome of this discussion should help them specify their upcoming request tracker :)

by email (likely quite painful) maybe the summit would be a place for that (but it also sounds like not the most exciting topic that could be discussed there).

In any case, next step is to prepare this discussion, i.e.:

  1. write down expected benefits (somewhat already done on this ticket)
  2. brainstorm drawbacks and risks we will rationally face
  3. brainstorm fears and other possibly irrational concerns, and try to translate them into actionable items (e.g. writing down explicit bits of policy to decrease the amount of unknown that created fear in the first place)
  4. think about a policy and technical implementation that takes all the above into account

I think we can do all this on this ticket, and then propose it to the project over email. If this results in a swift consensus, fine. If minor concerns are raised, we can iterate a bit. If major concerns are raised or too many iterations are needed, postpone to the summit.

#4 Updated by anonym about 2 years ago

  • Assignee deleted (anonym)
  • QA Check deleted (Info Needed)

This was more of a wishlist type of request from me and I am not motivated enough to put in time and energy in preparing some sort of proposal, but I'd happily participate in a discussion during a contributors meeting or the summit.

#5 Updated by u over 1 year ago

  • Related to Bug #9960: Request tracker for help desk added

#6 Updated by u over 1 year ago

I have the feeling this issue might be resolved by the request tracker for helpdesk.

I find it logical that the foundations team has access to this data. Maybe with our new workflow of FT and help desk meeting regulary, this has been addressed? Has it?

#7 Updated by u over 1 year ago

  • Status changed from Confirmed to Rejected

anonym and intrigeri agree that we can reject this ticket, as nobody has stepped up to lead this discussion to an end.

#8 Updated by sajolida over 1 year ago

  • Related to Feature #9803: Call for a meeting to refine requirements for help desk request tracker added

#9 Updated by sajolida over 1 year ago

I have the feeling this issue might be resolved by the request tracker for helpdesk.

Yes, that should be in our work on updated requirements: #12262.

Also available in: Atom PDF