[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