Add Onionoo's exit_addresses field

Ideally display them similarly to the entries in the MyFamily lists.

added component::metrics/relay search metrics-2017 owner::irl priority::medium resolution::fixed severity::normal status::closed type::enhancement labels

Trac:
Summary: add exit_addresses onionoo field to at atlas to add exit_addresses onionoo field

Replying to cypherpunks:

Ideally display them similarly to the entries in the MyFamily lists. I don't think this is ideal because it would be inconsistent with the style of the OR and Dir addresses fields.

Regarding the implementation of this feature, the Onionoo documentation on the exit_addresses field states it is an

[a]rray of IPv4 or IPv6 addresses that the relay used to exit to the Internet in the past 24 hours. IPv6 hex characters are all lower-case. Only those addresses are listed that are different from onion-routing addresses. Omitted if array is empty. This means exit relays that use the same address(es) for both OR and exiting have no exit_addresses field. Showing the field as empty (or none as is common for empty fields in Atlas) is confusing IMO. I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

Trac:
Owner: irl to cypherpunks
Status: new to accepted

Replying to cypherpunks:

I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

I'm not sure about this. Maybe when I see it I'll have a better idea. OR addresses have ports, exit addresses do not. While I can see how these are related, I wonder what the best presentation would be. It also cannot be assumed that an empty exit_addresses means that it will exit from the OR address, as it may just be that the exit scanner is broken, so that confusion should be avoided also.

Replying to irl:

Replying to cypherpunks:

I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

I'm not sure about this. Maybe when I see it I'll have a better idea. OR addresses have ports, exit addresses do not. I will strip off the ports before merging the fields.

While I can see how these are related, I wonder what the best presentation would be. It also cannot be assumed that an empty exit_addresses means that it will exit from the OR address, as it may just be that the exit scanner is broken, so that confusion should be avoided also. From the wording of the Onionoo description i assumed the OR address is always an exit address. Is this not correct?

Replying to cypherpunks:

This means exit relays that use the same address(es) for both OR and exiting have no exit_addresses field. Showing the field as empty (or none as is common for empty fields in Atlas) is confusing IMO. I disagree, there is a distinction between OR address and exit_address.

I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

Please do not merge them.

Replying to cypherpunks:

From the wording of the Onionoo description i assumed the OR address is always an exit address. Is this not correct?

No this is not correct. See also: https://www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit

Onionoo is rather clear about exit_addresses:

Only those addresses are listed that are different from onion-routing addresses

the same level of clearness should be on the atlas page displaying exit_addresses.

Empty exit_addresses for exits that exit with their OR IP address are clear in the context of the above statement.

Replying to nusenu:

Onionoo is rather clear about exit_addresses:

Only those addresses are listed that are different from onion-routing addresses

the same level of clearness should be on the atlas page displaying exit_addresses.

Empty exit_addresses for exits that exit with their OR IP address are clear in the context of the above statement. Okay, I'll not merge the two fields and add emphasis to the distinction in a tooltip.

thanks. The title for the list of exit_addresses could be "Not-announced Exit IP Addresses"

Trac:
0001-Add-a-field-for-the-exit-addresses-of-relays.patch

Replying to nusenu:

thanks. The title for the list of exit_addresses could be "Not-announced Exit IP Addresses" I kept the title similar to existing fields by simply naming it Exit Addresses.

I've opened #22160 (moved) for improving the address list style because some relays have more than two exit addresses which leads to styling issues.

Trac:
Status: accepted to needs_review

Also note that this list can be rather long (biggest entry I've seen so fare was 297 chars long). That is why I suggested to use a vertical style like the fingerprints in family blocks.

Replying to nusenu:

Also note that this list can be rather long (biggest entry I've seen so fare was 297 chars long). That is why I suggested to use a vertical style like the fingerprints in family blocks. Can you give the fingerprint so i can use it while working on #22160 (moved)?

this one is 173 chars long:

https://onionoo.torproject.org/details?fingerprint=8ED43EC3683D7E261BB8FEA4EA8122952968CF8E& fields=exit_addresses

Can the patch be updated to work better with the longer lists?

Trac:
Status: needs_review to needs_revision

Trac:
0001-Support-long-address-lists.patch

Trac:
0002-Reorder-fields-to-group-similar-styling-together.patch

I've attached two additional patches. [0001-Support-long-address-lists.patch] uses pre blocks to display addresses, and fields that represent arrays of addresses are made scrollable. [0002-Reorder-fields-to-group-similar-styling-together.patch] reorders the fields so fields that use pre blocks are grouped together which IMO looks better.

#22160 (moved) is now a child of this ticket because these patches fix the issue that that ticket addresses.

Curiously the number of exit addresses per relay have been reduced significantly, at the time of writing there are at most 3 exit addresses.

Trac:
Status: needs_revision to needs_review

I've not looked at this yet, but I think I'm going to find that having things grouped by presentation as opposed to content is less than optimal...

(I've closed #22160 (moved) as this is being done here and only affects this bug anyway.)

Sorry, could these patches be rebased against the current master?

Trac:
Status: needs_review to needs_revision

Use more capital letters in summary.

Trac:
Summary: add exit_addresses onionoo field to Add Onionoo's exit_addresses field

Trac:
Keywords: N/A deleted, metrics-2018 added

Trac:
Keywords: metrics-2018 deleted, metrics-2017 added

Moving this into my queue.

Trac:
Status: needs_revision to assigned
Owner: cypherpunks to irl

Trac:
Status: assigned to accepted

Fixed in e565a2ea1952901b95ed93c3536652378493a5d8.

I have not included the presentation patches. If this becomes an issue in the future we can take another look at this.

Trac:
Status: accepted to closed
Resolution: N/A to fixed

closed

mentioned in issue #22160 (moved)