Tails

#3 Updated by intrigeri 2014-05-30 01:41:26

> or maybe dropped alltogether, as it’s not the adequate place to
> keep future plans (it could link to the roadmap instead).

This document is made of a specification, followed by a description of
how Tails implements it.

This “future” section is part of the Privacy Enhancing Live
Distribution Specification. These future plans are about updating the
specification, not about improving the Tails implementation thereof.
So, I don’t think that the Tails roadmap is relevant in this context.
(Possibly, though, this section could be replaced by a bunch of
tickets, and a link to the custom Redmine query that lists them, if
someone feels strongly enough about it to do it.)

Anyway, looking at the sub-sections in details:

• “2.7.1 Memory recovery attacks”: next thing to do is to “warn about
  such matters” in the specs. That’s exactly what this section is
  about, so well, either someone does what it says, or it stays as-is.
• “2.7.2 HTTP keepalive”: I think we could probably drop this.
  The goal of our specs and design doc is not to duplicate the TBB’s.
  Instead, we should make it clear that the PELD implicitly includes
  the TBB spec requirements, and list the exceptions to it. This is
  non-trivial specs work.
• “2.7.3 Mounting of filesystems stored on removable devices”: still
  valid, so either someone does it, or it stays as-is.
• “2.7.4 Miscellaneous”: indeed, the PELD should at least warn about
  memory forensics via external bus.

=> I think most of the todo items in these sub-sections are reasonably up-to-date.

If something specific in there strikes you as outdated, please
clarify. Else, I think we can close this ticket.

> The section “caveats” should link to known issues rather than the roadmap.

I added a link to known issues, but kept the roadmap link, as our
roadmap gives insight into things that we consider to be problems, but
are not of the kind one can easily explain to end-users on the known
issues page (e.g. lack of apps sandboxes). Given the target audience
of this document is rather developers, it seems useful to me to point
them to the developers’ view of what needs to be done.