Feature #12262
Make WhisperBack logs available to developers to query
0%
Description
I’m finding more and more uses for greping 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.
Subtasks
Related issues
| Related to Tails - Bug #9960: Request tracker for help desk | Confirmed | 2015-07-24 | |
|
Related to Tails - |
Resolved |
History
#1 Updated by intrigeri 2017-02-25 16:45:18
- 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 2017-03-04 20:41:25
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 2017-03-05 09:35:54
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.:
- write down expected benefits (somewhat already done on this ticket)
- brainstorm drawbacks and risks we will rationally face
- 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)
- 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 2017-04-20 12:20:04
- 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 Anonymous 2018-01-18 14:30:36
- related to Bug #9960: Request tracker for help desk added
#6 Updated by Anonymous 2018-01-18 14:37:12
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 Anonymous 2018-01-18 14:47:05
- 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 2018-01-21 12:08:25
- related to
Feature #9803: Call for a meeting to refine requirements for help desk request tracker added
#9 Updated by sajolida 2018-01-21 12:08:52
> 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: Feature #12262.