14.07.2013 20:28, Mike Perry: > Sebastian G. <bastik.tor>: >> >> (Those bridges get more common and are essential to the diversity of the >> user-base Tor has.) >> >> (The quoted sentence still sounds to me as bridges would be the cause of >> Tor's partial slowness.) > > The core problem is that bridges are unmeasured and not load balanced. > > We currently have not implemented a way to check if a potential bridge > relay is fast enough for the "Fast" relay cutoff,
Would it be possible to measure bridges without making an observer know it's a bridge? A central server connecting to bridges to measure their bandwidth would reveal - by looking at a single server - that they are bridges, not just clients, wouldn't it? A decentralized approach would require multiple trusted members and would still reveal the location of bridges, right? Bridges could perform self-tests including measuring their own bandwidth and include the results in their descriptors. What does the bridge download and upload to test the bandwidth? Where are those files located? Clients don't do this, so seeing it would let me conclude there's a bridge running. > for example, let alone > making sure users are allocated to them in proportion to bandwidth > (which is a much harder problem). Bridge distribution is in general pretty difficult. (It appears to be the case to me.) Users don't get that many bridges, they are not in the position to base their paths on the bandwidth of bridges. BridgeDB handing out faster bridges more often could mean that those get blocked faster, what makes it far from ideal, I guess. Pluggable Transports would require measurement as well and handing out their information would face the same problems. (Getting out fast enough ones that also work). Best, bastik _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
