[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Measure Bridges (Was: Would Conflux have a positive effect against website fingerprinting?)
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).
tor-talk mailing list