[TWN team] Recent changes to the wiki pages

[Lunar]

===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2014/38 ===
===========================================================================

version 25
Author: harmony
Date:   2014-09-22T19:04:17+00:00

   remove covered item

--- version 24
+++ version 25
@@ -207,6 +207,5 @@
 
 Possible items:
 
- * Guardiness: Yet another external dirauth script https://lists.torproject.org/pipermail/tor-dev/2014-September/007489.html
  * (event) https://mailman.boum.org/pipermail/tails-project/2014-September/000037.html next Tails contributors meeting
  * Attack linking Tor circuits https://lists.torproject.org/pipermail/tor-dev/2014-September/thread.html#7489

version 24
Author: harmony
Date:   2014-09-22T18:57:31+00:00

   write guardiness item

--- version 23
+++ version 24
@@ -44,6 +44,49 @@
  [XXX]: https://www.eff.org/deeplinks/2014/09/tor-challenge-inspires-1635-tor-relays
  [XXX]: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
  [XXX]: https://www.torproject.org/docs/tor-doc-relay
+
+Guardiness and Tor’s directory authorities
+------------------------------------------
+
+When a Tor relay is first assigned the Guard flag by the directory
+authorities (or “dirauths”) it sees a dip in the amount of traffic
+passing through it, because Guard capacity is a scarce resource on the
+Tor network and, as Roger Dingledine explained last year [XXX], “all the
+rest of the clients back off from using you for their middle hops,
+because when they see the Guard flag, they assume that you have plenty
+of load already from clients using you as their first hop”, an
+assumption which is only correct after clients have had enough
+opportunity to select the new guard. With the recent move to single
+entry guards, an even longer period of time may pass before a young
+guard can be selected as a first hop by old clients.
+
+“Guardiness”, or GuardFraction, is a proposed measurement to let
+dirauths, and therefore clients, work out how much of a relay’s capacity
+is being used for first hops by clients, and how much for second and
+third hops, by finding the fraction of recent consensuses in which
+the relay has been given the Guard flag [XXX]. George Kadianakis
+published [XXX] an analysis of ways in which dirauths’ votes could be
+extended to include this guardiness measurement, taking into account the
+time and effort required to parse large numbers of Tor consensuses very
+quickly. The initial proposal was to ask dirauths to run a script each
+hour that would extract the data required for parsing into “summary
+files”, while Peter Palfrader suggested [XXX] that loading every
+consensus into a database for later querying might be more efficient,
+and Sebastian Hahn asked [XXX] how this measure might fail in different
+situations.
+
+“This feature is by far the trickiest part of prop236 (guard node
+security) and I wanted to inform all dirauths of our plan and ask for
+feedback on the deployment procedure”, wrote George. If you have any
+comments to add to the discussion so far, please send them to the tor-dev
+mailing list [XXX].
+
+ [XXX]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
+ [XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt#l101
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-September/007489.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-September/007526.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-September/007490.html
+ [XXX]: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
 
 Miscellaneous news
 ------------------



-- 
Your friendly TWN monitoring script

      In case of malfunction, please reach out for lunar at torproject.org
          or for the worst cases, tell weasel at torproject.org to kill me.