<span style="font-family: Arial; font-size: 13px;">Hi,<br><br>If I understand the factors, as things stand currently, regarding family use with respect to the *security* of Tor.<br><br>Pros<br>1 - Prevents information disclosure in case of using related relay too much (relay configuration or seizure of hardware).<br><br>Cons<br>2 - It's not used by operators with malicious intent.<br>3 -
 Reduces diversity in choosing non-malicious relay assuming all relay in
 a family have similar performance/bandwidth. If the metrics vary widely
 in the first place there's the chance it won't matter.<br>4 - Allows use of nickname and fingerprint.<br>5 - Can be used arbitrarily by unrelated nodes to influence path selection.<br>6 - Clients already disobey family under non-deterministic circumstance (not reliably reproduced but have measured)<br><br>The
 proposed changes, in absence of any errata, are an improvement for 
enforcing a bidirectional relationship. For this reason it mitigates (4), and (5). If arbitrary nodes cannot simply join a family it also has less of an impact on (3) than when the tickets were originally filed.<br><br>Towards mitigating (3) it might be worth considering the AS of the related relays. I know 
this increases computation cost so it's more of a thought than even a 
suggestion. If the AS differs across related relay you might consider 
this (honest?) operator a safe choice for not setting the 
family. That is that the family might be better based on similarity of 
AS, supposing that this would make it easier to compromise usage data. 
Another thought is to consider families as a single node for the purpose
 of computing network diversity. If a situation occurs where diversity 
is low it would be useful to not consider families or to reconsider the 
so-called safe-families. You might call this a discussion towards relaxing family definition (slightly) in favor of 
increasing diversity, but staying within the changes of Proposal 242.<br><br><br>--leeroy<br></span>