Tor Relay Guide: relays operators shouldn't expose their fine-grained monitoring graphs public
Even with this warning[1] in Tor Relay Guide, many operators still make their graphs public. We should make this warning bigger like #GettingHelp.
[1]"Note: Do not make your munin (or any other fine-grained monitoring) graphs public since this could help attackers with deanonymizing Tor users."
Activity
please provide examples or be more detailed in your description (e.g. do you mean real time monitoring data or screenshots of them)
Replying to cypherpunks:
please provide examples or be more detailed in your description (e.g. do you mean real time monitoring data or screenshots of them)
Real-time monitoring data, real-time graphs, and screenshots of detailed historical data are all bad for user privacy.
In more detail:
- Currently, public bandwidth reporting over any period less than 24 hours provides less security than tor bandwidth statistics.
- Reporting individual relays is worse than reporting totals for groups of relays. In future, we will securely aggregate Tor's bandwidth statistics, so any individual relay bandwidth reporting will be less secure than Tor's statistics.
- Smaller periods are worse.
- Numbers are worse than graphs.
- Real-time data is worse than historical data.
- Data in categories (IP version, in/out, etc.) is worse than total data.
If they want to report bandwidth, operators should aggregate all their relays' bandwidths over at least a week, then round to the nearest 10 terabytes.
we plan to publish
vnstati -moutput (monthly granularity), for servers (some servers run multiple tor instances, some only single) and it has XX.XX TiB granularity, let me know if you want to discourage thatReplying to cypherpunks:
we plan to publish
vnstati -moutput (monthly granularity), for servers (some servers run multiple tor instances, some only single) and it has XX.XX TiB granularity, let me know if you want to discourage thatPlease round to the nearest 10 terabytes. If you report to the nearest 0.01 terabytes, that's 10 gigabytes per month, or 333 megabytes per day, which seems like a reasonable amount of usage for a client (and therefore something we should try to protect). Rounding to 10 terabytes is ok, because we can't protect clients that use 33.3 gigabytes per day. There aren't enough clients that use that much data.
Please report totals across multiple machines if you can, particularly for machines with only a single relay.
vnstati does not support rounding.
tor reports values daily (xx.xx MiB) for each tor instance.
You are basically saying 'reporting with significantly less granularity than tor itself is still NOT good'? (a single monthly value)
Replying to cypherpunks:
vnstati does not support rounding.
You could use your favourite scripting language to round the numbers.
tor reports values daily (xx.xx MiB) for each tor instance.
Tor reports values in its logs. Occasionally operators will paste logs onto tickets. But that's not the same as reporting them publicly every month.
You are basically saying 'reporting with significantly less granularity than tor itself is still NOT good'? (a single monthly value)
Yes, we're moving towards relay statistics that are securely aggregated across the network, with no individual relay totals.
Please do your best to protect Tor users by aggregating and rounding your bandwidth as much as you can.
Replying to teor:
Replying to cypherpunks:
I'll talk to them.
That tweet is a year old. They stopped because of user privacy issues.
tor reports values daily (xx.xx MiB) for each tor instance.
Tor reports values in its logs. Occasionally operators will paste logs onto tickets. But that's not the same as reporting them publicly every month.
Tor does report data to dir auths and collector and onionoo publish it, RS makes graphs of it having daily granularity.
That tweet is a year old. They stopped because of user privacy issues.
I was well aware of it but it is prominently pinned and it animates others to basically do the same - and it is associated with the official torproject relay advocate.
Replying to cypherpunks:
That tweet is a year old. They stopped because of user privacy issues.
I was well aware of it but it is prominently pinned and it animates others to basically do the same - and it is associated with the official torproject relay advocate.
Replying to cypherpunks:
tor reports values daily (xx.xx MiB) for each tor instance.
Tor reports values in its logs. Occasionally operators will paste logs onto tickets. But that's not the same as reporting them publicly every month.
Tor does report data to dir auths and collector and onionoo publish it, RS makes graphs of it having daily granularity.
Yes, it does. And we're working on making it more secure. Please work with us to make it more secure.
could you put in references to the tickets? thanks!
since vnstat reports interface traffic and not tor-exclusive traffic I assume it is ok to publish, if it isn't please say so
Replying to cypherpunks:
could you put in references to the tickets? thanks!
#24104 (moved) - Delay descriptor bandwidth reporting on established relays
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/PrivCountInTor https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/PrioritiseStatisticsForPrivCountInTor https://trac.torproject.org/projects/tor/wiki/org/meetings/2018NetworkTeamHackfestSeattle/privcount
#22898 (moved) - Help get privcount standardized and merged
Replying to cypherpunks:
since vnstat reports interface traffic and not tor-exclusive traffic I assume it is ok to publish, if it isn't please say so
I think you might have missed my earlier answer:
Replying to teor:
Replying to cypherpunks:
we plan to publish
vnstati -moutput (monthly granularity), for servers (some servers run multiple tor instances, some only single) and it has XX.XX TiB granularity, let me know if you want to discourage thatPlease round to the nearest 10 terabytes. If you report to the nearest 0.01 terabytes, that's 10 gigabytes per month, or 333 megabytes per day, which seems like a reasonable amount of usage for a client (and therefore something we should try to protect). Rounding to 10 terabytes is ok, because we can't protect clients that use 33.3 gigabytes per day. There aren't enough clients that use that much data.
Please report totals across multiple machines if you can, particularly for machines with only a single relay.
if weekly values should be rounded to the nearest 10TiB, should monthly values be rounded to the nearest 40 TiB?
content from teor added to the guide: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide?sfp_email=&sfph_mail=&action=diff&version=224&old_version=221&sfp_email=&sfph_mail=
a better graphic warning will be added once this guide is moved to the new portal.
if you are not happy with it, please do reopen this ticket
Trac:
Resolution: N/A to fixed
Status: new to closedReplying to cypherpunks:
if weekly values should be rounded to the nearest 10TiB, should monthly values be rounded to the nearest 40 TiB?
I said that monthly values should be rounded to 10 TB: https://trac.torproject.org/projects/tor/ticket/26620?replyto=18#comment:4
Weekly values should also be rounded to 10 TB, because it's a shorter period, and shorter periods are more risky for client anonymity.
(When we implement #22898 (moved), we will have a precise specification for the amount of noise that Tor adds. Then we can calculate the noise that he entire Tor network needs to add to keep bandwidth safe, and update the suggested rounding. I'm using 10 TB as a conservative estimate.)
- Trac closed
closed