- tor-relays - lists.torproject.org

Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
by denny.obreham＠a-n-o-n-y-m-e.net 31 Oct '23

31 Oct '23

I've been thinking long and hard about this problem and I'm not sure if an email address - validated or not - is the best way to achieve the initial goals. What are the goals of having this validated email address? 1- Inform the operator; 2- Make sure the operator will read the info; 3- Identify the operator. I'll keep #1 for last as this is the only truly needed goal from my point of view. Identifying the operator ID to make further decisions on how to share the traffic may be kind of useless. There are either _good_ operators and you have no real reason to divert traffic from these relays or there are _bad_ operators and they will try to hide that fact by creating multiple identities. Your validated IDs are still useless to you as identifying _bad_relay operators. About validating an email address to make sure the operator will read the info, it is still not a guarantee that it will happen in the future. If an operator does not want to - or cannot - read his/her emails, you cannot do anything about it. Except maybe revalidating the email address regularly which is, first, annoying and, second, what are going to do if a _good_ relay operator doesn't revalidate his/her email address? Shut down all of his/her relays? You might shoot yourself in the foot going with such an attitude. So there is no real point in validating an email. It will just turn out to be more red tape to go through. About point #1, you want to inform the relay operator. Do you need a two-way communication method for that? * How about putting the message to the operator on the _metrics.torproject.org_ relay page? * Would there be any reason for the messages not to be public? * If, somehow, a response - or an exchange - may be needed, why not put a general contact email address for answers, comments, etc. with, for example, the message ID as the subject? If the message is really personal, the message can be as simple as "Contact us at torproject(a)example.org ASAP." * Why not put an RSS feed to be able to fetch those messages automatically and regularly? * That way, you can also contact multiple operators based on their country, platform, etc. with the same message as well. This would be something similar to _weather.torproject.org_ but much simpler and without a need for any kind of registration. Are you sure all operators will follow, read, and act upon your messages? Not less than by sending an email. Much better than NOT having a valid email address at all. A _bad_ operator will be a _bad_ operator no matter what.

2 1

Next Tor Relay Operator online Meetup - Saturday, October 21 @ 19 UTC
by gus 23 Oct '23

23 Oct '23

Hello, The next Tor relay operator meetup will happen this Saturday, October 21 @ 19 UTC. Where: BBB - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Note: BBB requires a browser that supports webRTC such as Firefox, Safari, or Chromium/Chrome. Agenda ------ https://gitlab.torproject.org/tpo/community/relays/-/issues/77 [Expected meeting duration: 60 to 90 minutes] - Announcements: - WebTunnel PT is available on Tor Browser 13 - (Update) Tor on Universities - Meta-proposal for new relay operator policies: https://gitlab.torproject.org/tpo/community/policies/-/blob/master/001-comm… - [Discussion] ContactInfo proposal Everyone is free to bring up additional questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

1 2

PSA: Exit nodes on 0.4.7.x might see less traffic
by Georg Koppen 17 Oct '23

17 Oct '23

Hello everyone! As you might have noticed, Tor Browser 13 got released last week[1] which ships for the first time a Tor 0.4.8.x version (0.4.8.7) to our stable Tor Browser users. One of the main features in the 0.4.8.x series is Conflux, which allows traffic-splitting to improve Tor performance.[2] Given that we assume Tor Browser users are a large fraction of our overall Tor users and 0.4.8.7 deployed by Tor Browser results in pre-built Conflux circuits, there is a chance that exit nodes on 0.4.7.x might see less traffic over time. An easy way to avoid or fix that problem is an upgrade to the 0.4.8.x series. Georg [1] https://blog.torproject.org/new-release-tor-browser-130/ [2] https://gitlab.torproject.org/tpo/core/torspec/-/blob/288c5134ddb737e321cf3…

1 0

Relay Bandwidth Limit
by Dan 16 Oct '23

16 Oct '23

Hi all, I’ve been running my first relay for a few weeks now. The VPS provider I chose provides 5TB of bandwidth per month so I have set AccountingMax to “5 TB” and AccountingStart to

6 7

snowflake prometheus metrics listen address
by Fran 03 Oct '23

03 Oct '23

