Feature #5831
Warn against file wiping shortcomings
100%
Description
Our current secure deletion documentation does not mention simply wiping a file might not be enough. It probably should.
E.g. "deleted" copies of a file (e.g. with OpenOffice.org). The nautilus-wipe doc probably has more examples about it.
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2014-04-19 |
History
#1 Updated by BitingBird 2014-06-09 11:11:14
- Subject changed from warn against file wiping shortcomings to Warn against file wiping shortcomings
- Description updated
- Starter set to No
#2 Updated by intrigeri 2014-06-21 15:21:45
- related to
Bug #7118: Document that "Securely clean available disk space" does not delete hidden files added
#3 Updated by BitingBird 2015-03-14 23:16:38
- Assignee set to BitingBird
There is https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/index.en.html#index2h1 but it links to a ticket before Redmine.
#4 Updated by BitingBird 2015-03-15 16:05:37
- Status changed from Confirmed to In Progress
- Target version set to Tails_1.3.2
- Feature Branch set to bitingbird:doc/5831-wipe_shortcomings
#5 Updated by BitingBird 2015-03-15 16:27:14
- Assignee changed from BitingBird to sajolida
- QA Check set to Ready for QA
Corrected the ticket link, added a warning against working copies of files (nautilus-wipe has no doc that I could find, so I found no other limitation to document).
Built, look good, please review :)
#6 Updated by BitingBird 2015-03-15 16:27:29
- % Done changed from 0 to 20
#7 Updated by BitingBird 2015-03-19 14:29:25
- Target version changed from Tails_1.3.2 to Tails_1.4
#8 Updated by sajolida 2015-04-24 08:22:01
- Assignee changed from sajolida to BitingBird
- QA Check changed from Ready for QA to Info Needed
I think that the case of working copies is not relevant in Tails as they
are not stored in persistence by default.
I read through `ghelp:nautilus-wipe?nautilus-wipe-data-deletion-intro`
and couldn’t find anything else worth mentioning. I was not sure about
“journalized file systems” but it says that they only keep filename in
their modern Linux versions.
I you agree with my analysis, then I would only cherry-pick your commit
12b368a and drop the rest.
#9 Updated by intrigeri 2015-04-25 03:11:58
> I think that the case of working copies is not relevant in Tails as they are not stored in persistence by default.
I’m not sure I can follow this reasoning (but I didn’t re-read the entire ticket and proposed changes, sorry if I’m off-topic or something).
My reasoning would instead be:
- Working copies are quite often stored alongside the file itself, in the same directory. So, for documents that live on whatever kind of persistent storage, working copies are relevant.
- In Tails, secure erasing of files is only relevant for documents that live on whatever kind of persistent storage.
From these two points, it follows that: for any file that may be worth securely erasing in Tails, working copies are relevant.
#10 Updated by BitingBird 2015-04-25 05:51:58
- Assignee changed from BitingBird to sajolida
That was my reasoning also. sajolida, do you agree, or shall we discuss this further?
#11 Updated by sajolida 2015-04-26 07:20:30
- QA Check changed from Info Needed to Ready for QA
Sorry, I went to fast on this one and you’re right, quite a few software save working copies in the same foloder as the original file. I’ll review and merge that again shortly.
#12 Updated by sajolida 2015-04-28 02:43:56
- Assignee changed from sajolida to BitingBird
- QA Check changed from Ready for QA to Dev Needed
- Feature Branch changed from bitingbird:doc/5831-wipe_shortcomings to doc/5831-wipe_shortcomings
Actuallty, I checked and Libre Office save backup copies in ~/.config/libreoffice/3/user/backup, so at least your example is wrong. I know that other software create backup copies in the same folder (like vi and emacs) but I wonder how common this is amongst the desktop applications that we ship in Tails.
Otherwise, I’m afraid to write something that looks more alarming than what it should. Since this doesn’t apply to Libre Office for example, maybe there’s not much left and we should think about this is a different way.
I’m also wondering whether it would be better to say “backup copies” instead of “working copies”. “Working copies” seems to be OK but “backup copies” make it more clear that this could be the same content and avoid the ambiguity of “working” as in “functioning”.
PS: You’re often writing “example”, with an “e” when it has a “a” in English. Try to activate spellchecking by default and I’ll catch it.
#13 Updated by intrigeri 2015-04-29 08:45:42
> I know that other software create backup copies in the same folder (like vi and emacs) but I wonder how common this is amongst the desktop applications that we ship in Tails.
> Otherwise, I’m afraid to write something that looks more alarming than what it should. Since this doesn’t apply to Libre Office for example, maybe there’s not much left and we should think about this is a different way.
Good point, thanks for checking!
Let’s keep in mind, though, that users may want to use Tails to securely delete files that were created or edited outside of Tails (e.g. the screenshots we have on https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/ display some external drive’s content), so IMO the question should be asked more generally, and not only about apps we ship in Tails.
I’ve re-read the proposed wording, and the way it talks of “potential working copies” doesn’t sound overly alarming to me: it merely warns about a potential shortcoming, that seems important enough to mention if we don’t want to convey a false sense of security. I’ve tried to find an alternate proposal but failed :(
> I’m also wondering whether it would be better to say “backup copies” instead of “working copies”.
Agreed, “backup copies” sounds better :)
#14 Updated by sajolida 2015-04-30 05:03:11
- Assignee changed from BitingBird to sajolida
- QA Check changed from Dev Needed to Ready for QA
> I’ve tried to find an alternate proposal but failed :(
Fair enough. That’s on my plate again, then.
#15 Updated by sajolida 2015-05-07 10:33:08
- Status changed from In Progress to Resolved
- % Done changed from 20 to 100
Applied in changeset commit:0d69700aff4b9e15957c5b749165cfdd41454fd2.
#16 Updated by BitingBird 2015-05-07 16:03:26
- Assignee deleted (
sajolida) - QA Check changed from Ready for QA to Pass