On February 3, 2019 10:19:00 PM UTC, nusenu nusenu-lists@riseup.net wrote:
Thanks for this email. I exporting more metrics on the control port
is a
great idea. I wanted to have that for a while
Great to hear that so we have a realistic chance it gets actually implemented :)
There are safety questions to ask ourselves here before blindly exporting many stats.
Sure.
Exporting many stats to the control port unfortunately means that all relay operator can possibly create fancy graphs
making non-public graphs and alerts is the goal
and make them public
public graphs should result in the rejection of affected relays. I'll be submitting a few to bad-relays@ soon since enn.lu apparently does not care when asked to remove their public stats and xml data.
which, depending on the stat, can be harmful.
Furthermore, graphing stats can also means that over time the relay operator stores historical data of everything that happened within
the
relay and that can be used in many ways to pull off attacks (ex: subpoena to access such data base by LE).
yes, acceptable / unacceptable retention times and granularity should be defined and documented. I'd propose a max. retention time of two weeks.
The Heartbeat log has a minimum of 30 minutes period but a default of
6
hours.
current tor has no restrictions on Heartbeat granularity, you can ask tor to write the data to the logs every other second by issuing "SIGNAL HEARTBEAT" on the control port.
Whatever stats we would end up exporting, I strongly think that keeping delays like that is a strong requirement because we would
sort
of "bin" those aggregated stats by a "long enough period" instead of having a very fine grained stream of stats that would make it trivial
to
spot spikes down to the minute.
30 or 60 minutes granularity seems reasonable
Some of the stats below are safe in my opinion like the memory usage
but
most of them need to be looked at in terms of safety
yes please
Here's another design that preserves user privacy: * add noise to every logged statistic (to protect usage in the current period) * round every logged statistic (to protect average usage over multiple periods)
If we add enough noise to protect most users, then we will have privacy by design.
We should still teach operators why detailed stats are bad for users. And have rules about retention periods. But these rules won't be as critical as they are now, because the rules will only be needed for edge cases. (Like a single client that uses moat of a relay, which we can't hide very well, no matter what we do.)
Adding noise will be easier once PrivCount is implemented. Until then, we'll need to rely on the retention rules you are suggesting.
T
-- teor ----------------------------------------------------------------------