[tor-dev] Proposal draft: Better hidden service stats from Tor relays
karsten at torproject.org
Thu Dec 11 12:42:58 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 10/12/14 15:37, A. Johnson wrote:
>> But I don't see the value of binning the result once more. In a
>> sense, we're already binning signal + noise by cutting off the
>> float part. I don't see what we gain by reducing resolution
>> even more. It seems just unnecessary.
> In principle releasing the number could result in different
> differential-privacy guarantees than releasing the bin. However,
> the way I had in mind to set the Laplace parameters this wouldn’t
> be an issue, because the Laplace distributions themselves would
> satisfy the desired differential privacy guarantee (and not just
> the resulting distribution on bins).
> So I guess this could be viewed as a post-processing step that is
> useful for clarity rather than privacy: namely, that the output
> should be interpreted as a range. But we could leave this to the
> data consumer to apply without a privacy issue.
Can you be more explicit with regard to privacy guarantees of the
obfuscation schema that is currently implemented: 1) binning, 2) add
Laplace noise, 3) no second binning.
If you think 3) should be changed, can you explain why that leads to
better privacy guarantees?
> Also, I believe that the parameters we had discussed should
> change. To see why, observe that the Laplace distributions for two
> adjacent values that cross a bin barrier are now very far apart
> after being recentered within the appropriate bins. Thus, \delta_f
> should increase if it is smaller than the maximum number of bins
> that can be crossed within that \delta_f multiplied by the bin
> size. With our previous numbers, the new \delta_f for rendezvous
> cell counts doesn’t change (still 2048), but the new \delta_f for
> HS descriptors counts is 8.
The current parameters are:
* delta_f = 2048
* epsilon = 0.3
* bin_size = 1024
* delta_f = 1
* epsilon = 0.3
* bin_size = 8
I can see how the Laplace distribution doesn't add much noise to the
second case. And your suggestion is to change the second delta_f to 8?
All the best,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
More information about the tor-dev