[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #2372 [BridgeDB]: Export BridgeDB's pool assignments
#2372: Export BridgeDB's pool assignments
-------------------------+--------------------------------------------------
Reporter: karsten | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: BridgeDB | Version:
Keywords: | Parent:
-------------------------+--------------------------------------------------
Following the (actually newly introduced) tradition of summarizing IRC
discussions in Trac or email, here's what Roger and I discussed today:
I'm interested in learning whether keeping a certain fraction of bridges
unassigned, that is not distributing them via email or HTTP, is a good
idea. AIUI, the idea was to have a small set of fresh bridges in case we
come up with a new distribution channel or want to give out fresh bridges
manually. This idea might fail if people who run a bridge that ends up in
the unallocated pool decide that their bridge is not being useful. They
might turn off their bridge or delete their keys in order to get a new
fingerprint and end up in another pool. If many people do so, we might
better allocate all bridges to pools directly and start a new pool
whenever there's a new distribution channel. Given the high churn of
bridges, we might have a sufficient set of fresh bridges in that pool very
soon. Also, if we want to give out bridges manually, we might give out
bridges from the other pools which may have higher uptime than bridges in
the unallocated pool. Allocating all bridges also means we don't have to
explain to bridge operators why their bridge is also useful even if it
doesn't have any users right now.
So, we need to export pool assignments from BridgeDB somehow. Currently,
we have log files of the following format:
{{{
Jan 10 01:41:14 [DEBUG] Leaving bridge 1.2.3.4:443
dddddddddddddddddddddddddddddddddddddddd unallocated
Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1 (port-443 subring)
Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1 (stable subring)
Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1
}}}
If we want to analyze bridge pool assignments we need a better data format
than this log format. Here's a proposed data format for bridge pool
assignments (with sanitized IP addresses and fingerprints):
{{{
bridge-pool-assignment 2011-01-10 01:41:14
b 127.0.0.1:443 abcdef0123456789abcdef0123456789abcdef01
b 127.0.0.1:443 0123456789abcdef0123456789abcdef01234567
s IP ring 1 (port-443 subring)
s IP ring 1 (stable subring)
s IP ring 1
}}}
The timestamp in the bridge-pool-assignment line is the time when the
assignment is written to disk (twice an hour). Lines starting with b
contain IP address, port, and fingerprint of a bridge. For sanitizing
purposes, I replaced bridge IP addresses with 127.0.0.1 and bridge
identities with their SHA-1 hashes. That's the same approach that we take
for sanitizing bridge descriptors. Lines starting with s contain the
rings or subrings that a bridge is allocated to.
Possible questions that I'm trying to answer with these data are:
1. Do bridges ever switch pools?
2. Is bridge uptime affected by the pool assignment?
Are there reasons not to publish the sanitized versions of these bridge
pool assignments? Are any sensitive data left that we need to remove?
Can we change the BridgeDB code to export its pool assignment in this
format (without the sanitizing which I would do on a metrics machine)?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2372>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs