<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><div><br></div></div><div>On 5 Sep 2018, at 02:36, Damian Johnson <<a href="mailto:atagar@torproject.org">atagar@torproject.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Nyx's 'should this be scrubbed' check is pretty simple [1].</span><br><span>Inbound addresses are scrubbed if...</span><br><span></span><br><span>1. You're configured to accept user traffic (ie. you set BridgeRelay</span><br><span>in your torrc or have receive the Guard flag). [2]</span><br></div></blockquote><div><br></div><span style="background-color: rgba(255, 255, 255, 0);">There are so many edge cases for this check.</span><br><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">Flags are a *recommendation* to clients. They don't force clients</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">to behave a certain way.</span></div><div><br></div><div>For example:</div><div>* clients connecting via bridges can use a middle node as their</div><div> second hop. These middle nodes will leak bridge addresses via nyx.</div><div>* clients and relays can have different consensuses:</div><div> * if a relay loses the Guard flag, and finds out earlier than its clients,</div><div> nyx will stop protecting those clients</div><div> * if a client finds out before the relay, nyx won't protect those clients</div><div>* some Tor client versions don't check the guard flag at all. Others</div><div> keep their guards, even if they lose the flag</div><div>* middle and exit relays can be used as bridges, even if they don't set</div><div> BridgeRelay</div><div>* older Tor versions have a non-zero probability of choosing any relay</div><div> as an entry, even if it doesn't have the guard flag</div><div>* various config options make tor clients ignore the Guard flag</div><div><br></div><div>Please only show an IP if the relay is already public in the consensus.</div><br><blockquote type="cite"><div><span>2. The connection doesn't belong to a another tor relay. [3]</span></div></blockquote><div><br></div><span style="background-color: rgba(255, 255, 255, 0);"><blockquote type="cite">[1] <a href="https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230</a><br>[2] <a href="https://gitweb.torproject.org/stem.git/tree/stem/control.py" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">https://gitweb.torproject.org/stem.git/tree/stem/control.py</a><br>[3] In particular, we check if the address/port is in the consensus.</blockquote><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div>You could also check if the connection is authenticated to a public relay.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">But the IP check works in most cases, and if it fails, it's ok to keep more</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">info private.</span></div><div><br><div>T</div></div></body></html>