Hi,   On Thursday, March 5, 2020 at 8:24 PM, Imre Jonk imre@imrejonk.nl wrote:

Hi Eddie,

On Wed, 2020-03-04 at 12:34 -0800, Eddie wrote:

...

Does BandwidthRate apply to bridges.  I can (hopefully) guess that RelayBandwidth doesn't. Does the AccountingMax apply.

I am almost certain that all three options apply to bridges as well. Note that BandwidthRate applies to all TCP data (not the TCP headers or DNS traffic), while RelayBandwidth* applies to the _relayed traffic_ only.

...

I noticed the following in the manual:

If you have bandwidth cost issues, enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are always "available".

Does that advice apply equally to bridges, assuming that the Accounting options do apply.  Or would it more advantageous for a bridge to be constantly available, as switching bridges isn't as seamless as switching relays.

That's an interesting question. Bridges are required to provide at least 1 Mbit/s bandwidth, but I can't find anything related to uptime requirements (except for the two hours a day minimum). I'd say that the advice therefore also applies to bridges. The Tor client software can be configured to use multiple bridges.

I would say the recommendation to use AccountingMax does not apply for bridges. It's just a subjective impression but there are often people complaining that most bridges they get handed out don't work or stop working after a short time. Some of these people end up believing that they are unable to use Tor at all from their location, because their adversary successfully detected the bridge. (Which might be true in some cases.)

In order to avoid confusion for people who depend on using bridges it seems to make more sense to limit the bandwith instead.