The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-09T09:17:11Zhttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/32Find out why a relay in previous consensuses is not found2024-01-09T09:17:11ZjugaFind out why a relay in previous consensuses is not foundTalking with @gk by IRC we had the case of a relay not being found by margot by nickname that instead appeared in metrics.tpo (does it has 2h delay) and consensus-health.tpo.
It might be the case that the relay just went offline or chan...Talking with @gk by IRC we had the case of a relay not being found by margot by nickname that instead appeared in metrics.tpo (does it has 2h delay) and consensus-health.tpo.
It might be the case that the relay just went offline or changed name and margot couldn't find it cause looking at a more recent live consensus.
I couldn't find the relay either in the local arti storage.jugajugahttps://gitlab.torproject.org/tpo/core/arti/-/issues/890chancell relaycell chanmsg relaymsg, docs, non-orthogonality and/or code dupl...2023-11-13T15:40:31ZIan Jacksoniwj@torproject.orgchancell relaycell chanmsg relaymsg, docs, non-orthogonality and/or code duplicationWe have: `RelayCell`, `RelayMsg`, `ChanCell`, `ChanMsg`, `Any*`, and related traits.
1. There is no documentation which brings together all of the relevant types and contrasts them, and explains how they relate to each other. (The `to...We have: `RelayCell`, `RelayMsg`, `ChanCell`, `ChanMsg`, `Any*`, and related traits.
1. There is no documentation which brings together all of the relevant types and contrasts them, and explains how they relate to each other. (The `tor_cell` crate docs do explain the Tor protocols, but not the Rust types.)
2. Some macros such as `msg_impl_relaymsg` vs `msg_impl_chanmsg` seem to be duplicated (with, following !1236, probably-unwarranted divergence)
I think it would be a good idea to try to provide the overview doc (which exercise will perhaps suggest API changes), and also unify parts of the implementation that could be unified.
See also #763https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41835Review default search engine options2024-03-07T13:46:03ZdonutsReview default search engine optionsMullvad Browser took a start-from-scratch approach and removed all default search options besides DuckDuckGo. While we probably don't want to do the same, I think Tor Browser's search options could still use some housekeeping – e.g.
- S...Mullvad Browser took a start-from-scratch approach and removed all default search options besides DuckDuckGo. While we probably don't want to do the same, I think Tor Browser's search options could still use some housekeeping – e.g.
- Some of the favicons are out of date, inconsistent (e.g. in the case of DuckDuckGo and its corresponding onion site) and pretty crunchy.
- I'm not sure whether "DuckDuckGoOnion" and "BlockchairOnion" are consistent with our naming conventions.
- In some ways, "default" feels like a recommendation. Do we really want to recommend Google, Youtube and Yahoo?
- Does StartPage receive enough usage to warrant being included as a default option?
- The menu could be combined with the onionize switch proposed for about:tor in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41333
Were we to remove a few options we could come up with a user migration plan that adds the currently selected search provider as a custom option.
- [default-search-options](/uploads/200d67018885264361455d2cbca8c040/default-search-options.png)richardrichardhttps://gitlab.torproject.org/tpo/core/arti/-/issues/884Clarify intended time for which a NetDir should be held; make sure code is be...2023-06-12T17:21:29ZNick MathewsonClarify intended time for which a NetDir should be held; make sure code is behaving sensibly.See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228?commit_id=cd133bdc0930d5f120ed95b019ec1388df435b0d#note_2910285 .
Basically, we should _at least_ document that when you get an `Arc<NetDir>` from an ...See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228?commit_id=cd133bdc0930d5f120ed95b019ec1388df435b0d#note_2910285 .
Basically, we should _at least_ document that when you get an `Arc<NetDir>` from an `NetDirProvider`, you shouldn't hold on to it longer than you need to. (The reason being: said `Arc` is pointing to a `Mutex<Arc<NetDir>>` that can get updated with `Arc::get_mut()`, which can clone the `NetDir` if somebody has a reference to it.)
Additionally, we should look through our code and explain why we are holding `NetDir`s for the "right" amount of time, and use this to inform best practices. (For example, this is part of the reason why, when constructing a circuit path, we construct the _entire_ path all at once. It is also part of the reason why `OwnedCircTarget` exists.)
Possibly, we should turn Relay into a type that holds Arc<> rather than a reference. Doing this would alleviate some of our pain, but not all.https://gitlab.torproject.org/tpo/core/tor/-/issues/40809Bring padding machines into sync with Tobias's latest changes2023-06-15T10:31:28ZMike PerryBring padding machines into sync with Tobias's latest changesTobias has added some changes to the padding machines in his latest research: in particular, the padding machine can respond to queue length/congestion signals. I believe there are now also probabilistic transitions (ie https://gitlab.to...Tobias has added some changes to the padding machines in his latest research: in particular, the padding machine can respond to queue length/congestion signals. I believe there are now also probabilistic transitions (ie https://gitlab.torproject.org/tpo/core/tor/-/issues/31636 or https://gitlab.torproject.org/tpo/core/tor/-/issues/31787).
I need to read his latest paper, sync with him, and discuss these things. This will generate new tickets.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41217retire cupani2024-03-26T20:48:47Zanarcatretire cupaniOnce all lagacy Git repositories have been migrated to GitLab (#41215), retire cupani.Once all lagacy Git repositories have been migrated to GitLab (#41215), retire cupani.legacy Git infrastructure retirement (TPA-RFC-36)anarcatanarcat2024-04-24https://gitlab.torproject.org/tpo/core/tor/-/issues/40807Look for the lib64 directory when using a custom OpenSSL directory2023-06-12T16:28:25ZPier Angelo VendrameLook for the lib64 directory when using a custom OpenSSL directoryFor Tor Browser, we build tor in an old Debian container that has a very old OpenSSL.
So, we also compile OpenSSL and use a custom prefix with `--with-openssl-dir=$openssldir`.
From what I understood (by compiling with `make V=1`), it s...For Tor Browser, we build tor in an old Debian container that has a very old OpenSSL.
So, we also compile OpenSSL and use a custom prefix with `--with-openssl-dir=$openssldir`.
From what I understood (by compiling with `make V=1`), it seems to me that tor's build system tries to use `$openssldir/lib` as a library directory (and IIRC, it falls back to `$openssldir` when it doesn't exist).
However, with OpenSSL 3, the default directory has become `$openssldir/lib64` (at least on Linux amd64).
Linking `$openssldir/lib` to `$openssldir/lib64` seems to solve all the various problems.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41819Stop providing our brand.dtd after we update the about dialog2023-09-29T06:40:27ZPier Angelo VendrameStop providing our brand.dtd after we update the about dialogIt isn't used anymore upstream: 1662ea09fa2589c689cc4e4189f6853546fd0685.
We still use it on `aboutDialog.dtd`.
We could move it there, but I think it'd be new strings to translate, so not very good, since we want to go away from legac...It isn't used anymore upstream: 1662ea09fa2589c689cc4e4189f6853546fd0685.
We still use it on `aboutDialog.dtd`.
We could move it there, but I think it'd be new strings to translate, so not very good, since we want to go away from legacy formats anyway.https://gitlab.torproject.org/tpo/core/arti/-/issues/878broken pt config can create a broken state, preventing from bootstaping after...2023-11-14T16:43:41Ztrinity-1686abroken pt config can create a broken state, preventing from bootstaping after fixing the issueWhen trying to connect to a broken bridge (in this case, PT kind not registered), arti store something in its state directory, which causes it to not try to run PTs on subsequent restarts.
How to reproduce:
- run the snowflake example (...When trying to connect to a broken bridge (in this case, PT kind not registered), arti store something in its state directory, which causes it to not try to run PTs on subsequent restarts.
How to reproduce:
- run the snowflake example (not yet merged, in !1216), it works
- comment one bridge line, break the other, for instance change the PT kind from `snowflake` to `snowflak`
- run the example, it fails as expected
- restore the file
- run the example, it fails again. Interestingly, no line from `tor_ptmgr` ever get logged.
<details><summary>shell logs</summary>
```sh
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]> cargo run --example snowflake --features pt-client
Finished dev [unoptimized + debuginfo] target(s) in 0.23s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:22:31.966319Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:31.971166Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:22:32.263816Z INFO tor_ptmgr: Got a request for transport snowflake, which is not currently running. Launching it.
2023-06-07T21:22:32.264050Z INFO tor_ptmgr::ipc: Launching pluggable transport at /sbin/snowflake-pt-client for [PtTransportName("snowflake")]
2023-06-07T21:22:32.268040Z INFO tor_ptmgr::ipc: Transport 'snowflake' uses method PtClientMethod { kind: V5, endpoint: 127.0.0.1:36513 }
2023-06-07T21:22:32.268074Z INFO tor_ptmgr::ipc: PT binary initialisation done
2023-06-07T21:22:32.268150Z INFO tor_ptmgr: Successfully launched PT for snowflake at PtClientMethod { kind: V5, endpoint: 127.0.0.1:36513 }.
2023-06-07T21:22:32.416115Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] offer created
2023-06-07T21:22:32.993817Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] broker rendezvous peer received
2023-06-07T21:22:33.192347Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:33.196673Z INFO tor_dirmgr: Directory is complete. attempt=1
2023-06-07T21:22:33.345261Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] connected
2023-06-07T21:22:34.774159Z INFO tor_guardmgr::guard: We have found that guard [192.x.x.x:80 via snowflake 1z…] is usable.
sending request...
reading response...
HTTP/1.1 200 OK
<redacted for conciseness>
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> vim examples/snowflake.rs # comment one bridge, change to pt kind to `snowflak` on the other
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> cargo run --example snowflake --features pt-client
Compiling arti-client v0.9.1 (/home/trinity/dev/tor/core/arti/crates/arti-client)
warning: unused variable: `bridge_1`
--> crates/arti-client/examples/snowflake.rs:30:9
|
30 | let bridge_1: BridgeConfigBuilder = BRIDGE1_LINE.parse()?;
| ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_bridge_1`
|
= note: `#[warn(unused_variables)]` on by default
warning: `arti-client` (example "snowflake") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 1.68s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:22:44.695698Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:44.696135Z WARN tor_circmgr: Problem launching a timeout testing circuit: error: Unable to select a guard relay: No usable guards. Rejected 2/2 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
2023-06-07T21:22:44.700623Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:22:45.927859Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:45.932017Z INFO tor_dirmgr: Directory is complete. attempt=1
^C⏎
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> vim examples/snowflake.rs # restore the file
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]> cargo run --example snowflake --features pt-client
Compiling arti-client v0.9.1 (/home/trinity/dev/tor/core/arti/crates/arti-client)
Finished dev [unoptimized + debuginfo] target(s) in 2.77s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:23:03.295584Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:23:03.297077Z WARN tor_circmgr: Problem launching a timeout testing circuit: error: Unable to select a guard relay: No usable guards. Rejected 2/2 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
2023-06-07T21:23:03.300749Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:23:04.516865Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:23:04.521279Z INFO tor_dirmgr: Directory is complete. attempt=1
^C⏎
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]>
```
</details>
loosely related to #177Arti: Feature parity with the C implementationNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/5Rewrite Lox handling of new resources2024-02-15T17:38:19ZonyinyangRewrite Lox handling of new resourcesAt present, the Lox distributor handles `new` resources by parsing them into BridgeLines, grouping them into 3 (MAX_BRIDGES_PER_BUCKET) and then placing them into an open invitation bucket. Any additional bridges that don't group into 3 ...At present, the Lox distributor handles `new` resources by parsing them into BridgeLines, grouping them into 3 (MAX_BRIDGES_PER_BUCKET) and then placing them into an open invitation bucket. Any additional bridges that don't group into 3 are stored temporarily in the LoxServerContext until enough bridges to make up a bucket come along. Eventually, this needs to be improved to address several things:
* [ ] Smarter bridge groupings:
* What factors determine whether a set of bridges are grouped into a bucket?
* Should the distributor determine those factors or should rdsys pre-sort bridges into buckets?
* [ ] Decide on an appropriate open invitation to hot spare bucket ratio
* Some proportion of buckets *must* be hot spare buckets so that there are a pool of buckets for users to migrate to
* [ ] Ensure access to open-entry invitations
* Can we prevent sock-puppets from clogging the open-entry pathway?
* Can/should we limit which open-entry bridges are distributed to which users?
* [ ] Determine when a bridge is "blocked"?
* In reality, bridges are blocked by locale which Lox does not consider
* Issue being tracked [here](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035)
* [ ] Improve Lox Parameters for Tor Usecase
* Lox's parameters such as the time to level up, number of invitations distributed, etc. are untested in the real world
* Are there better parameters for Tor's usecase?https://gitlab.torproject.org/tpo/core/tor/-/issues/40806running tor guard/bridge/exit behind layers of nat2023-06-13T20:47:38Zredbearrunning tor guard/bridge/exit behind layers of natThe issue is i can start a node and port is reached by outside but outside ips need uses some intermediate ip to access node. There is some work around ? is possible make something or config on torrc ?The issue is i can start a node and port is reached by outside but outside ips need uses some intermediate ip to access node. There is some work around ? is possible make something or config on torrc ?https://gitlab.torproject.org/tpo/core/tor/-/issues/40802Dir auths say "Failed to find node for hop #2 of our path. Discarding this ci...2024-01-31T23:49:46ZRoger DingledineDir auths say "Failed to find node for hop #2 of our path. Discarding this circuit." every second after boot until new consensusStarting somewhere in Tor 0.4.7, every directory authority now prints thousands of lines of
```
Jun 01 14:51:33.790 [notice] Failed to find node for hop #2 of our path. Discarding this circuit.
```
on startup. It continues until the top ...Starting somewhere in Tor 0.4.7, every directory authority now prints thousands of lines of
```
Jun 01 14:51:33.790 [notice] Failed to find node for hop #2 of our path. Discarding this circuit.
```
on startup. It continues until the top of the hour when
```
Jun 01 14:59:59.942 [notice] Failed to find node for hop #2 of our path. Discarding this circuit.
Jun 01 15:00:00.017 [notice] Time to publish the consensus and discard old votes
Jun 01 15:00:00.162 [notice] Published ns consensus
Jun 01 15:00:00.315 [notice] Published microdesc consensus
```https://gitlab.torproject.org/tpo/core/arti/-/issues/871Use cargo-vet to track our dependencies over time.2023-08-19T18:23:33ZNick MathewsonUse cargo-vet to track our dependencies over time.[Cargo-vet](https://mozilla.github.io/cargo-vet/) is a tool to track which crates have been audited by whom. It'd be neat to use it. We won't be able to audit everything ourselves, but we can use upstream audits from folks at Google, Mo...[Cargo-vet](https://mozilla.github.io/cargo-vet/) is a tool to track which crates have been audited by whom. It'd be neat to use it. We won't be able to audit everything ourselves, but we can use upstream audits from folks at Google, Mozilla, and other sources.https://gitlab.torproject.org/tpo/core/arti/-/issues/869rpc: Add a general-purpose "destroy" method2023-11-15T18:58:35ZNick Mathewsonrpc: Add a general-purpose "destroy" methodThis comes out of discussion on !1200.
It would be neat to have a general purpose "destroy or shutdown this object" method that multiple objects can receive.
Note that this might require some changes in our method implementation design...This comes out of discussion on !1200.
It would be neat to have a general purpose "destroy or shutdown this object" method that multiple objects can receive.
Note that this might require some changes in our method implementation design, so that it can release _one_ strong ID, but leave the others pointing to a shut-down object. This would require that the method implementation receive the specific object ID that it was sent to (rather than `Arc<Object>`),Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/868rpc: Settle on strong/weak ID semantics and their implications for capability...2024-02-24T18:30:20ZNick Mathewsonrpc: Settle on strong/weak ID semantics and their implications for capability designThis stems from a discussion in !1200.
We can't define a sensible "drop" method for a weak ID, because the weak IDs for an object are automatically deduplicated. Thus, if you remove a weak ID for a given circuit, you're actually removi...This stems from a discussion in !1200.
We can't define a sensible "drop" method for a weak ID, because the weak IDs for an object are automatically deduplicated. Thus, if you remove a weak ID for a given circuit, you're actually removing _every_ weak ID for that circuit.
@diziet has additional thoughts about the situation at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1200#note_2905558 .
Here are some alternatives; there may be more.
* **There are no weak IDs.** (This would make some programs hard to write without making sure that the API user manually drops everything, and would make some APIs hard to provide. Probably not a good idea)
* **Weak IDs do not get deduplicated.** (This would probably lead to OOM conditions if an API user does something that gets it a zillion weak IDs for the same object.)
* **You can't drop weak IDs.** (This is the status quo, but it means that any capability represented by a weak ID is undroppable, unless you can trust yourself to "forget" the ID.)
* **Dropping a weak ID drops _every_ weak ID for the same object.** (This leads to nonlocal behavior issues, since IDs can get invalidated by parts of the API user that don't even have the ID.)
* **As above, but this is a different operation from the regular "drop".** (This mitigates the nonlocality problem a little by making it hard to do by accident, but it does make weak-ID-dropping a risky proposition.)
* **Weak IDs are not capabilities.** (This is potentially hard to design. If we assume "every ID is a capability", then writing a secure API is as simple as "don't give out an ID to something the user shouldn't have access to" and "Don't access anything without an ID." But if we say only strong IDs are a capability, it's not clear what weak IDs can even allow you to do; it seems like we might need additional access control in the objects that do have the strong IDs.)
* **Weak IDs exist within named tables.** (@diziet suggested this in the above-linked comment.)
* **Weak IDs are namespaced relative to strong IDs.** (This may be the same as @diziet's design above. It would imply that every weak ID is somehow seen as a facet of something that you have a strong ID for, such that dropping the strong ID will expire all the weak IDs.)Arti: RPC SupportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/867Update in-tree docs to refer to TROVE2023-09-13T17:33:22ZIan Jacksoniwj@torproject.orgUpdate in-tree docs to refer to TROVEAt least our what do we support doc, and perhaps a general readme, should have appropriate link(s) to TROVE.At least our what do we support doc, and perhaps a general readme, should have appropriate link(s) to TROVE.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41787Purple tor buttons use white text in both light and dark theme2023-10-11T21:38:25ZhenryPurple tor buttons use white text in both light and dark themeCurrent both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab....Current both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41608#note_2895231:
> in the figma mockups the "Connect" button uses almost-white text with a light theme, and almost-black text with a dark theme.
>
> In contrast the ".onion available" urlbar button always uses white text, regardless of theme:
>
> ![onion available button in dark mode](https://gitlab.torproject.org/tpo/applications/tor-browser/uploads/dac4112fc2b8aa6d21c65bb76cda4e25/onion-available-dark-mode.png)
And the reply from @donuts
> The two variants are supposed to use `purple-60` (light theme) and `purple-30` (dark theme) for backgrounds, and the normal label color for foregrounds (e.g. page-color, I think?).
>
> For consistency, maybe we should ignore the dark theme variant for now, and we can open a separate issue to fix this everywhere (i.e. torconnect, onion-location, and this instance).henryhenryhttps://gitlab.torproject.org/tpo/network-health/metrics/monitoring-and-alerting/-/issues/27Add fingerprints to notifications about X relays joining the network2024-01-16T13:51:05ZGeorg KoppenAdd fingerprints to notifications about X relays joining the networkWe have notifications for e.g. a number of new relays joining the network in the last X hours, which is good. However, it would be very helpful if the mail contained e.g. the fingerprints of the relays it is talking about. That would mak...We have notifications for e.g. a number of new relays joining the network in the last X hours, which is good. However, it would be very helpful if the mail contained e.g. the fingerprints of the relays it is talking about. That would make it a lot easier to check what's actually going on and to decide on how we should deal with those reports.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/34How to handle keyword-value based fields2024-01-16T13:49:10ZHiroHow to handle keyword-value based fieldsWe have been dealing with key-value based fields on a need-by-basis. This mean that if the field is parsed often the individual fields are stored in their own columns and if it is accessed often enough it is stored as a string. Maybe it ...We have been dealing with key-value based fields on a need-by-basis. This mean that if the field is parsed often the individual fields are stored in their own columns and if it is accessed often enough it is stored as a string. Maybe it made sense to just store it as a string and have some code to write and read it easily.
Said this we should consider if the DB handle betters individual columns or blob of JSON instead.https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/78Enhanced metrics for Onion Service descriptors2024-03-27T21:44:54ZSilvio RhattoEnhanced metrics for Onion Service descriptorsImplement additional metrics for Onion Service descriptors.
That need:
* A better way to parse descriptors would enable many other metrics.
* Some patches sent upstream to Stem.
Some fields that could get measurements:
* From the out...Implement additional metrics for Onion Service descriptors.
That need:
* A better way to parse descriptors would enable many other metrics.
* Some patches sent upstream to Stem.
Some fields that could get measurements:
* From the outer descriptor wrapper:
* [ ] "descriptor-lifetime".
* [ ] "revision-counter".
* From the first layer of encryption:
* [ ] "[caa-critical](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/343-rend-caa.txt)".
* From the second layer of encryption:
* [ ] "single-onion-service".
* [ ] "pow-params": an indirect way to measure DoS for PoW-enabled
services (by measuring the PoW settings in the descriptor),
which depends on tpo/core/tor#40634 to be implemented.
* [ ] "[caa](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/343-rend-caa.txt)".
Other measurements:
* [ ] Metrics for the descriptor and inner layer sizes.Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16