Opened 4 years ago

Closed 3 years ago

#18036 closed defect (not a bug)

OnionOO ignores history age limit

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

Description

In #18035, we modify the updateFallbackDirectories.py script in tor because OnionOO is ignoring the end of the "days ago" range, returning data much older than this limit.

Can this be fixed on the OnionOO side as well?

See https://lists.torproject.org/pipermail/tor-relays/2016-January/008504.html

Child Tickets

Change History (4)

comment:1 Changed 4 years ago by karsten

Can you be more specific which request you're making and how it returns a different response than you would expect?

I don't know if the following is the issue raised here, but if you're expecting Onionoo to return different content for relays or bridges based on the parameters you're giving it, then that's not how Onionoo works. The parameters only determine which relays and bridges are included in the response, they don't change the information provided for each of them. For example, if you ask for an uptime document, that document will contain the entire uptime history of a relay or bridge, regardless of the given first_seen or last_seen parameters. (The fields parameter is perhaps the only exception there, because that one does affect what the returned documents contain.) If this turns out to be the issue you're seeing, I'm afraid we can't fix that, because we're returning pre-generated JSON files for performance reasons (well, except for fields). But what we could do is document this better to avoid confusing the next person writing such a script.

comment:2 Changed 4 years ago by teor

Ah, ok, thanks, that helps me understand.

The part of the fallback directories script the deals with uptimes seems to expect the returned uptimes to only be for the last 120 days, as well as only be for relays seen in the last 120 days. (I didn't write that part of the script, I think it was written by weasel.)

The older uptimes are easy enough to filter out, but it seems like it wasn't clear to me, starlight, or weasel, that filtering was needed.

comment:3 Changed 4 years ago by karsten

Status: newneeds_information

Okay, that makes this a documentation issue then. The protocol specification says under "Parameters": "Each of the methods can be parameterized to select only a subset of relay and/or bridge documents that are currently running or that have been running in the past week." It doesn't say though that parameters affect the relay or bridge document contents. I think I'd rather not want to write more text about what the protocol does not do, because more text means that fewer people will read it. If somebody has a patch that makes this clearer without making the text more complicated, I'll apply that. Changing to needs_information for now. (Thanks!)

comment:4 Changed 3 years ago by karsten

Resolution: not a bug
Status: needs_informationclosed

I'm closing this ticket now, because I don't know how to make the text better. Still happy to accept patches, of course, but I'm trying to reduce the number of open tickets that are not actionable or likely actionable in the near future.

Note: See TracTickets for help on using tickets.