Propose to delete data from a persistence feature when it is deactivated
When you deactivate a persistence feature, the corresponding data is not erased from the persistent volume. This is nothing new, but I’m realizing that this is not made clear to the user and this is a problem:
- People might believe that this data has been deleted when it is not.
- People might have bad surprises as Tails autoconnecting to networks that they had configured in the past but disabled since then.
First we should discuss whether we think that this is a problem, and its gravity. Then we can move on to proposing solutions: wiping disabled features by default, prompting the user to choose whether wiping or not, mentioning this in the documentation only, etc.
#2 Updated by intrigeri 2014-12-16 21:58:36
> * People might have bad surprises as Tails autoconnecting to networks that they had configured in the past but disabled since then.
Just to be clear: this shouldn’t happen for networks that were individually disabled, but only when one has disabled the Network Connections persistence preset entirely, right?
> First we should discuss whether we think that this is a problem, and its gravity.
Looks like a normal priority problem to me.
> Then we can move on to proposing solutions: wiping disabled features by default, prompting the user to choose whether wiping or not, mentioning this in the documentation only, etc.
Wiping by default seems to be out-of-question to me without a prompt. With a prompt, well, maybe that would be a fine place to draw the line, yeah.
Code-wise, I see only one obvious way to do it given how the codebase is opiniated. It would happen in the persistence-setup Git repo.
One would add what is called a “step” to the code, e.g.
Tails::Persistence::Step::Clean, that takes some of its code as parameters from
Tails::Persistence::Setup (what?! oh crap I wrote it). Learn the basics of Moose if needed, and see examples in the
Tails::Persistence::Step:: namespace. The interaction with the data model would happen in
Tails::Persistence::Configuration (saving the initial configuration, looking for removed atoms or lines — pick the best layer of abstraction, enjoy — between them). Plugging it all together would be done in
Maybe an “Easy” code ticket?
Don’t be discouraged, at least another person (kurono) has already successfully patched it in non-trivial ways. Maybe he would be interested playing with it again :)
#4 Updated by sajolida 2014-12-24 13:25:43
I think that this prompt should suggest that deleting data as the default option. It would be more like a confirmation prompt than a scary warning prompt.
It could be something like:
You are about to disable the following persistent features: * Pidgin * GnuPG Do you want to securely delete the data associated with those features? [Keep] [Delete]
#7 Updated by sajolida 2015-01-03 23:50:33
During the January meeting, we said that:
- We acknowledged the proposal from comment 4.
- We can’t really say “securely delete” on flash media. So that needs rephrasing.
#19 Updated by intrigeri 2019-01-23 10:38:14
One (corner?) case that can make this harder to implement: software may be started and using the very persistent data we want to delete; then all kinds of things can happen, e.g. the software misbehaving, data not being really deleted, the software re-saving it after it’s been deleted, etc. So the only way to do this reliably might be to store on the persistent volume a list of data that needs to be deleted next time the persistent volume is unlocked.