[tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02

[nusenu]

> It seems to me the specification tries to make use of the fact that the
> ContactInfo field is essentially unstructured text to put things into
> it, in a slightly structured manner, that could be helpful in a number
> of areas (bad relay detection, relay metrics, network growth...). I,
> like others, fear a potential function-creep here essentially wasting
> the time you put into this important work because nobody is adopting
> your suggestions (they are opt-in according to your writing). So, my
> suggestion would be to take a step back and think harder about whether
> all of those areas would really benefit from the work in your
> specification or whether we should try to get improvements elsewhere
> going instead (E.g. I like the idea mentioned by Iain to think about new
> fields for extrainfo documents[4] for some of this information).

It is great if you take this idea an turn it into a tor proposal with new (extra) 
descriptor fields but in the end it will require operators to adopt it 
and it probably does not matter much for an operator whether the information is
put into a single ContactInfo line or into multiple distinct lines with a slight
plus for multiple lines for readability.
Parsing is surely cleaner with new descriptor fields.
The main point is probably to convince operators that such machine parseable information
benefits them and the tor network (at least if you keep the opt-in spirit of the current draft).
I mainly went for the ContactInfo field since it does not require any code changes.

> As another suggestion that could help thinking about your spec: what
> about ahf's idea to deprecate ContactInfo and replace it with a more
> structured format instead? That could go along with the areas above
> which we *actually* think should be covered by the (original)
> ContactInfo field?

The only negative point of removing the ContactInfo field
altogether is loosing information that people put into it. 

 
>> After that I hope it sees some adoption by major operators so I can use your ContactInfo strings
>> for automated verification and as input for malicious relay detection.
> 
> That's one part I don't understand. You advertise the specification as
> opt-in 

yes it is opt-in.

> and relay operators are free to choose from any of the options[5]

with one exception: If someone claims to adopt it, there is one mandatory
field: email
but the adoption in itself is still opt-in. 
One can still use all fields except email, it would just not be according
to this draft.

> but your wording above seems to imply that not following it could make
> the probability higher that the relay will be marked as bad exit. 

I didn't think of it strictly like that but the data would obviously
be usable to detect "false friends" that required manual steps in the past.
false friend = malicious operators using contact info from good operators.

> So,
> there is supposed to happen a silent enforcement over time of an opt-in
> spec which is a weird thing to me. (Additionally, what does it mean in
> your spec that "The email field MUST be provided" given that the whole
> spec is opt-in?) 

I hope my line above helps with this point.


Two more resources by Eran Sandler related to this draft (not matching the latest revision):

generator:
https://torcontactinfogenerator.netlify.com/ 

parser:
https://github.com/erans/torcontactinfoparser 


Thank you for your feedback,
nusenu



-- 
https://mastodon.social/@nusenu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200113/9c95d827/attachment.sig>