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

[Georg Koppen <gk@xxxxxxxxxxxxxx>]

nusenu:
> Hi,
> 
> I made some updates to the 
> ContactInfo Information Sharing Specification
> draft.
> 
> Most notably I added a new field 'verifyurl' that should allow
> the automatic verification of the operatorurl claim.
> 
> Without it anyone could claim to be part of some operator without the possibility of automated verification.
> 
> You can get the current version on github:
> 
> https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/blob/master/README.md

Thanks for writing that draft. I've been looking over earlier
discussions of it on tor-dev[1] and tor-relays[2] to get more context
for that write-up and I have some questions and suggestions.

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).

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?

> Please send me your comments before 2020-02-02.
> I'm planing to tag a v1.0 in February 2020. 
> 
> 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 and relay operators are free to choose from any of the options[5]
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. 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?)  Again as I said above: we should think about the
different areas this spec covers, and if there is anything we want to
enforce for $purpose we should think about the best way to do so (having
the longer term costs associated with what we pick in mind, too) and
then do it. However, we should avoid any ambiguity in that case and not
get to a slow enforcement of things we originally propagated as merely
opt-in.

Georg

[1]
https://lists.torproject.org/pipermail/tor-dev/2017-October/012507.html ff.
[2]
https://lists.torproject.org/pipermail/tor-relays/2017-October/013274.html
ff.
[3] https://trac.torproject.org/projects/tor/ticket/24526#comment:3
[4]
https://lists.torproject.org/pipermail/tor-relays/2017-October/013275.html
[5] https://lists.torproject.org/pipermail/tor-dev/2017-October/012509.html

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays