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#defined-fields looking forward to your feedback, nusenu Document location: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification -- https://mastodon.social/@nusenu twitter: @nusenu_
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays