The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-08-23T15:17:07Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24526Make it clear that multi-relay operators are expected to set a working Contac...2021-08-23T15:17:07ZcypherpunksMake it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamilyAs per discussion with David on bad-relays@ I'm opening this ticket as he requested.
We want to make it clear to tor relay operators that setting a proper ContactInfo (working email address) and MyFamily (fully mutual configuration) is ...As per discussion with David on bad-relays@ I'm opening this ticket as he requested.
We want to make it clear to tor relay operators that setting a proper ContactInfo (working email address) and MyFamily (fully mutual configuration) is strongly encouraged (required?) for relay operators that run more than 3 (?) tor instances, relays showing up without such configuration likely raise a red flag and might get rejected from the network.
places to update:
* manual page:
* ContactInfo
* MyFamily
* relay documentation (legacy/trac#24497)Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24518Remove the --quiet from our cargo build invocation2020-06-27T13:54:46ZNick MathewsonRemove the --quiet from our cargo build invocationIt seems to suppress some errors, which is Not What We Want.It seems to suppress some errors, which is Not What We Want.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24511TorBrowser 7.5 a8 takes multiple minutes to connect2020-06-27T13:54:47ZTracTorBrowser 7.5 a8 takes multiple minutes to connectTorBrowser 7.5 a8 takes multiple minutes to connect, here is thew log.
```
Dec 03 21:12:46.198 [notice] Tor 0.3.2.4-alpha running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Dec 03 ...TorBrowser 7.5 a8 takes multiple minutes to connect, here is thew log.
```
Dec 03 21:12:46.198 [notice] Tor 0.3.2.4-alpha running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Dec 03 21:12:46.199 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 03 21:12:46.199 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 03 21:12:46.199 [notice] Read configuration file "/Users/USER/Desktop/tor alpha/TorBrowser.app/Contents/Resources/TorBrowser/Tor/torrc-defaults".
Dec 03 21:12:46.199 [notice] Read configuration file "/Users/USER/Desktop/tor alpha/TorBrowser-Data/Tor/torrc".
Dec 03 21:12:46.205 [notice] Scheduler type KISTLite has been enabled.
Dec 03 21:12:46.205 [notice] Opening Socks listener on 127.0.0.1:9150
Dec 03 21:12:46.205 [notice] Opening Control listener on 127.0.0.1:9151
Dec 03 21:12:46.000 [notice] Parsing GEOIP IPv4 file /Users/USER/Desktop/tor alpha/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip.
Dec 03 21:12:46.000 [notice] Parsing GEOIP IPv6 file /Users/USER/Desktop/tor alpha/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip6.
Dec 03 21:12:46.000 [notice] Bootstrapped 0%: Starting
Dec 03 21:12:47.000 [notice] Starting with guard context "default"
Dec 03 21:12:47.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Dec 03 21:12:47.000 [notice] New control connection opened from 127.0.0.1.
Dec 03 21:12:47.000 [notice] New control connection opened from 127.0.0.1.
1512364367600 addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232} WARN Loading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}': Reading manifest: Error processing permissions.1: Unknown permission "privacy"
1512364367600 addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232} WARN Loading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}': Reading manifest: Error processing permissions.4: Unknown permission "unlimitedStorage"
1512364367700 addons.webextension.https-everywhere-eff@eff.org WARN Loading extension 'https-everywhere-eff@eff.org': Reading manifest: Error processing devtools_page: An unexpected property was found in the WebExtension manifest.
1512364367700 addons.webextension.https-everywhere-eff@eff.org WARN Please specify whether you want browser_style or not in your browser_action options.
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
Dec 03 21:14:05.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Dec 03 21:14:06.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Dec 03 21:14:06.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 03 21:14:06.000 [notice] Bootstrapped 100%: Done
Dec 03 21:14:08.000 [notice] New control connection opened from 127.0.0.1.
Dec 03 21:14:08.000 [notice] New control connection opened from 127.0.0.1.
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function
2017-12-04 05:14:09.868 plugin-container[85038:1180266] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x8e3b, name = 'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.
```
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24510Make AccountingStart begin at the same time each period2020-06-27T13:54:47ZTracMake AccountingStart begin at the same time each periodMy ISP provides me with unlimited bandwidth for a certain time window each day. I would like to use AccountingStart day to start my relay at the beginning of that window. However, from the FAQ:
>Note that your relay won't wake up exactl...My ISP provides me with unlimited bandwidth for a certain time window each day. I would like to use AccountingStart day to start my relay at the beginning of that window. However, from the FAQ:
>Note that your relay won't wake up exactly at the beginning of each accounting period. It will keep track of how quickly it used its quota in the last period, and choose a random point in the new interval to wake up.
How can I configure my relay to ignore this feature and begin at the specified time each day?
**Trac**:
**Username**: andrewtothTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24509circuit_can_use_tap() should only allow TAP for v2 onion services2021-08-23T15:17:07Zteorcircuit_can_use_tap() should only allow TAP for v2 onion servicescircuit_can_use_tap() checks the circuit purpose to make sure that it's an onion service circuit. But it should also check that the circuit is for a v2 onion service before allowing TAP.
There should be a field in the circuit or extend_...circuit_can_use_tap() checks the circuit purpose to make sure that it's an onion service circuit. But it should also check that the circuit is for a v2 onion service before allowing TAP.
There should be a field in the circuit or extend_info that we can use for this.
This is security-low, because it's a defence in depth mechanism that doesn't provide as much defence as we thought.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24502scheduler_release_channel: Non-fatal assertion2020-06-27T13:54:47Ztoralfscheduler_release_channel: Non-fatal assertionGot this at a stable hardened Gentoo Linux exit :
```
Dec 02 18:20:17.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)
... <repeating>
Dec 03 01:03:59.000 [warn] Tried to establish r...Got this at a stable hardened Gentoo Linux exit :
```
Dec 02 18:20:17.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)
... <repeating>
Dec 03 01:03:59.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)
Dec 03 01:04:10.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)
Dec 03 01:07:47.000 [warn] tor_bug_occurred_(): Bug: src/or/scheduler.c:631: scheduler_release_channel: Non-fatal assertion !(smartlist_pos(channels_pending, chan) == -1) failed. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
```Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24501When we hit MaxMemInQueues, make the log message more quantitative2020-06-27T13:54:47ZRoger DingledineWhen we hit MaxMemInQueues, make the log message more quantitativeA relay operator on #tor shared these log lines, on a fast exit relay running with 1GByte of memory (so maxmeminqueues is 768MBytes):
```
Nov 30 03:13:52.000 [notice] We're low on memory. Killing circuits with over-long queues. (This be...A relay operator on #tor shared these log lines, on a fast exit relay running with 1GByte of memory (so maxmeminqueues is 768MBytes):
```
Nov 30 03:13:52.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 30 03:13:52.000 [notice] Removed 118288 bytes by killing 124 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 30 03:13:52.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 30 03:13:52.000 [notice] Removed 25940496 bytes by killing 125 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 30 03:13:53.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 30 03:13:53.000 [notice] Removed 528 bytes by killing 1 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 30 03:13:53.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 30 03:13:53.000 [notice] Removed 528 bytes by killing 2 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 30 03:13:54.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 30 03:13:54.000 [notice] Removed 528 bytes by killing 1 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
Nov 30 03:13:54.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Nov 30 03:13:54.000 [notice] Removed 528 bytes by killing 2 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections.
```
I notice in cell_queues_check_size() that we sum up four things to compute alloc:
```
size_t alloc = cell_queues_get_total_allocation();
alloc += buf_get_total_allocation();
alloc += tor_compress_get_total_allocation();
const size_t rend_cache_total = rend_cache_get_total_allocation();
alloc += rend_cache_total;
```
For operators who are debugging their memory use, and for us poor people trying to help diagnose, it would seem smart for us to expose these four numbers when we say "We're low on memory".
(I thought about this idea in particular because of the tor_compress_get_total_allocation() call and legacy/trac#24368.)Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24500Confusing log message "Can't get entropy from getrandom()"2020-06-27T13:54:47ZRoger DingledineConfusing log message "Can't get entropy from getrandom()"A relay operator on #tor shared these log lines:
```
Dec 01 16:33:00.000 [notice] Tor 0.3.1.8 (git-868c1b2b1eb7225a) opening log file.
Dec 01 16:33:00.515 [warn] Can't get entropy from getrandom().
Dec 01 16:33:00.534 [notice] Tor 0.3.1....A relay operator on #tor shared these log lines:
```
Dec 01 16:33:00.000 [notice] Tor 0.3.1.8 (git-868c1b2b1eb7225a) opening log file.
Dec 01 16:33:00.515 [warn] Can't get entropy from getrandom().
Dec 01 16:33:00.534 [notice] Tor 0.3.1.8 (git-868c1b2b1eb7225a) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1.0alpha[...]
```
The middle line is confusing -- why can't we get the entropy from it? Does that mean Tor has failed at something important? What should the relay operator do?
If the relay operator shouldn't do anything, because it's fine, this should be a notice or less. If the relay operator ought to do something, because it's not fine, then we should suggest what to do and/or what the problem is with doing nothing.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24498add configurables for eventdns settings2022-06-22T15:07:57ZDhalgrenadd configurables for eventdns settingsScenarios exist where relay operators may wish to tune libevent evdns.c (eventdns) for specific exit relay requirements. For example ideal values on a high-performance exit where a local instance of Unbound is utilized might be attempts...Scenarios exist where relay operators may wish to tune libevent evdns.c (eventdns) for specific exit relay requirements. For example ideal values on a high-performance exit where a local instance of Unbound is utilized might be attempts=1 timeout=15, max-inflight=16384, but these settings are inappropriate when bind9/named or non-local Unbound are employed.
Target settings:
max-inflight
max-timeouts
timeout
attempts
Settings already configurable:
randomize-case
Other evdns.c settings exist that are not set in src/or/dns.c and it seems reasonable to omit them here as these can be adjusted via resolv.conf. The settings targeted here are under the control of the Tor daemon such that resolv.conf "options" have no effect.
Predecessor tickets: legacy/trac#18580 legacy/trac#21394
I am willing to contribute a patch for this and unless I am advised otherwise will prepare and submit one in the next two or three weeks.
A behavior I'm inclined to implement is to have the value -1 signify that dns.c should not touch the settings, permitting resolv.conf "options" to control.https://gitlab.torproject.org/tpo/core/tor/-/issues/24490Stop setting bridges running in networkstatus_getinfo_by_purpose()2021-09-16T14:31:40ZteorStop setting bridges running in networkstatus_getinfo_by_purpose()A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0...A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0.2.0.13-alpha.Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24489Add some consts to networkstatus_getinfo_by_purpose()2020-06-27T13:54:48ZteorAdd some consts to networkstatus_getinfo_by_purpose()We shouldn't modify any of the data structures passed to networkstatus_getinfo_by_purpose(). But the current design modifies the running flag in the GETINFO.
The patch I'm about to post makes sure we don't accidentally modify any more o...We shouldn't modify any of the data structures passed to networkstatus_getinfo_by_purpose(). But the current design modifies the running flag in the GETINFO.
The patch I'm about to post makes sure we don't accidentally modify any more of the data structures.
Thanks to komlo - the patch was her idea, and she helped create it.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24488Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses2020-06-27T13:54:48ZteorMake set_routerstatus_from_routerinfo() set IPv6 unspecified addressesset_routerstatus_from_routerinfo() currently sets ipv6_orport to all zeroes. But it should be set to the unspecified IPv6 address.
This is unlikely to cause any bugs in previous Tor versions, but we should fix this for correctness.
Thi...set_routerstatus_from_routerinfo() currently sets ipv6_orport to all zeroes. But it should be set to the unspecified IPv6 address.
This is unlikely to cause any bugs in previous Tor versions, but we should fix this for correctness.
This is a bug on commit 6d99c51 in 0.2.4.1-alpha.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24487Reverse path selection (choose outer hops first)2020-07-28T16:10:00ZMike PerryReverse path selection (choose outer hops first)Because Tor's path selection chooses inner nodes first, and then excludes those nodes from being used in outer hops, over many circuits, outer hops get information about the choice of inner hops/guards.
We need to reverse the selection ...Because Tor's path selection chooses inner nodes first, and then excludes those nodes from being used in outer hops, over many circuits, outer hops get information about the choice of inner hops/guards.
We need to reverse the selection of nodes in the loop circuit_establish_circuit() in order to fix this.
This isn't as bad as it might otherwise be, because the last hop already is chosen first in that function. So it is a little tricky to take advantage of this info leak.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24486Mark all bridges as up on application activity2020-06-27T13:54:48ZteorMark all bridges as up on application activityIf circuit_get_open_circ_or_launch() or its callers don't already mark all bridges as up, we should make them do so.
A good way to do this is to:
* modify the bridge state so we're using the bootstrapping schedule, then
* reset the down...If circuit_get_open_circ_or_launch() or its callers don't already mark all bridges as up, we should make them do so.
A good way to do this is to:
* modify the bridge state so we're using the bootstrapping schedule, then
* reset the download statuses on all bridges, and
* reset the guard state on all the bridges (?).Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24484free(NULL) always works (nowadays) so stop acting like it might not2020-06-27T13:54:48ZTaylor Yufree(NULL) always works (nowadays) so stop acting like it might notsrc/common/util.h has the following text in a comment:
```
* Unlike the free() function, tor_free() will still work on NULL pointers,
* and it sets the pointer value to NULL after freeing it.
```
`free(NULL)` has been required to be a...src/common/util.h has the following text in a comment:
```
* Unlike the free() function, tor_free() will still work on NULL pointers,
* and it sets the pointer value to NULL after freeing it.
```
`free(NULL)` has been required to be a no-op since C89 at least. Some pre-ANSI platforms might have had a libc `free()` that didn't allow a null pointer, but we mostly don't care about those.
We should stop propagating this common misconception that `free(NULL)` might undefined on modern platforms. We should remove that text from the comment and remove the conditional from the implementation.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24483Make bridges work when the authorities are blocked2022-06-20T10:12:39ZteorMake bridges work when the authorities are blockedBridges should be able to:
* bootstrap using fallbacks
* find and connect to enough relays to avoid failing too many client paths
If bridges used bridge guards (#7144), they would work even if most relays were blocked.
This is similar ...Bridges should be able to:
* bootstrap using fallbacks
* find and connect to enough relays to avoid failing too many client paths
If bridges used bridge guards (#7144), they would work even if most relays were blocked.
This is similar to IPv6-only bridges (#23824).https://gitlab.torproject.org/tpo/core/tor/-/issues/24482Upload all stable binaries to torproject debian repository2020-06-27T13:54:48ZTracUpload all stable binaries to torproject debian repositoryCurrently only the latest stable version is included in torproject repo.
Example: https://deb.torproject.org/torproject.org/dists/jessie/main/binary-amd64/Packages has the latest 0.3.1.x series.
It would be helpful to be able to apt-pi...Currently only the latest stable version is included in torproject repo.
Example: https://deb.torproject.org/torproject.org/dists/jessie/main/binary-amd64/Packages has the latest 0.3.1.x series.
It would be helpful to be able to apt-pin system tor to a particular major version (ie 0.2.9.x) and receive security updates while testing compatibility with the next major version. At the moment, updates to 0.2.9.x must be built and distributed by a third-party even though 0.2.9.x is an LTS release.
**Trac**:
**Username**: entr0pyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24480Signed/unsigned mismatch2020-06-27T13:54:49ZLinus Nordberglinus@torproject.orgSigned/unsigned mismatchrendservice.[ch] are mixing signed and unsigned types for struct rend_intro_cell_s member ciphertext_len.rendservice.[ch] are mixing signed and unsigned types for struct rend_intro_cell_s member ciphertext_len.https://gitlab.torproject.org/tpo/core/tor/-/issues/24469Cannibalizing a circuit should check that first hop is in our guard state2020-06-27T13:54:49ZDavid Gouletdgoulet@torproject.orgCannibalizing a circuit should check that first hop is in our guard stateI noticed this on my v3 hidden service info logs which happened on Nov 22nd:
```
Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last hop ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open) $77159B89F...I noticed this on my v3 hidden service info logs which happened on Nov 22nd:
```
Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last hop ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open) $77159B89F39708B27CAC528FF32DD786569A11A5(open) $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open) $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell(): circuit_send_next_onion_skin() failed.
Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed. Closing.
```
So that circuit above has a Guard (`175921396C7C426309AB03775A9930B6F611F794`) that was removed a minute or so before:
```
Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus(): Removing sampled guard lovejoy ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days ago, and confirmed over 60 days ago.
```
Turns out that the circuit was cannibalized but tor made it failed because I assume our guard state wasn't available for that circuit which ultimately triggered those warnings. asn informed me that it is important that the circuit with old guard(s) stay alive for a while to help mitigate Guard discovery attacks.
Bottom line, I think our cannibalized function should exclude any circuit that doesn't match our guard state. In the meantime, those warnings will appear in the logs.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24468Measure HSDir usage to guide parameter choices2022-06-17T18:35:31ZteorMeasure HSDir usage to guide parameter choicesSplit off legacy/trac#24425:
Replying to [ticket:24425#comment:5 asn]:
> Replying to [ticket:24425#comment:4 teor]:
> > If you write down a list of exactly what you want to know, we can probably collect some stats on ~18 HSDirs using Pr...Split off legacy/trac#24425:
Replying to [ticket:24425#comment:5 asn]:
> Replying to [ticket:24425#comment:4 teor]:
> > If you write down a list of exactly what you want to know, we can probably collect some stats on ~18 HSDirs using PrivCount.
> ...
> here are some basic ideas:
>
> - How many v2/v3/both descs per HSDir?
How is this different to "rate of incoming"?
If you mean "cached right now", then I'd need a timeframe so I could design an event. I could do this in December or January.
> - How much total RAM do all v2/v3/both descs occupy on your hsdirs? (max,min,avg,mean over your 18 hsdirs)
I think we have some of the data, but I'd need a list of the objects that contribute to RAM usage. Do you just want descriptors, or is there a replay cache? I could do this in December or January.
> - Size variance of v2/v3 descs? (max,min,avg,mean)
Already implemented as a histogram, needs defined bin sizes.
> - What's the rate of incoming v2/v3/both descs?
Already implemented, needs a time period.
> - How many failed requests for HS descriptors over time? (percentage over total requests?)
I'm going to implement this in December.
> These are just the obvious stats that I came up with. We can come up with more stuff as we see some results and understand the space better.
>
> Let me know if you need help in turning the above sentences into methodologies.
>
> > We will also need an estimate of how much 1 client / service would contribute to each statistic in 10 minutes.
> >
>
> Is that to figure out the noise for differential privacy? Let's try to come up with the final stats list and then we can figure this out.
Yes, that's fine. They only need to be rough estimates.