tor-dev

tor-dev@lists.torproject.org

3580 discussions

[tor-project] Reminder: mailman 3 upgrade imminent (TPA-RFC-71)
by Antoine Beaupré 29 Oct '24

29 Oct '24

Hi, As mentioned in early October, we're in the process of upgrading our main mail server, which includes upgrading to the shiny new Mailman 3 platform. We have, right now, a prototype mailman 3 server available at: https://lists-01.torproject.org/ It's hidden behind the usual "trivial" authentication (ask us on IRC if you don't remember what it is), but should otherwise work normally. I'm going to start by migrating the TPA mailing list and we'll be testing this for a couple of days, but, next week, I'll start migrating the other mailing lists (including this one!). If people want to jump in front of that train early and be part of the beta testers, then by all means I'm happy to have your mailing list be part of the early adopters. Be warned that Mailman 3 is a significant upgrade from Mailman 2. There are some great things (like unified authentication), and some less great things (like a more complex design and "shinier" web interface that might not be everyone's taste). As a reminder, we're doing this upgrade a little rushed because the main mail server is now unsupported for security upgrades. See the details of the proposal here: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-71-emerge… ... with the milestone tracking actual work issues in: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/16 (Sorry for cross-posting this, but this seems like it warrants wider distribution. As a rule of thumb, I selected mailing lists with public archives that had posts in October 2024, removing duplicates like anti-censorship-team and -alerts. I also suspect many of those mailing lists will refuse my message because I'm not subscribed, but I will have tried. :)) Phew! a. -- Antoine Beaupré torproject.org system administration _______________________________________________ tor-project mailing list tor-project(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

1 0

Sharing Circuits Between Onion Servers and Clients
by stifle_savage042＠silomails.com 26 Oct '24

26 Oct '24

Hi all, I want to promote some recent work of mine in the hope that someone here will find it interesting or useful. In my most concise language, it is a "decentralized, asynchronous entropy generator protocol." I've made a somewhat complete demo implementation so far. Here's the repository: https://github.com/devnetsec/rand-num-consensus. The integrity of the entropy can only be compromised if all nodes in the ring are malicious and coinciding. Currently, a Tor client cannot anonymously connect to an onion service by directly contacting the rendezvous point, because that relay could have been chosen maliciously by the onion server. I wager that a scheme like this could enable onion servers and clients to share the same circuit. Both parties would have a guarantee that their relays were chosen randomly. The most similar solution I could find to this was in the TorCoin paper, but it appears to require a more complicated zero-knowledge proof. If there is serious interest in this, I'd be willing to write a proposal draft. Besides implementation difficulty, is there any outstanding flaw in this idea? Best Regards, Dylan Downey [devnetsec]

4 6

Proposal: Handling Complex DNS Traffic for VPN usage in Tor
by Alexander Færøy 21 Oct '24

21 Oct '24

Hello! Micah and I worked on this as part of the P101 work for the VPN. Some of the work that Q is looking into as part of its involvement with the Onion Services Working Group may impact some of these items. Cheers, Alex --- snip --- ``` Filename: XXX-complex-dns-traffic-for-vpn.md Title: Handling Complex DNS Traffic for VPN usage in Tor Authors: Alexander Færøy and Micah Anderson Created: 2024-05-22 Status: Open ``` [[_TOC_]] # Introduction ## Background As part of our work building a prototype for a VPN client that uses the Tor network, we have investigated the need for more modern DNS handling within the Tor network. Presently, Tor exit nodes support hostname resolution and reverse DNS lookups for both IPv4 and IPv6 addresses. Reverse DNS queries are handled by sending a `RELAY_RESOLVE` cell containing an `in-addr.arpa` hostname, with successful responses returning a hostname in the reply cell. Initially, a broader set of features was considered. However, with the introduction of proposal #348 (UDP Application Support in Tor), we have been able to conduct more direct experiments with the required DNS types on the Android platform, utilizing both TCP and UDP resolvers. ## Objective This proposal aims to expand Tor's DNS resolution capabilities by supporting a broader range of DNS request types. Additionally, we will examine the potential impacts of this enhancement on various aspects of the Tor network. ## Audience This proposal is largely designed for users who interact with Tor via the `DNSPort` or through Onionmasq's virtual DNS proxy. In this context, the additional round-trip time for DNS requests and responses is not a significant concern, as it is an expected characteristic of the VPN environment. ## Compatibility Considerations A key requirement of this proposal is to maintain compatibility with common DNS debugging tools such as `dig` and `drill`. Users should be able to continue using these tools to troubleshoot the DNS layer in Tor, whether they're connecting through Tor's `DNSPort` or Onionmasq's virtual VPN DNS server. # New DNS Records This section outlines the additional DNS record types we propose to incorporate into the Tor protocol's DNS layer. Implementing these changes will require updates to the "Remote hostname lookup" section (6.4) of the `tor-spec.txt` document. Specifically, the new types need to be added in addition to the response format. It's important to note that until fragmented cells are supported in C Tor, responses may be truncated due to Tor's cell size limitations. ## HTTPS and SVCB Records In RFC 9460, the IETF defines the SVCB and HTTPS DNS resource records (RR). These records are important in the VPN context to allow web application authors to both provide alternative ports to connect to for HTTP resources, but more importantly, it can be used together with modern HTTP implementation APIs to send pre-flight requests to determine if an end-point supports HTTP/3 (HTTP-over-Quic/UDP) as an alternative to HTTP-over-TCP. This is needed for additional usage of the UDP feature defined in proposal #348. Although the wire format is defined in RFC 9460 section 2.2, Tor does not need to parse the wire format; it should simply propagate the response payload to the client. Tor is currently limited to the 509 bytes per cell, which may be insufficient for complex payloads. Until fragmented cells are supported network-wide, Tor SHOULD trim over-sized payloads to fit within the 509-bit limit. # Security Implications DNS represents a potential attack vector for adversaries seeking to cause harm to the Tor network. As we expand DNS capabilities, we must carefully consider and mitigate associated security risks. ## Denial of Service (DoS) Attacks A major risk involving DNS is Denial of Service attacks. In particular, amplification attacks are a powerful way where an adversary with relatively little effort and request size can cause an exit node to be flooded with significantly larger response sizes from its DNS provider, thus blocking its uplink with DNS responses instead of more useful traffic. While Tor's relatively conservative support of the DNS protocol has mitigated this risk, past DoS attacks have targeted exit nodes with flooding DNS requests. ## Amplification Attacks Because we are adding support for new types where the request-to-response ratio is different from the currently supported types (A, AAAA, and PTR), there is a potential for attackers to exploit these new record types to amplify their attacks more effectively. As such, we need to be cautious and implement feature toggles can be used to disable the ability to utilize certain record types, and keep track of the request-to-response ratio in the network. ## Mitigation Strategies It is important that when this proposal is implemented, that we ensure the following: 1. Monitoring and Metrics: We MUST implement Tor's internal MetricsPort features to keep track of both the request type, the request size, and the response sizes. This will allow us to analyze DNS request-to-response ratios together with the Exit node operator community and determine if some DNS types are more prone to abuse than others. We suggest the following records to be exposed via the MetricsPort (naming can be changed later): ``` dns_lookup_count{type=rr} = n dns_lookup_request_size{type=rr} = n dns_lookup_response_size{type=rr} = n ``` Where `rr` is all of A, AAAA, PTR, and SVCB/HTTPS. 2. Anomaly Detection: Network health SHOULD utilize these metrics to develop systems to detect unusual patterns in DNS request volume and implement automated alerts for potential attacks. 2. Feature Toggles: We MUST ensure that the directory authorities have the ability to disable specific DNS types globally in the network in case of catastrophic abuse of the feature. This can be done using consensus parameters. 3. Response Size Limits: We MUST enforce strict limits on DNS response sizes, especially for the new record types, and implement intelligent truncation for over-sized responses. 4. Rate Limiting: Consider implementing per-client and per-record-type rate limiting for DNS requests. Consider adaptive rate limiting based on network conditions and observed patterns. 5. Periodic Auditing: Regularly review and update security measures as new threats emerge. Conduct periodic testing focused on DNS-related vulnerabilities. # Implementation Recommendations 1. Phased Rollout: Introduce new DNS capabilities gradually, monitoring for abuse at each stage. 2. Configurable Limits: Allow node operators to set custom limits on DNS usage. 3. Fallback Mechanisms: Implement fallback to basic DNS functionality if abuse is detected. 4. Collaborative Defense: Engage with the Network Health and Community team for developing analysis, response and coordination with the Exit operator community. # External References 1. Cloudflare wrote a blog post of the usage of HTTPS records in https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-d… 2. PowerDNS already implemented automatic hints for SVCB records in their software. See: https://doc.powerdns.com/authoritative/guides/svcb.html#svc-autohints # Testing and Debugging Cloudflare has SVCB enabled on `blog.cloudflare.com` and `crypto.cloudflare.com`. Their record can be seen using: $ dig blog.cloudflare.com -t TYPE65 If you have `drill` installed with modern HTTPS/SVCB support, you can also query it with a nicer response using: $ drill HTTPS blog.cloudflare.com This should make it easier to test the feature. --- snip --- -- Alexander Færøy

1 0

Tor over QUIC
by Q Misell 11 Oct '24

11 Oct '24

Hi all, I know the discussion on how best to support UDP applications over Tor has dragged on for a long time, so I thought what better to do than to throw another item to bikeshed into the discussion :) On a more serious note I think running Tor over QUIC would provide several advantages - both for the current stream transport and for possible future datagram transports. On a technical level I don't think this would require huge changes to the Tor specification, circuit IDs map nicely to QUIC stream IDs, and datagram packets - whatever form they take - can be sent as QUIC datagram frames (c.f. RFC 9221). The primary advantage I see QUIC providing is the removal of head of line blocking. As Tor currently multiplexes everything over one TCP connection, a single dropped packet will delay all circuits and streams. This impacts bandwidth utilisation and makes Tor less than ideal for real-time applications. Given this it might make more sense to provide a mapping of Tor streams to QUIC streams rather than Tor circuits - but this is a minor technical detail to be worked out in any specification. Now, that's great and all, but is it secure? I think yes - although I haven't done an in depth analysis yet. QUIC is very resistant against de-anonymization by passive attackers - the only thing a passive observer can see is a cryptographically generated random connection ID. QUIC also provides in-built padding frames to protect against traffic analysis. The connection setup and handshake is protected by the usual TLS mechanisms (with a minimum version of TLS 1.3). We already know recent TLS versions to be almost bullet proof if used correctly, and TLS is already the base transport for Tor anyway. A read of the security considerations section of RFC 9000 seems to confirm that even an active attacker can at most cause a connection to fail. Another concern is this making Tor traffic stand out more. This is a very legitimate concern, however with the increasing deployment of HTTP/3 I don't think it will make Tor stand out against the background of HTTP/3 traffic, see: https://e.as207960.net/w4bdyj/uJdzhSHvRZOf5dPL I recognise this is a rather large project - and may not be worthwhile. I only expect this to be implemented in Arti, so deployment of Tor over QUIC in the real world will take at least until Arti is widely used. What are people's thoughts on this? Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

