Status: WIP please send your comments until 2017-10-27
I'm writing this with the following motivation:
- make it easier for current and future relay operators to find (rarely used) hosters for tor relays by increasing the information sharing between relay operators. -> help the tor network grow - improve geo- and autonomous system diversity on the tor network (more diverse is better) - collect additional (self-reported) relay metrics (for things like atlas [1] and OrNetStats [2]) https://atlas.torproject.org https://nusenu.github.io/OrNetStats exmples: How many - use tor's Sandbox? - run in OfflineMasterMode? - make use of KIST? - do auto-updates? This data could provide tor developers with information on how well tested/how much used new features (like Sandboxes) are before changing defaults. - improve the ability to contact relay operators (automatically) - make provided information machine readable - provide the foundation for an automated contactInfo verification bot mutually verified email addresses (and other contact options) could be displayed differently on atlas.torproject.org - make t-shirt delivery easier since contact information is potentially already verified - increase the ability to detect undeclared relay groups / make hiding relay groups harder - make hosting costs visible - potentially detect relay operators impersonating other operators by using their email address
Should 10% cw fraction and at least 50 operators use any of the defined fields I'll ask irl (atlas maintainer) to get that specific field added to atlas (separately from the contactinfo string).
Example ContactInfo String --------------------------
email:user[]example-operator.com hoster:https://example-hoster.com uplinkbw:100 trafficacct:unmetered cost:10 virtualization:xen
Considerations ----------------
- increases exposure of relay operators The machine readable information could be used by spammers and to target relay operators. Operators concerned about this can omit contact information but it should not be hard to create a new email address for the purpose.
- more information makes targeted exploitation easier / more silent Attackers could use the additional information provided in these fields to specifically target only vulnerable systems. Operators concerned about sharing configuration information should omit this type of information, but can share other information.
- increased descriptor size and directory traffic The contactinfo field size could potentially grow because of this specification. This should be mitigated with the use of directory data compression and diffs available since tor 0.3.1.
- ContactInfo size constraints According to the manual [2] there is no explicit ContactInfo size limit but there is a descriptor size limit. The max. descriptor size is 20000 bytes [3]. The family size and exit policy are two other relevant inputs.
[2] https://www.torproject.org/docs/tor-manual.html.en#ContactInfo [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364
List of information fields ----------------------------
I started to collect possible fields here:
https://github.com/nusenu/ContactInfo-Information-Shareing-Specification#def...
looking forward to your feedback, nusenu
Document location: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification
Hi,
On 14/10/17 23:01, nusenu wrote a proposal.
The ContactInfo field doesn't need to be overloaded again. ):
See proposal 234 [0] for adding bitcoin/zcash/etc addresses.
Maybe we can work out new fields for extrainfo documents [1] that could contain some of this information.
I do think this is a useful thing to look at, but I just don't think that ContactInfo is the right way to go about it.
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/234-remittance-addr... [1]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n799
Thanks, Iain.
"Iain R. Learmonth" irl@torproject.org wrote:
Hi,
On 14/10/17 23:01, nusenu wrote a proposal.
The ContactInfo field doesn't need to be overloaded again. ):
See proposal 234 [0] for adding bitcoin/zcash/etc addresses.
Maybe we can work out new fields for extrainfo documents [1] that could contain some of this information.
ExtraInfo documents are also one possibility for communicating OutboundBindAddress values, as well.
I do think this is a useful thing to look at, but I just don't think that ContactInfo is the right way to go about it.
I concur.
Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
ExtraInfo documents are also one possibility for communicatingOutboundBindAddress values, as well.
While publising OBA's may be wanted by censoring firewall pedants, it's not productive for relay operators who wish, as is their right, to offer tor users the chance to use exit IP's that are *not* listed in the consensus for easy scraping by such pedants, such that users might have more of a chance to participate freely reading materials on the internet, communicating on forums etc, where such pedants have otherwise blocked access.
Operators that OBA, NAT, VPN, or provide VPN termination IP's on their nodes, have my support as they offering additional censorship resistant services of that kind, even if only marginal due to exit testing, it's still benefit against lazy censors.
Other than that, many times suggested has been ways for relays and primarily third parties subscribable services to calculate, denote, and promulgate for user consumption various "extra" properties of relays, such as Web of Trust (WoT), diversity, other metrics. If not in "Contact", a second, community defined and wikified field could be adopted. Or made purely third party lookup subscription or patch if all such other is refused in tor directly.
Thanks Nusenu, and for all your various work.
Iain R. Learmonth:
The ContactInfo field doesn't need to be overloaded again. ):
See proposal 234 [0] for adding bitcoin/zcash/etc addresses.
Thank you for the pointer. This proposal is from 2014 and I havn't found any trac ticket for it, so I guess no one is working on implementing it. Once this is implemented I'll remove these fields from [1] if onionoo includes these fields.
Maybe we can work out new fields for extrainfo documents [1] that could contain some of this information.
While I agree that it would be nicer to have this as separate fields - and this is the way to go on the long run (if anyone implements it) - in practice this requires a lot more than people just changing their ContactInfo string according to a specification: - proposal(s) - deployment of new tor version on the network - tor code change (implementation) - onionoo code change to parse new data - atlas code change to display new data
Using ContactInfo does not require any tor/onionoo code change even atlas is optional and relay operators don't have to wait for a new tor version that supports it. They can basically start using it once the specification for the format is done (<1month).
I see you played with a long (>5k) contact string already ;) https://atlas.torproject.org/#details/A5B70A588FC01FAC572536B0BC35C7DD425284...
[1] https://github.com/nusenu/ContactInfo-Information-Shareing-Specification
Hi,
On 15/10/17 09:07, nusenu wrote:
See proposal 234 [0] for adding bitcoin/zcash/etc addresses.
Thank you for the pointer. This proposal is from 2014 and I havn't found any trac ticket for it, so I guess no one is working on implementing it. Once this is implemented I'll remove these fields from [1] if onionoo includes these fields.
It would be interesting to see how many relays currently have bitcoin/zcash or similar addresses in their ContactInfo fields.
While I agree that it would be nicer to have this as separate fields - and this is the way to go on the long run (if anyone implements it) - in practice this requires a lot more than people just changing their ContactInfo string according to a specification:
- proposal(s)
- deployment of new tor version on the network
- tor code change (implementation)
- onionoo code change to parse new data
- atlas code change to display new data
This is true.
Using ContactInfo does not require any tor/onionoo code change even atlas is optional and relay operators don't have to wait for a new tor version that supports it. They can basically start using it once the specification for the format is done (<1month).
Perhaps then we can use the fields that people choose to use as an indicator of which ones we should progress to proposals for changes to the descriptors.
I would suggest though that if these do catch on, perhaps proposing an AdditionalInfo field as a catch-all field to house future properties until they can be formalised to avoid doing too much with the ContactInfo field?
Thanks, Iain.
Iain R. Learmonth:
It would be interesting to see how many relays currently have bitcoin/zcash or similar addresses in their ContactInfo fields.
there are >600 relays (>320 unique contactstrings) which have a string in their contactInfo which could match a bitcoin address regex.
tor-relays@lists.torproject.org
-
grarpamp -
Iain R. Learmonth -
nusenu -
Scott Bennett