Hey there, snowflake v2.6.1 offers a prometheus metrics endpoint `-metrics`.[1] Unfortunately I am unable to figure out how to let it listen to non-localhost address: tcp LISTEN 0 4096 127.0.0.1:9999 0.0.0.0:* users:(("snowflake",pid=402248,fd=6)) Any ideas? Thansk! f. [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

2 2

Does Tor itself estimate how it can run as quota-utilizing as possible?
by telekobold 01 Oct '23

01 Oct '23

Hello together, today I apparently discovered an interesting feature of Tor I wasn't aware of: I'm running two relays at a large provider's data center having 20TB/month free outgoing traffic for each relay. However, this quota is often exhausted before the end of a month. In order to provide the Tor project with some bandwidth all the time, I configured "AccountingMax 20 TB" and "AccountingStart month 1 00:00" and, for the last few months, I used to switch off one of the relays on the first of a month and turn it on again a few days after the beginning of the month, so that one of the two relays is running all the time. I also connected the two relays using the "MyFamily" flag. Until last month, each of the relays simply continued to run after the end of the month. Today, however, I wondered why one of the relays shut itself down apparently which did not change after a restart. A look into /var/log/tor/notices.log provided the following entries: Oct 01 16:58:29.000 [notice] Configured hibernation. This interval began at 2023-10-01 00:00:00; the scheduled wake-up time is 2023-10-05 06:06:25; we expect to exhaust our quota for this interval around 2023-10-29 04:23:25; the next interval begins at 2023-11-01 00:00:00 (all times local) [...] Oct 01 16:58:49.000 [notice] Commencing hibernation. We will wake up at 2023-10-05 06:06:25 local time. Oct 01 16:58:49.000 [notice] Going dormant. Blowing away remaining connections. So apparently Tor learned from my behavior and calculated itself when to turn itself off and on again in order to use as much quota as possible based on the bandwidth used and/or some other metrics so I don't have to do this manually in future? Kind regards telekobold

2 2

Bridge with iat-mode=2 very slow
by Split 28 Sep '23

28 Sep '23

Hello everyone! I run the obfs4 bridge, in the parameters I specify to use iat-modr=2. As a result, the bridge is VERY, VERY SLOW. Connection speed is on average 100 kb/sec. When I remove the iat-mode=2 parameter, the speed becomes 8-10 times higher. I checked the processor load, it is at 3%, the problem is unlikely to be with the processor, the RAM load is at 20%. I can't figure out if this is expected behavior or if the speed drop is too significant. Please tell me, is this the normal maximum speed of the bridge with iat-mode=2 or can it be increased somehow?

3 2

Tor Weather : Node-Flag [Guard] Alert
by denny.obreham＠a-n-o-n-y-m-e.net 27 Sep '23

27 Sep '23

I received the following message from Tor Weather. According to Tor Metrics, this exit relay still has no Guard flag. Another - slightly more recent - exit relay (25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57) is on the same server and IP, and still has the Guard flag (although with 0% guard probability). Should I do something with this info? Denny On 09/26/2023 06:31 PM weather(a)torproject.org wrote .. > > > Hi, > > We have detected that the node - 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C associated > with your subscription has lost the Guard flag > for more than 1hr(s). This may impact the performance of your service. > > Thank You!

2 1

Grafana dashboards
by Toralf Förster 16 Sep '23

16 Sep '23

Yesterday I stumbled together 2-3 dashboards [1] for Tor relay(s), Tor Snowflake(s) and the DDoS solution [2]. Feedback is welcome. [1] https://github.com/toralf/torutils/tree/main/dashboards [2] https://github.com/toralf/torutils/tree/main -- Toralf

1 0

Metrics
by BridgeOverStyx 08 Sep '23

08 Sep '23

My bridge styxVortex is up and running. I know this because the Nyx monitor shows activity. However, a search of metrics.torproject.org shows it down. It has been in this state for at least a month. Do you have any suggestions of what could be the possible cause of this? I am using pfblockerng on my network, but the machine that is running Tor bridge is not filtered by it. I do have a couple of TOR feed enabled in pfblockerng but only incoming traffic is filtered. I have no idea how the bridge stats are passed to metrics.torproject.org so it is very challenging for me to tamp down on the cause. Any suggestion, at this point, will be helpful. Sent with [Proton Mail](https://proton.me/) secure email.

6 9