Hello,
an earlier version of this has been send to tor-relays [1] and I got some feedback from irl and relay operators via ML and github issues.
Now I'd like to hear from the tor developer community. Please send your feedback until 2017-10-27.
example ContactInfo: https://atlas.torproject.org/#details/1EBFC733CCD952F7F7616EBBA7BC6B8E6F2F0C...
Overview ---------
Tor's ContactInfo descriptor field was primarily intended to contain an email address and PGP key fingerprint but since this field accepts an arbitrary string it has been used for multiple other other purposes (website urls, donation information, bitcoin addresses, ...). Making use of provided information in an automated way is hard since there is no specification on how this string should look like. This is an specification to formalize the ContactInfo string.
Motivation (excerpt) -----------
- collect additional (self-reported) relay metrics (for things like atlas and https://nusenu.github.io/OrNetStats ) - exmples: How many use tor's Sandbox/OfflineMasterKey/KIST feature? - This data could provide tor developers with information on how well tested/how much used new features (like Sandboxes) are before changing defaults.
The entire document can be found here: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification
regards, nusenu
[1] https://lists.torproject.org/pipermail/tor-relays/2017-October/013274.html
On 20 Oct 2017, at 23:44, nusenu nusenu-lists@riseup.net wrote:
- collect additional (self-reported) relay metrics (for things like
atlas and https://nusenu.github.io/OrNetStats )
- exmples: How many use tor's Sandbox/OfflineMasterKey/KIST feature?
- This data could provide tor developers with information on how well
tested/how much used new features (like Sandboxes) are before changing defaults
In general, unstructured text should remain unstructured text.
Automated statistics would be more reliable for these particular use cases. If the information is sensitive, it can be collected using a safe aggregation scheme (PrivCount as described in prop280, or similar).
T
Thank you for the feedback.
teor:
In general, unstructured text should remain unstructured text.
Relay ops are free to choose from the available options (unstructured and structured).
Automated statistics would be more reliable for these particular use cases. If the information is sensitive, it can be collected using a safe aggregation scheme (PrivCount as described in prop280, or similar).
I agree that it would be desirable to not require manual steps (=error prone and likely outdated over time) for items that can be automated.
Most fields on the current list can not be automated though.
Do you consider the following torrc _settings_ too sensitive to publish by relays (without an aggregation scheme)?
- OfflineMasterKey setting (0/1) - SigningKeyLifetime - Sandbox (0/1) - Schedulers
On 21 Oct 2017, at 19:21, nusenu nusenu-lists@riseup.net wrote:
Automated statistics would be more reliable for these particular use cases. If the information is sensitive, it can be collected using a safe aggregation scheme (PrivCount as described in prop280, or similar).
I agree that it would be desirable to not require manual steps (=error prone and likely outdated over time) for items that can be automated.
Most fields on the current list can not be automated though.
Do you consider the following torrc _settings_ too sensitive to publish by relays (without an aggregation scheme)?
- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)
Yes, these are directly related to relay security, so if they can be linked to the relay, they should be opt-in.
- Schedulers
I don't think this is sensitive information.
T
teor:
Do you consider the following torrc _settings_ too sensitive to publish by relays (without an aggregation scheme)?
- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)
Yes, these are directly related to relay security, so if they can be linked to the relay, they should be opt-in.
All fields are opt-in and can be linked to the relay if they are published, but if there are concerns about publishing+collecting that information I can remove these fields.
teor:
- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)
Yes, these are directly related to relay security, so if they can be linked to the relay, they should be opt-in.
I added your note to Sebastian's ticket about publishing key expiry information in descriptors. I like Sebastian's idea but I also agree to your opt-in remark - which means that we will likely not get much data at all (how many relay operators will opt-in vs. the effort to make that possible).
I added your note to Sebastian's ticket about publishing key expiry information in descriptors. I like Sebastian's idea but I also agree to your opt-in remark - which means that we will likely not get much data at all (how many relay operators will opt-in vs. the effort to make that possible).
I should include an URL to Sebastian's ticket:
https://trac.torproject.org/projects/tor/ticket/24194
-
nusenu -
teor