[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