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

[Georg Koppen]

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.

Yes, that's what I figured. So, it seems to me not all your proposed
keys are equally important (e.g. your require the email one). Which of
those (or maybe even which cluster of those) are/is important enough in
your opinion to could be considered on topic for a potential tor
proposal? (If we would go that route)

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

Well, it does not necessarily mean losing information as the field would
not just go away but be replaced by other, more narrowed down ones.

Do you have some data about how the field is actually used in the wild
today (I guess you did look at that before starting this proposal
because it would have given you a good overview of what you would have
needed to specify)?

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

Well, yes, at least a bit.

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

Thanks, that's useful.

So, one thing that would be helpful here I think is getting feedback
from the network-team, too, on how to move forward. I could try bringing
this topic up during one of their next weekly meetings. Do you think
this would be a useful thing for me to do?

Georg

-------------- 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/20200116/82c3d8ab/attachment-0001.sig>