[tor-bugs] #13192 [Tor]: Collect aggregate stats of total hidden service usage vs total exit usage in Tor network

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Dec 28 10:16:40 UTC 2014


#13192: Collect aggregate stats of total hidden service usage vs total exit usage
in Tor network
-----------------------------+---------------------------------
     Reporter:  arma         |      Owner:
         Type:  enhancement  |     Status:  needs_information
     Priority:  normal       |  Milestone:  Tor: 0.2.???
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  SponsorR, tor-relay
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------------------

Comment (by karsten):

 Replying to [comment:42 teor]:
 > Thanks, karsten - but I wasn't at all concerned. I think everyone
 deserves a break at least once a year!

 Indeed, time to take a break and review some maths code. :)

 b823b7aad83489ffbac068eeb96ec0492cd50a36
  - These fixes look trivially correct.  Just the changes file doesn't
 follow the usual format.  Please take a look at the ChangeLog file for
 examples.

 cc8f7ab46378e7520d1003844d59b1bc358a6af0
  - Same remark about the changes file as above.
  - Regarding your last comment in `sample_laplace_distribution()`: you're
 thinking about handling extreme values for b, which is obviously better
 than hoping they're handled correctly.  But the even better way, IMHO, is
 to restrict the interval of acceptable ranges, document that, and assert
 if we receive values outside of that interval.  For b, we can require that
 it's > 0, not Infinity, and not NaN.
  - In that same comment you're talking about converting to INT_MIN or
 INT_MAX.  This conversion doesn't happen here, and it's a conversion to
 INT64_MIN and INT64_MAX.  Maybe remove this comment.
  - In `add_laplace_noise()`, you're handling cases when epsilon is zero.
 IMHO, it's better to assert that this is not permitted, and document that.
 More precisely, delta_f should be > 0, not Infinity, and not NaN, and
 epsilon should be > 0 and <= 1.  But I'd also like to hear asn's opinion
 on this, because he has read at least one research paper more on
 differential privacy than I.
  - In the same function, should there be a `tor_trunc()`, just in case
 different architectures/compilers do different things when you call
 `trunc()`?
  - Some of your tests pass INT64_MAX as `delta_f` to
 `add_laplace_noise()`, but that function expects a double there.  Maybe
 pass some kind of DOUBLE_MAX there.
  - I found at least one duplicate unit test (right after the comment "does
 it play nice with INT64_MAX?").  Maybe take another look if there are more
 duplicates.
  - Rest looks good.

 Thanks!

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


More information about the tor-bugs mailing list