[tor-bugs] #9871 [Onionoo]: ExoneraTor by CIDR block

[Tor Bug Tracker & Wiki]

#9871: ExoneraTor by CIDR block
-----------------------------+----------------------
     Reporter:  grarpamp     |      Owner:  wfn
         Type:  enhancement  |     Status:  assigned
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------

Comment (by wfn):

 Replying to [comment:1 karsten]:
 > Another reason against extending ExoneraTor is that Kostas is working on
 a replacement that is based on Onionoo.  I'm reassigning this ticket to
 him and to the Onionoo component.  Kostas, any chance that you can support
 searches by CIDR block in your Onionoo extension?  Feel free to put this
 on the long-term TODO list, or to close it if you see no chance to ever
 building this.

 Indeed, [https://github.com/wfn/torsearch torsearch] already does
 [https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md
 arbitrary substring searches] for all the fields supported, including
 (IPv4, for now) network addresses. In a way, this kind of substring search
 provides the functionality in question, but not by one being able to query
 by netblock explicitly.

 [http://ts.mkj.lt:5555/details?search=200. GET details?search=200.] =>
 return all relays with IPv4 matching 200.*, i.e. 200.0.0.0/8 in CIDR
 notation.

 Being able to explicitly specify the exact netblock one is interested
 about would be nice, of course. For example,
 [http://ts.mkj.lt:5555/details?search=200.1 GET details?search=200.1] =>
 returns relays with IPv4 matching 200.1*, including 200.100.* and so on,
 not 200.1'''.'''* (for which the search query would be
 [http://ts.mkj.lt:5555/details?search=200.1. GET details?search=200.1.];
 this is good, but a more rigorous way to search by netblock would be nice
 indeed.

 In torsearch (not metrics-web), we're currently matching against a simple
 varying(15) address field to be able to do this (we can afford this
 because we're using an
 [https://github.com/wfn/torsearch/blob/master/torsearch/models.py#L207-L223
 intermediary table] which is much smaller than everything else (so we can
 do things just like this.))

 Replying to [ticket:9871 grarpamp]:
 > The ExoneraTor should probably have a way to query by netblock.
 > ie: w.x.y.z/19 , IPv6/n
 >
 > At least postgres has a netblock/n function if that's the backend.
 > Meanwhile user could download and parse archived data.
 > There seems no exonerator component, placed under metrics to start.

 Question is, how usual of a use case would this be?

 Does the current torsearch functionality kinda-satisfy those use cases in
 question?

 (Also note that time(exact address search) << time(arbitrary address
 substring search); we optimize for and focus on the general use case,
 which in this case is: searching for a particular exact network address.)

 Can't say searching by netblock wouldn't be a cool thing to do!

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9871#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online