6 7

When RFC 7686 and transparent proxies collide
by Matt Jolly 28 Sep '24

28 Sep '24

Hello Everyone, I recently inadvertently opened a much larger can of worms than I'd intended when fixing a bug reported downstream where cURL would, when configured with certain DNS backends, fail to resolve .onion addresses. https://bugs.gentoo.org/887287 After doing some digging I discovered that the c-ares library was updated in 2018 to intentionally fail to resolve .onion addresses in line with RFC 7686, and another reported 'Bug' in cURL for leaking .onion DNS requests: https://github.com/c-ares/c-ares/issues/196 https://github.com/curl/curl/issues/543 I took the obviously sane and uncontroversial approach of making sure that cURL would always behave the same way regardless of the DNS backend in use, and that it would output a useful error message when it failed to resolve a .onion address. Unfortunately, this has made a lot of people very angry and been ~~widely regarded as a bad move~~panned by a small subset of downstream cURL users: https://github.com/curl/curl/discussions/11125 https://infosec.exchange/@harrysintonen/110977751446379372 https://gitlab.torproject.org/tpo/core/torspec/-/issues/202 I accept that, in particular, transproxy users are being inconvenienced, but I also don't want to go back to 'cURL leaks .onion DNS requests _sometimes_'. As a career sysadmin and downstream bug triager: this is the stuff that keeps me up late at night. Quite literally, far too often. I have found, however that the downstreams that I expected to be inconvenienced most (Whonix and Tails) simply use socks: https://github.com/Kicksecure/sdwdate/commit/5724d83b258a469b7a9a7bbc651539… https://github.com/Kicksecure/tb-updater/commit/d040c12085a527f4d39cb1751f2… https://github.com/Kicksecure/usability-misc/blob/8f722bbbc7b7f2f3a35619a5a… https://gitlab.tails.boum.org/tails/tails/-/issues/19488 https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1123 I've asked in the Tor Specifications issue (inspired by Silvio's suggestions), and in the cURL issue, but I seem to be getting nowhere and the impacted users are clamouring for a quick band-aid solution, which I feel will work out worse for everyone in the long run: >How can client applications (safely): > >1.discover that they're in a Tor-enabled environment >2.resolve onion services only via Tor in that circumstance >3.not leak .onion resolution attempts at all > >Right now, not making these requests in the first place is the >safest (and correct) thing to do, however inconvenient it may be. >Rather than immediately trying to come up with a band-aid approach >to this problem, a sane mechanism needs to be implemented to: > >1.prevent each application from coming up with their own solution >2.prevent inconsistency in .onion resolution (i.e. no "oh it only >leaks if DO_ONION_RESOLUTION is set") >3.provide a standardised mechanism for applications that want to be Tor >aware to discover that they're in a Tor-enabled environment. I'm not particularly attached to that last point, but it's worth discussing. On a related note: -is the use of a transparent proxy recommended? -is there a sane alternative that involves as minimal configuration as possible for these users? I'm not sure what the best way forward is here, but I'm hoping that actual Tor developers might have a useful opinion on the matter, or at least be able to point me in the right direction. Thanks for your time, Cheers, Matt

