Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • B blueprints
  • Project information
    • Project information
    • Activity
    • Members
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Terraform modules
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
Collapse sidebar
  • tails
  • blueprints
  • Wiki
  • persistent_Tor_state

persistent_Tor_state · Changes

Page history
Adjust for ikiwiki → GitLab wiki authored Jan 12, 2021 by intrigeri's avatar intrigeri
Hide whitespace changes
Inline Side-by-side
persistent_Tor_state.md
View page @ a5d53a93
[[!toc levels=3]]
[[_TOC_]]
# Big picture
This is about [[!tails_ticket 5462]].
This is about tails/tails#5462.
There are a few good reasons for making Tor's data directory
persistent:
......@@ -29,8 +31,8 @@ a persistence preset for it.
* Using persistent Entry Guard(s) [is a problem for mobile
users](https://lists.torproject.org/pipermail/tor-talk/2012-October/025975.html),
as it gives attackers some bits for AdvGoalTracking (see [[the MAC
address spoofing design documentation|contribute/design/MAC_address]]),
as it gives attackers some bits for AdvGoalTracking (see [the MAC
address spoofing design documentation](https://tails.boum.org/contribute/design/MAC_address)),
even if this is less severe than it used to be, thanks
to the move to a single Entry Guard. We want to protect users
against AdvGoalTracking, including versions thereof where the
......@@ -372,7 +374,7 @@ Prerequisites: this can happen only once we don't rely anymore on the
fact that certain files in `/var/lib/tor` are not persistent.
More specifically:
* [[!tails_ticket 5774]] needs to be resolved (our time syncing script
* tails/tails#5774 needs to be resolved (our time syncing script
uses the existence of `cached-descriptors` as a test for whether Tor
is working, and a similar assumption is made for the
`*-consensus` files;
......@@ -439,7 +441,7 @@ Finally, we seed the Tor PRNG with:
Note that Entry Guard(s) selection depends on the current state of the
Tor network, and not only on how the Tor PRNG has been seeded.
See [[!tor_bug 2653]] for further ideas on this topic.
See [bug #2653 on Tor Project's Trac](https://bugs.torproject.org/2653) for further ideas on this topic.
<a id="drawbacks"></a>
......@@ -527,8 +529,7 @@ feature, hence:
habits now.
* We have considered requesting user input _once_, both to
parameterize Entry Guard selection, and for [[!tails_ticket
desc="seeding the entropy pool" 7675]]. This was discarded since the
parameterize Entry Guard selection, and for seeding the entropy pool (tails/tails#7675). This was discarded since the
entropy pool seed should ideally contain, well, quite some entropy,
while the requested user input for Entry Guard selection should be
short, easy to type and to remember.
......@@ -559,4 +560,5 @@ feature, hence:
randomly." (source: *Why MAC Address Randomization is not Enough:
An Analysis of Wi-Fi Network Discovery Mechanisms*)
* How is this impacted by the changes brought by [[!tor_bug 12600]]?
* How is this impacted by the changes brought by [bug #12600 on Tor Project's Trac](https://bugs.torproject.org/12600)?
Clone repository
  • ARM_platforms
    • Acer_Chromebook_R_13_CB5 312T
  • Add_Gnome_PPP_for_Dial Up_Users
  • CI_usability
  • Debian_Stretch
  • Debian_testing
  • Endless_upgrades
  • Faster_builds
  • GNOME_bugs_that_affect_Tails
  • GNotification
  • GitLab
  • Git_sub repositories
  • HTTP_mirror_pool
    • archive
  • HackFest_2014_Paris
View All Pages