Dear readers,
During the last week the bytes/second of my bridge dropped to 20% of its common usage over the past months, while the average number of connected clients stayed the same (according to metrics.torproject.org).
I'm also seeing a dozen circuit connections with purpose Hs_vanguards in nyx recently, which are not familiar to me.
Under-utilization of my bridge is not a problem to me, but maybe someone can tell me whether the two are related?
Maybe it's an issue at my end or my hoster or maybe a generic issue of the tor network currently? Or maybe it's all normal?
Thanks and best regards
Hi folks,
As part of the hackweek projects
( https://gitlab.torproject.org/tpo/community/hackweek/ ),
some of us are thinking about simple tweaks we can do to tune the network
to better handle this month's traffic overload.
The long term answer is to try out proposal 327:
https://gitweb.torproject.org/torspec.git/tree/proposals/327-pow-over-intro…
because we think a lot of the overload has to do with people sending
way too many intro cells to some onion services, and giving the onion
services ways to defend themselves is the only real answer.
But while we're thinking about implementing that proposal, one of our
earlier steps is to set the guard-n-primary-guards-to-use consensus
parameter from 1 to 2.
Now that it's taken effect (you can watch the votes at
https://consensus-health.torproject.org/#consensusparams ), this change
means that clients will now choose between two guard relays by default
(rather than just one) when building circuits.
This is potentially a big deal, since it puts us into a different point
in the performance vs safety tradeoff space.
Here is some reading for why we originally moved down to 1 guard by default:
https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramet…https://www-users.cse.umn.edu/~hoppernj/single_guard.pdf
But on the theory that some guards are way overloaded right now and
some aren't, giving clients two bites at the apple might make a dramatic
improvement in terms of reliable and consistent performance.
There is also some argument in favor of using two guards anyway. One
reason (explained more in proposal 291) is that there are already
some edge cases where clients use their second guard. And also, in the
glorious future, we will want to be using multiple guards because we
have switched to the multi-path Conflux design (proposal 329) -- though
we're not there yet.
So: I am giving you all here some early warning, in case you see anything
odd on the network when we make this change. Let us know if you do. :)
--Roger
Dear all,
ExoneraTor is/was useful for showing law enforcement authorities that
a given IP address acted as a Tor exit relay at a given day.
Unfortunately, ExoneraTor seems to be offline.
This page does not work at all, returning an HTTP 503 error
immediately: https://exonerator.torproject.org/
This page returns the following error whenever I submit an IP address:
https://metrics.torproject.org/exonerator.html
| Server problem
|
| Unable to connect to the database. Please try again later. If this problem persists, please let us know!
Can it be revived? Can I help?
Cheers,
Christian
--
Christian Pietsch
volunteering for Digitalcourage e.V. https://digitalcourage.de/
– Swarm support: https://digitalcourage.de/swarm-support
– German BigBrotherAwards: https://bigbrotherawards.de/