7 9

Proposal 351: Making SOCKS5 authentication extensions extensible
by Nick Mathewson 16 Sep '24

16 Sep '24

(You can see this proposal rendered at https://spec.torproject.org/proposals/351-socks-auth-extensions.html ) ``` Filename: 351-socks-auth-extensions.md Title: Making SOCKS5 authentication extensions extensible Author: Nick Mathewson Created: 9 September 2024 Status: Open ``` ## Introduction Currently, Tor implementations use the SOCKS5 username and password fields to pass parameters for stream isolation. (See the `IsolateSocksAuth` flag in the C tor manual, and the "Stream isolation" section ([forthcoming](https://gitlab.torproject.org/tpo/core/torspec/-/merge_request…) in our [socks extensions](../socks-extensions.md) spec.) > Tor implementations also support SOCKS4 and SOCKS4a, > but they are not affected by this proposal. > > The C Tor implementation also supports other proxy types besides SOCKS. > They are not affected by this proposal > because they either have other means to extend their protocols > (as with HTTP headers in HTTP CONNECT) > or no means to pass extension information > (as for DNS proxies, iptables transparent proxies, etc). Until now, the rules for interpreting these fields have been simple: all values are permitted, and streams with unequal values may not share a circuit. But in order to integrate SOCKS connections into Arti's RPC protocol, we additionally want the ability to send RPC "Object IDs"[^ObjectId] in these fields. To do this, we will need some way to tell when we have received an object ID, when we have received an isolation parameter, and to avoid confusing them with one another. > Note that some confusion will necessarily remain possible: > Since current Tor clients are allowed to send any value > as SOCKS username and password, > any value we specify here will be one which a client in principle > _might_ have sent under the old protocol. Additionally, since we are adding complexity to the interpretation of these fields, it's possible we'll want to change this complexity in the future. To do this, we'll want a versioning scheme to premit changes. ## Proposal > If accepted, the following can be incorporated into > our [socks extensions](../socks-extensions.md) spec.) We support a series of extensions in SOCKS5 Username/Passwords. Currently, these extensions can encode a stream isolation parameter (used to indicate that streams may share a circuit) and an RPC object ID (used to associate the stream with an entity in an RPC session). These extensions are in use whenever the SOCKS5 Username begins with the 8-byte "magic" sequence `[3c 74 6f 72 53 30 58 3e]`. (This is the ASCII encoding of `<torS0X>`). If the SOCKS5 Username/Password fields are present but the Username does not begin with this byte sequence, it indicates _legacy isolation_. New client implementations SHOULD NOT use legacy isolation. A SocksPort may be configured to reject legacy isolation. When these extensions are in use, the next byte of the username after the "magic" sequence indicate a version number. Any implementation receiving an unrecognized or missing version MUST reject the socks request. When the version number is `[30]` (the ascii encoding of `0`), we interpret the rest of the Username field and the Password field as follows: The remainder of the Username field encodes an RPC Object ID. (If the remainder of the Username field is empty, there is no RPC object.) The Password field is stream isolation parameter. If it is empty, the stream isolation parameter is an empty string. ### Stream isolation > This replaces the corresponding part of > the "Stream isolation" section > ([forthcoming](https://gitlab.torproject.org/tpo/core/torspec/-/merge_request…) > in our [socks extensions](../socks-extensions.md) spec. Two streams are considered to have the same SOCKS authentication values if and only if one of the following is true: - They are both SOCKS4 or SOCKS4a, with the same user "ID" string. - They are both SOCKS5, with no authentication. - They are both SOCKS5 with USERNAME/PASSWORD authentication, using legacy isolation parameters, and they have identical usernames and identical passwords. - They are both SOCKS5 using the extensions above, with the same stream isolation parameter. ### A further extension for integration with Arti SOCKS > We should add the following to a specification, > though it is not clear whether it goes in the Arti RPC spec > or in the socks extensions spec. In some cases, the RPC Object ID may denote an object that already includes information about its intended stream isolation. In such cases, the stream isolation MUST be blank. Implementations MUST reject non-blank stream isolation in such cases. In some cases, the RPC object ID may denote an object that already includes information about its intended destination address and port. In such cases, the destination address MUST be `0.0.0.0` or `::` (encoded either as an IPv4 address, an IPv6 address, or a hostname) and the destination port MUST be 0. Implementations MUST reject other addresses in such cases. ----- > (Here the specifications end. > The rest of this proposal is discussion.) ## Design considerations Our use of SOCKS5 Username/Passwords here (as opposed to some other, new authentication type) is based on the observation that many existing SOCKS5 implementations support Username/Password, but comparatively few support arbitrary plug-in authentication. The magic "`<torS0X>`" prefix is chosen to be 8 characters long so that existing client implementations that generate random strings will not often generate it by mistake. The version number is chosen to be an ASCII `0` rather than a raw 0 byte, for compatibility with existing SOCKS5 client implementations that do not support non-ASCII username/password values. ## C Tor migration When this proposal is accepted, we *should* configure C tor to implement it as follows: - To reject any SOCKS5 Username starting with `<torS0X>` unless it is exactly `<torS0X>0`. This behavior is sufficient to give correct isolation behavior, to reject any connection including an RPC object ID, and to reject any as-yet-unspecified isolation mechanisms. [^ObjectId]: An ObjectId is used in the Arti RPC protocol to associate a SOCKS request with some existing Client object, or with a preexisting DataStream.

6 10

changes in user-agent spoofing in the Tor Browser 14.0 series
by Morgan 09 Sep '24

09 Sep '24

tldr; We're planning on disabling HTTP-header user agent spoofing on the basis that it (in our analysis) does little if any good while causing breakage on the internet when the JS and HTTP user agents do not match. However, if there is something critical we're missing here, we'd certainly love to hear. In the meantime it seems like an easy win for some improved usability. best, -morgan Excerpt from 14.0a4's blog post follows: > User Agent Spoofing Changes > > Historically, Tor Browser has spoofed the browser user agent found in HTTP headers, while not spoofing the user agent returned by the Navigator.userAgent property in JavaScript. The logic behind the HTTP header spoofing was to prevent passive tracking of users' operating system by websites (when using the 'Safest' security level) and by malicious exit nodes (or their upstream routers) passively listening in on unencrypted HTTP traffic. We left the JavaScript query intact for the purposes of website compatibility and usability. We also left it enabled because there are already many ways of detecting a user's real operating system when JavaScript is enabled (e.g. via font enumeration). > > With Tor Browser 14.0a4, we have introduced the boolean preference privacy.resistFingerprinting.spoofOsInUserAgentHeader. When this pref is set to true (which is currently the default), Tor Browser will follow the previously described legacy behaviour. However, if you set this preference (accessible in about:config) to false, Tor Browser will never spoof the user agent and will report your operating system family (i.e. Windows, macOS, Linux, or Android) when requested. We are considering changing Tor Browser to make this the new default behaviour. > > So, why are we considering making this change? Basically, asymmetrically spoofing the user agent causes website breakage seemingly due to bot-detection scripts. And (in our analysis) it also provides only a negligible amount of benefit to the user in terms of additional linkability (i.e. cross-site tracking, fingerprinting) protections, and only then when JavaScript is disabled. Tor Browser's default HTTPS-Only mode (and much of the web having moved to HTTPS) has also significantly reduced the utility of passively sniffing HTTP traffic for user agents as well. > > We would be very curious to hear from users and domain experts as to whether user agent spoofing is providing any other privacy benefits. In the meantime, disabling spoofing is available to users on an opt-in basis. For more information and to join the conversation, please see the Gitlab ticket tor-browser#42467.

1 0

Proposal for a New Web App to Configure Tor Nodes
by Alessandro Greco 30 Aug '24

30 Aug '24

Hello everyone, I have been thinking about creating a web app that generates a script to configure a Tor node based on the settings defined by the user. Let me explain a bit further. This web app could work either entirely on the client side using JavaScript or on the server side. I believe a client-side-only approach is preferable because it avoids handling user data in any way and reduces the risk of man-in-the-middle attacks, although it doesn't completely eliminate it. The main use case would be for a user who wants to contribute by configuring a Tor node. Instead of manually writing all the various configurations — from downloading Tor to following the best practices after configuration — the user would simply need to select a series of options on a user-friendly page (user-friendly = easier setup => more wish to do it, which could realistically lead to more relays), download the auto-generated file, and run it with administrative privileges. I believe that developing such a web app could not only benefit the Tor network by encouraging the deployment of new nodes, but it could also be highly educational. Alongside the script to execute, a standard report could be generated to technically explain the function of each setting. Of course, there would be a standard section allowing for basic relay execution and an "advanced" section that opens up multiple functionalities for the user. I'm not sure if something like this already exists, but I think it could be very helpful. For instance, I often find myself scrolling through the manual to check for the latest updates applicable to the `torrc` file. With this web app, we could also create a "latest updates" section. This is just my rough idea, and if it proves useful not just for me but for the rest of the community as well, we could consider structuring a development project around it. Best regards, Aleff. --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

5 6

terminology explaination: identifier.
by eff_03675549＠posteo.se 27 Aug '24

27 Aug '24

Hi, On the following URL : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/stats… the quote: *All per-graph statistics files are available for download via an URL of the form:* *https://metrics.torproject.org/identifier.csv* Remains ambiguous to me... *object of this email: *What is an /identifier/ ? Do the author imply the Nickname / Fingerprint ?... Do they imply the |KP_relayid_ed| that requires specific relay permission when the mere fingerprint is safer ?... *Would you kindly increment the torproject webpage with an example (or a set of examples) @ *http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/stats.html Cheers, Carlos.

2 1

Cancel
by tj 21 Aug '24

21 Aug '24

Sent from my iPhone

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev