Opened 5 months ago

Last modified 6 weeks ago

#22147 needs_revision enhancement

add exit_addresses onionoo field

Reported by: cypherpunks Owned by: cypherpunks
Priority: Medium Milestone:
Component: Metrics/Atlas Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Attachments (3)

0001-Add-a-field-for-the-exit-addresses-of-relays.patch (1.8 KB) - added by cypherpunks 5 months ago.
0001-Support-long-address-lists.patch (2.9 KB) - added by cypherpunks 4 months ago.
0002-Reorder-fields-to-group-similar-styling-together.patch (4.4 KB) - added by cypherpunks 4 months ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 5 months ago by cypherpunks

Summary: add exit_addresses onionoo field to at atlasadd exit_addresses onionoo field

comment:2 in reply to:  description ; Changed 5 months ago by cypherpunks

Owner: changed from irl to cypherpunks
Status: newaccepted

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.

comment:3 in reply to:  2 ; Changed 5 months ago by 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. 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.

comment:4 in reply to:  3 ; Changed 5 months ago by cypherpunks

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?

comment:5 in reply to:  2 Changed 5 months ago by nusenu

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.

comment:6 in reply to:  4 Changed 5 months ago by nusenu

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

comment:7 Changed 5 months ago by 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.

comment:8 in reply to:  7 Changed 5 months ago by cypherpunks

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.

comment:9 Changed 5 months ago by nusenu

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

comment:10 in reply to:  9 Changed 5 months ago by cypherpunks

Status: acceptedneeds_review

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 for improving the address list style because some relays have more than two exit addresses which leads to styling issues.

comment:11 Changed 5 months ago by 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.

Last edited 5 months ago by nusenu (previous) (diff)

comment:12 in reply to:  11 Changed 5 months ago by cypherpunks

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?

comment:14 Changed 4 months ago by irl

Status: needs_reviewneeds_revision

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

Changed 4 months ago by cypherpunks

comment:15 Changed 4 months ago by cypherpunks

Status: needs_revisionneeds_review

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

comment:16 Changed 4 months ago by irl

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 as this is being done here and only affects this bug anyway.)

comment:17 Changed 6 weeks ago by irl

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

comment:18 Changed 6 weeks ago by irl

Status: needs_reviewneeds_revision
Note: See TracTickets for help on using tickets.