Opened 4 months ago

Closed 6 weeks ago

#22307 closed defect (fixed)

Atlas shows duplicates shown when a bridge changes to a publicly listed node.

Reported by: entry Owned by: metrics-team
Priority: Very Low Milestone:
Component: Metrics/Atlas Version:
Severity: Trivial Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If a node is running as a bridge with PublishServiceDescriptor bridge then changes to a regular node without resetting it's fingerprint, that node will have 2 identical entries forever.

I have reproduced here: https://atlas.torproject.org/#search/30AFA68C0F9B30C213F19B6CE57F7D8CA4B77A25

Child Tickets

Attachments (1)

0001-Use-fingerprint-searches-for-the-detail-documents.patch (1.9 KB) - added by cypherpunks 4 months ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 4 months ago by entry

Summary: Atlas showz duplicates shown when a bridge changes to a publicly listed node.Atlas shows duplicates shown when a bridge changes to a publicly listed node.

comment:2 Changed 4 months ago by arma

Seems like that might be a feature? Since there are the stats about it when it was a bridge, and the stats about it when it was a relay, and we would want onionoo to track each of them.

comment:3 Changed 4 months ago by arma

Oh -- on the example atlas page, both entries are listed as 'relay'. That definitely sounds like a bug.

comment:4 Changed 4 months ago by cypherpunks

This is caused by js/models/relay.js#n136 which processes only the first relay or bridge (with a preference for the relay in the case of both). In this case Atlas requests the summary document which returns the relay and bridge. For both the detail document is requested which returns the relay and the bridge. The response for the bridge contains both the relay and the bridge where Atlas takes preference for the relay details and ignores the bridge details leading to duplicate results.

comment:6 Changed 4 months ago by cypherpunks

Status: newneeds_review

comment:7 Changed 4 months ago by cypherpunks

Status: needs_reviewneeds_revision

The patch fixes the issue on the search page but the results link to the incorrect details page. Please ignore the patch for now.

comment:8 Changed 4 months ago by cypherpunks

Component: MetricsMetrics/Atlas
Keywords: atlas removed

This is an issue with Atlas which incorrectly duplicates search results so I'm changing the component.

comment:9 in reply to:  7 Changed 4 months ago by cypherpunks

Replying to cypherpunks:

The patch fixes the issue on the search page but the results link to the incorrect details page. Please ignore the patch for now.

The results do not link to the incorrect details pages. It is Atlas always using hashed fingerprints for Onionoo requests which does not work with the fingerprint parameter. Atlas hashes the given fingerprints to prevent bridge fingerprints from being leaked but in this case it prevents searches for exact matches.

I'm unsure about how to continue now. On one hand we want exact matches (especially for the details page because it presents information about a specific relay or bridge) which means we should pass on the exact fingerprint the user gives us. On the other hand we want to protect the user from leaking bridge fingerprints which forces us to use the lookup parameter which can return multiple results with no good way to select one of the results.

Thinking about it some more i believe the solution is to rehash the fingerprints Onionoo returns in the summary response. This will turn the details requests using the lookup parameter into

https://onionoo.torproject.org/details?lookup=D752CBAB72003DE7774D032186A47ACE09CD27C1 for the relay.
https://onionoo.torproject.org/details?lookup=BD2734E77BEBA086B9718091B6D11A75422E4770 for the bridge.

The first request returns both relay and bridge where Atlas will only parse the relay as explained in comment:4. The second request returns only the bridge so Atlas can and will only parse the bridge.

This solution was discussed previously in #21615 in a different context but was closed as not a bug. Now it turns out it is a bug so i'll reopen and make this ticket the parent.

comment:10 Changed 6 weeks ago by irl

Resolution: fixed
Status: needs_revisionclosed

I believe this was fixed in 40426f09f37ff84f93f20f156ab638ce27ff977a to be deployed shortly. Please reopen if this is still a problem, and provide some example fingerprints to test.

Note: See TracTickets for help on using tickets.