Update Tails links and work around changes in Tails documentation

nathandyer commented 3 months ago

Status

Ready for review

Description of Changes

This PR fixes #543 by replacing references to tails.boum.org with tails.net.

As part of the changes with Tails' new domain name and updated documentation, some of the previous documentation links no longer exist. The most notable one is related to Wiping files/drives. This functionality was removed in Tails 6.0, and as a result the Tails documentation has changed to reflect this.

Given these external changes, this commit also removes references to the Wipe option in files, and instead encourages the use of the Trash (which is not ideal, and may not actually be good advice).

Before merging, we should determine if Trash is sufficient, or if there is a better option.

Resolves #543

Testing

[ ] Visual review
[ ] make linkcheck passes for all Tails-related domains
[ ] We are happy with substituting the Trash workflow to replace Wiping

Checklist (Optional)

[x] Doc linting (make docs-lint) passed locally
[ ] Doc link linting (make docs-linkcheck) passed
- [x] Passed for all Tails-related domains; other fixes are likely out of scope for this PR
[x] You have previewed (make docs) docs at http://localhost:8000

eloquence commented 3 months ago

Thanks @nathandyer! The link changes LGTM.

Regarding the changes to Tails' secure delete behavior, pinging @freedomofpress/seceng for input. IMO your changes here are a net improvement because they correctly describe the current capabilities, and the previous "secure wipe" advice was arguably misleading (and now no longer works).

However, it might be warranted to add new advice for regularly overwriting the export device, to ensure that an attacker who recovers the passphrase cannot undelete previously exported files. That seems like it could be tracked as a separate follow-up issue.

lsd-cat commented 3 months ago

The Tails documentation is right, in modern flash based devices there is no guarantee of a match of the writing destination between the firmware level and the physical level. It is basically impossible to enforce a sequential overwrite, and even though that is doable via the filesystem, it is very unlikely that such behavior will be respected in underlying level.

So for wiping individual files, there are not really workarounds. For wiping full drives, in the theory SSD secure delete functions are reasonable (they swap transparent encryption keys at the firmware level), but in practice we know these implementations happen to be not so reliable.

As for ensuring a full overwrite/wipe of a device besides the firmware provided function, I need to do some research if there are proven alternatives.

eloquence commented 3 months ago

@lsd-cat Does the approach of merging this PR and tracking follow-up separately sound reasonable to you?

freedomofpress / securedrop-docs