[tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Aug 1 19:52:41 UTC 2016


#18910: distributing descriptors accross CollecTor instances
-------------------------------+-----------------------------------
 Reporter:  iwakeh             |          Owner:  iwakeh
     Type:  enhancement        |         Status:  needs_information
 Priority:  Medium             |      Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:  ctip               |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:
-------------------------------+-----------------------------------

Comment (by karsten):

 Moving forward here, after thinking about this problem a bit more.  I'd
 say let's give up on the `@source` annotation idea and, for now, simply
 trust whatever we get from other (trusted) CollecTor instances.  The goal
 should be to start syncing data soon to finally turn the single point of
 failure into many.  And if the spam problem turns out to be a real
 problem, let's solve it.  However, let's keep potentially malicious
 CollecTor instances in mind by taking the following precautions:

  - Allow the operator not only to configure which CollecTor instances to
 sync from, but also let them configure which descriptor types to sync from
 a given instance.  This includes looking at synced descriptor contents and
 skipping unwanted descriptor types (example: bridge descriptor
 "accidentally" contained in synced relay descriptor files).  For example,
 it makes little sense for the primary CollecTor instance to sync bridge
 descriptors from anywhere, because it's the only source for them.  (Oh,
 while writing this, please disregard this suggestion if the plan was to
 limit this feature to relay descriptors anyway.)

  - Check whether the local instance already contains synced data and only
 store remote data if it's better than local data.  For example, it might
 be that a remotely obtained consensus contains fewer signatures than the
 local copy of that consensus, in which case the local copy should be kept.
 But in some cases it's worth adding parts of remote data or even replace
 local data, after being sure that no information gets lost.  Requires a
 per-case consideration.  (Note that this enhancement is not specific to
 syncing from CollecTor mirrors but that it also makes sense to make it for
 fetching from different directory authorities.  It just gets even more
 important now.)

 What precautions did I miss?  And what else is missing to build this?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18910#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list