Re: [tor-dev] putting 'Nuke MyFamily' to vote (#6676)
We'd obviously lose some connections if we lost MyFamily. And I'd prefer not to lose them. However, if there's other needs which require the nuking of MyFamily, my/Roster's world would not end. -V On Sunday, 17 April 2016, Tim Wilson-Brown - teor wrote: > > > On 16 Apr 2016, at 17:13, Virgil Griffith > > wrote: > > > > I'm not wholly in favor of keeping MyFamily in its current form. In > Roster we simply need a way to identify when two relays are owned by the > same operator. Worst comes to worst we could use the email address in the > ContactInfo, or some such. > > Some operators use a variant email address or ContactInfo for each relay, > although these are in the minority. > Others don't have any ContactInfo at all. > I'm not sure whether any of these relays declare MyFamily or not, I'd have > to check. > > I'd like to know how many relay associations we'd lose in the current > network by removing MyFamily before we make a decision. > > > There have been proposals to do more creative signature schemes for > MyFamily ownership. This would also be a satisfactory solution. > > I wonder if this kind of complexity would be worth it. > Do we gain much over the current system by using a signature scheme? > (Apart from making large families shorter and easier to administer, at the > cost of making small families longer.) > > > In summary, my world would not end if MyFamily ceased to existwe'd > simply use the ContactInfo for family membership. Obviously family > membership then becomes spoofable, but perhaps who cares? > > It makes some difference for fallback directories, where we use a > combination of family, contact, and IP to work out which relays are more > likely to go down at the same time. > > I also wonder about the impact on path selection and client security - > even an honest operator can have their relays compromised or be compelled > to provide information. > > Tim > > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > ricochet:ekmygaiu4rzgsk6n > > > > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] putting 'Nuke MyFamily' to vote (#6676)
> On 16 Apr 2016, at 17:13, Virgil Griffith wrote: > > I'm not wholly in favor of keeping MyFamily in its current form. In Roster > we simply need a way to identify when two relays are owned by the same > operator. Worst comes to worst we could use the email address in the > ContactInfo, or some such. Some operators use a variant email address or ContactInfo for each relay, although these are in the minority. Others don't have any ContactInfo at all. I'm not sure whether any of these relays declare MyFamily or not, I'd have to check. I'd like to know how many relay associations we'd lose in the current network by removing MyFamily before we make a decision. > There have been proposals to do more creative signature schemes for MyFamily > ownership. This would also be a satisfactory solution. I wonder if this kind of complexity would be worth it. Do we gain much over the current system by using a signature scheme? (Apart from making large families shorter and easier to administer, at the cost of making small families longer.) > In summary, my world would not end if MyFamily ceased to existwe'd simply > use the ContactInfo for family membership. Obviously family membership then > becomes spoofable, but perhaps who cares? It makes some difference for fallback directories, where we use a combination of family, contact, and IP to work out which relays are more likely to go down at the same time. I also wonder about the impact on path selection and client security - even an honest operator can have their relays compromised or be compelled to provide information. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] putting 'Nuke MyFamily' to vote (#6676)
I'm not wholly in favor of keeping MyFamily in its current form. In Roster we simply need a way to identify when two relays are owned by the same operator. Worst comes to worst we could use the email address in the ContactInfo, or some such. There have been proposals to do more creative signature schemes for MyFamily ownership. This would also be a satisfactory solution. In summary, my world would not end if MyFamily ceased to existwe'd simply use the ContactInfo for family membership. Obviously family membership then becomes spoofable, but perhaps who cares? -V On Sunday, 27 March 2016, nusenu wrote: > One year after my last thread on that topic [0] I'd like to move forward > on the question whether tor should have a MyFamily functionality or not, > because it seems to be a blocker of prop242 (#5565) and it is clear that > the current MyFamily design is not practical for many - given the amount > of improper or undeclared families [6]. > > prop 242 is also relevant in the context of Sibyls because if MyFamily > becomes trivially easy for everyone to configure one might even start to > use it to tell "good" and "bad" apart. > > If you have an opinion on that topic please reply. > > I tried to collect opinions on that from past threads and trac. > > When Nick asked "So, what do we think?" last year only people in favor > of keeping it replied. > > In favor of keeping it: > Nick [1] > Teor [2] > Virgil [3] > Griffin [4] > Moritz [5] > > In favor of nuking MyFamily: > rransom > anyone? > Please speak up. > > Tools that use/display/process/depend on MyFamily: > - tor-roster.org > - onionoo > - atlas > - others? > > Can we close #6676 if no one is in favor of removing MyFamily? > https://trac.torproject.org/projects/tor/ticket/6676 > > > > [0] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html > [1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008517.html > [2] https://lists.torproject.org/pipermail/tor-dev/2015-March/008531.html > [3] https://lists.torproject.org/pipermail/tor-dev/2015-March/008527.html > [4] https://lists.torproject.org/pipermail/tor-dev/2015-March/008529.html > [5] https://trac.torproject.org/projects/tor/ticket/6676#comment:8 > [6] > > https://raw.githubusercontent.com/nusenu/tor-network-observations/master/tor_families_master.txt > > https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt > > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] putting 'Nuke MyFamily' to vote (#6676)
One year after my last thread on that topic [0] I'd like to move forward on the question whether tor should have a MyFamily functionality or not, because it seems to be a blocker of prop242 (#5565) and it is clear that the current MyFamily design is not practical for many - given the amount of improper or undeclared families [6]. prop 242 is also relevant in the context of Sibyls because if MyFamily becomes trivially easy for everyone to configure one might even start to use it to tell "good" and "bad" apart. If you have an opinion on that topic please reply. I tried to collect opinions on that from past threads and trac. When Nick asked "So, what do we think?" last year only people in favor of keeping it replied. In favor of keeping it: Nick [1] Teor [2] Virgil [3] Griffin [4] Moritz [5] In favor of nuking MyFamily: rransom anyone? Please speak up. Tools that use/display/process/depend on MyFamily: - tor-roster.org - onionoo - atlas - others? Can we close #6676 if no one is in favor of removing MyFamily? https://trac.torproject.org/projects/tor/ticket/6676 [0] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html [1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008517.html [2] https://lists.torproject.org/pipermail/tor-dev/2015-March/008531.html [3] https://lists.torproject.org/pipermail/tor-dev/2015-March/008527.html [4] https://lists.torproject.org/pipermail/tor-dev/2015-March/008529.html [5] https://trac.torproject.org/projects/tor/ticket/6676#comment:8 [6] https://raw.githubusercontent.com/nusenu/tor-network-observations/master/tor_families_master.txt https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
