- tor-dev - lists.torproject.org

Back to the action!
by Fernando Fernandez Mancera 18 Sep '18

18 Sep '18

Greetings! I have been out this summer but I am back and I want to continue contributing. Starting next week I will attend the network-team meetings if you don't mind. If there is any task you could think it fits with my experience, please let me know. If there isn't, I am going to search in the ticket list. I am preparing my environment right now, and by tomorrow I will be ready to work! Thank you and see you soon at #tor-dev, ffmancera.

1 0

State of the HA proxy onion patch
by George Kadianakis 17 Sep '18

17 Sep '18

Hello Mahrud, I wanted to ask if you've been using the #4700 branch and how is it going? We've been planning to include #4700 in the upcoming 0.3.5 release if possible, and we remember that you had some pending patches to it. Do you think you can publish those somewhere if they are to be included upstream? There are also some further mods that need to happen that I'm not sure if you've performed in your local branch (torrc option & restricting the feature only to onion connections, as per #4700). Let us know how it's working for you and whether you have any patches that we should have in mind, so that we can see if we can fit it in the 035 release. Thank you! :)

2 4

Tor master exits with a required protocol error
by teor 17 Sep '18

17 Sep '18

(CC'd tor-relays, please direct replies to tor-dev.) Hi, If you are running Tor master, your Tor may exit with a required protocol error. The issue was introduced in commit 991bec67ee (about 8 hours ago). The following conditions will make Tor exit: * Tor will exit on startup if it has a cached consensus from the 14th of September (or earlier). It does not matter how old the consensus is. * If certain directory authorities go down, the remaining authorities may generate a consensus that will cause your Tor to exit. These consensuses require the LinkAuth=1 protocol, which Tor master believes it does not support. (The change was intended for NSS Tors, but mistakenly applies to all Tors.) Here's how you can mitigate this issue: * downgrade to 0.3.4.8 or earlier, or * delete the cached consensuses in your data directory. These consensuses may be called cached-consensus, cached-microdesc-consensus, unverified-consensus, and unverified-microdesc-consensus. Some may not be present. We should resolve this issue in master in the next 24 hours. Then it may take another 24 hours for packages to be rebuilt. The master ticket for this change is: https://trac.torproject.org/projects/tor/ticket/27288 T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

1 0

Upcoming changes to CSV files provided by Tor Metrics
by Karsten Loesing 14 Sep '18

14 Sep '18

Hello tor-dev@, today we finally published specifications [0] for the per-graph CSV files that we added to Tor Metrics earlier this year. At the same time we're announcing two upcoming changes to CSV files provided by Tor Metrics: - August 15: We're going to make the first batch of changes to per-graph CSV files marked as "Suggested change" on the linked page. If you're currently working with per-graph CSV files, you should watch out for those changes. We're tracking these changes on #26998 [1]. - September 15: We're going to remove pre-aggregated CSV files after providing working alternatives with the per-graph CSV files for all use cases we thought of or that were brought to our attention. If you're currently working with pre-aggregated CSV files, you should consider switching after August 15 but before September 15. The relevant ticket for this change is #27000 [2]. Please direct any questions or comments to the metrics-team@ mailing list [3] or comment on either of the two tickets mentioned above. All the best, Karsten [0] https://metrics.torproject.org/stats.html [1] https://bugs.torproject.org/26998 [2] https://bugs.torproject.org/27000 [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 1

[release] Onionoo 7.0-1.18.1
by Iain Learmonth 11 Sep '18

11 Sep '18

Hi, Onionoo's protocol was extended and has a major version bump to 7.0. Download available at: https://dist.torproject.org/onionoo/7.0-1.18.1/ Protocol changes (also summarized in [0]): Extended the "version" parameter to support lists and ranges Removed redundant "1_week" and "1_month" graphs from clients documents Changed "3_months" graphs to "6_months" graphs in all documents containing history objects Removed the "fingerprint" parameter Removed the previously deprecated "as_number" field from details documents Software changes are summarized in the changelog [1]. The changes are already deployed on all onionoo.torproject.org instances. Note that the 7.0-1.18.0 release suffered from a bug that did not surface until deployment and the deployment was rolled back until the 7.0-1.18.1 release could be made. This issue only affected the web server, not the updater or state files. Please direct comments and questions to the metrics-team mailing list [2]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://metrics.torproject.org/onionoo.html#versions_6_1 [1] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Tor Volunteer
by ESAUL PARRA GARCIA 09 Sep '18

09 Sep '18

Hello everyone, I want to volunteer my time for the tor project. I have a background in statistics, python, R, and web development(react, nodejs, monbodb, aws, dynamob). Let me know what I can do to help. Email me back so I can send you my resume. Best, Esaul Parra Garcia -- University of California, Los Angeles B.S. Statistics | 2017 Email: epg323(a)ucla.edu | Mobile: 323.984.1204

5 10

PDF versions of Marionette Documents
by John Helmsen 04 Sep '18

04 Sep '18

These are the PDF versions of the Marionette Documents for easier reading. The markdown versions of them can be found on the github distribution at https://github.com/redjack/marionette/doc -- John Helmsen john.helmsen(a)redjack.com C: (301) 273-4372

3 2

Fwd: Manuals
by John Helmsen 04 Sep '18

04 Sep '18

FYI The Marionette documentation. Marionette Manuals for review ---------- Forwarded message ---------- From: John Helmsen <john.helmsen(a)redjack.com> Date: Fri, Aug 31, 2018 at 9:34 AM Subject: Manuals To: "Ianculovici, Ciprian" <IanculoviciC(a)state.gov> -- John Helmsen john.helmsen(a)redjack.com C: (301) 273-4372 -- John Helmsen john.helmsen(a)redjack.com C: (301) 273-4372

1 0

Network Team Meeting: Tuesday 1700 UTC
by teor 04 Sep '18

04 Sep '18

Hi, It's a public holiday in the US on Monday. So we moved the network team meeting from Monday to Tuesday 1700 UTC for this week. Sorry for the late notice! T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

1 0

Archiving old Components in Trac
by teor 29 Aug '18

29 Aug '18

Hi, Is anyone still using these trac components? Applications/Tor Messenger Applications/Tor Mail Applications/TorBirdy Core Tor/Erebus Obfuscation/FTE If no-one is using them, we can move them to Archived/ T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

6 7

oss-fuzz Coverage
by Tom Ritter 29 Aug '18

29 Aug '18

tor is in OSS-Fuzz, and I recently found this very slick dashboard that shows you just what coverage tor is getting out of it: https://storage.googleapis.com/oss-fuzz-coverage/tor/reports/20180829/linux… Thought I'd share in case others hadn't seen it (I think it's fairly new.) -tom

1 0

Highlights from ACM SIGCOMM
by Iain Learmonth 27 Aug '18

27 Aug '18

Hi All, I attended ACM's SIGCOMM last week. A few things caught my attention that I thought might be of interest here: "CircuitStart: A Slow Start For Multi-Hop Anonymity Systems" Christoph Döpmann and Florian Tschorsch. Link: https://dl.acm.org/authorize?N666917 "Design of SOCKS Version 6" Vladimir Olteanu and Dragoş Niculescu. Link: https://dl.acm.org/authorize?N666057 Related Internet Draft: https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/ One thing about their design for SOCKS 6 is that is has options, and those options could be used to specify some sort of isolation property instead of overloading username/password. Thanks, Iain.

1 0

routing security handling in the tor network
by nusenu 27 Aug '18

27 Aug '18

Hi, I looked at the routing security state of the >3k BGP prefixes that make up the tor network [1]. I believe it is important for tor to have a discussion on how the network should deal with relays that will increasingly be only partially reachable due to the increase of RPKI route origin validation (ROV) in big IXPs (AMS-IX to name one). to quote the relevant part from [1]: > “Virtual” Route Origin Validation in the Tor Context > > The are two good reasons why Tor should care about relays located in > RPKI ‘Invalid’ prefixes: > > It will eventually break the “the Tor network is a full mesh” > assumption. Relays in such RPKI ‘invalid’ prefixes with no > alternative valid route will not be reachable from ASes performing > ROV, but the Tor network assumes that every relay can reach every > other relay. When ROV breaks that assumption it is better to exclude > these relays than to keep only partially reachable relays. An RPKI > ‘Invalid’ route might as well be an actual BGP hijacking attempt and > why not stop that? > > The obvious place to enforce ROV for the Tor network would be the Tor > directory authorities that would run RPKI validators and vote for > relays accordingly. At this point this is no more than an idea. There are certainly some challenges and trade-offs when doing ROV from a non-BGP-router perspective, but they are solvable. There is no need to panic - this affects less than 5 relays currently but we should have a discussion and reach some form of consensus on the topic to move forward instead of waiting until it significantly affects reachability. Would be nice to have an initial discussion even before writing a proposal to gather opinions if that would be actually worth doing. kind regards, nusenu [1] https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacki… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 1

Re: [tor-dev] Relay diversity master thesis
by Robin Descamps 22 Aug '18

22 Aug '18

Hello, I would like to share with you the master thesis I wrote this year on a topic concerning diversity in Tor, that I evoked earlier this year. I would like to thanks all the dev that have shared feedback with me about my thesis plan. This work may not be perfect, but could start/influence the research in the future hopefully. Here is the abstract and the access link: Tor is the most popular anonymous communication system nowadays, that set up a excellent compromise between anonymity and performance. However, Tor is by design vulnerable to end-to-end correlation attacks. Many techniques have been and are being developed in order to mitigate these attacks. This master thesis objective is to define the utility of a new relay, and to give a measure of its contribution to the diversity of the network. This is achieved with a modified version of the TorPS , which simulate the Tor network against both relay and network adversaries. More diversity means less end-to-end correlation attacks possible by the latter. At the end, we would like the volunteers to be aware of the utility they bring to the Tor network security with a certain relay configuration. https://dial.uclouvain.be/memoire/ucl/fr/object/thesis%3A14661<https://dial.uclouvain.be/memoire/ucl/fr/object/thesis:14661> Thanks, Robin Descamps Le 22 déc. 2017 à 01:23, Robin Descamps <robin.descamps(a)outlook.com<mailto:robin.descamps@outlook.com>> a écrit : Hello, I already sent this message to the metrics team, but they advice me to address it to the dev team, which seem to be more relevant. I realise this year a master thesis, in the Université catholique de Louvain in Belgium, about measuring the utility brought to the Tor network diversity by adding a new relay, according to its configuration. I added to this message my master thesis plan, as well as a poster that presents a summary of the key elements. May I ask you advices/feedback about this master thesis plan? Since I would like this project to bring a real contribution to the Tor development, I want to make sure that all the steps I will perform are useful and/or worth it. The master thesis plan: https://drive.google.com/open?id=1XEOSS29owavKJ_cJJAVaPiJe34Ez6XXx The poster: https://drive.google.com/open?id=1BlF2U-Kexyz6ihVSqvsVHv4PUsvXATc4 Thanks, Robin Descamps

2 2

Unable to access '#tor-dev' IRC Channel
by KUSHAL BORKAR 20 Aug '18

20 Aug '18

Greetings All, This is to inform you that, I, Kushal Borkar, IRC Alias 'Lashuk', am unable to access the '#tor-dev' IRC channel. I tried using Pidgin Internet Messenger to properly connect to the channel but I face the same problem: "Cannot join #tor-dev: Registration is required." I also checked whether I'm linked to the internet and also verified by using the command "/msg NickServ IDENTIFY". I cannot access the '#tor-dev' IRC channel on OFTC neither using my registered nick on desktop client nor through the web interface. I also tried OFTC IRC Service to check my Nickname which indicated me "An error occurred fetching the nickname data. It may be private or there may be a problem with the server." I eagerly want to discuss the specific project "Ahmia - Onion Service Search" and would like to know about the Outreachy Internship which starts from December to March. I politely request you all help me and direct me in the right direction in order to start thinking about what I could do for Tor. With Regards, *Kushal Borkar* *B.Tech - 4th Year,Electronics and Communication Engineering,IIIT Chittoor,Sri City-517588* Email Id*: kushal.b15(a)iiits.in <kushal.b15(a)iiits.in>*

2 1

[release] Onionoo 6.2-1.17.1
by Iain Learmonth 17 Aug '18

17 Aug '18

Hi, A patch release has been made for Onionoo to fix errors with the searching for relays with unknown AS numbers. Additionally, we announce today the fixes from version 6.2-1.17.0 which were released yesterday but not deployed as this additional patch was ready for release and so we postponed. This fixes issues with slow reverse DNS lookups. Download available at: https://dist.torproject.org/onionoo/6.2-1.17.1/ Software changes are summarized in the changelog [0]. The changes are already deployed on all onionoo.torproject.org instances. Not all reverse DNS names will be looked up immediately, but should all be present once the updater has run at least once 13 hours after the upgrade. Please direct comments and questions to the metrics-team mailing list [1]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Alternative directory format for v3 client auth
by George Kadianakis 14 Aug '18

14 Aug '18

Hello haxxpop and David, here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: https://github.com/torproject/torspec/pull/23 Thanks for making me edit the spec because it made me think of various details that had to be thought of. Let me know if you don't like it or if something is wrong. Cheers!

3 8

[release] Onionoo 6.2-1.16.1
by Iain Learmonth 13 Aug '18

13 Aug '18

Hi, A patch release has been made for Onionoo to fix an error in the serialization of history documents. Download available at: https://dist.torproject.org/onionoo/6.2-1.16.1/ Software changes are summarized in the changelog [0]. The changes are already deployed on all onionoo.torproject.org instances. In order to benefit from this fix immediately you may wish to follow the advanced instructions listed below. If you do not do this, then after a week you should find that the problem is resolved, it will just happen more slowly as the documents are rewritten. 1. Checkout commit 18e5c04 in karsten's task-27039 branch https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-27039… 2. Run ant jar to build the jar file at generated/dist/onionoo-6.2-1.16.0-dev.jar. (You will not need the war file built.) 3. Upload this jar file along with the jar and war files for the 6.2-1.16.1 release. 4. Wait for hourly updater to end. 5. Stop hourly updater and the web server. 6. Run java -jar onionoo-6.2-1.16.0-dev.jar --rewrite-only. 7. Remove the intermediate jar file to avoid confusion. 8. Re-start the web server and the hourly updater using the files from the 6.2-1.16.1 release. Please direct comments and questions to the metrics-team mailing list [1]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

[release] Onionoo 7.0 will be released after September 3, 2018
by Karsten Loesing 09 Aug '18

09 Aug '18

Hello tor-dev@, yesterday we announced Onionoo protocol version 6.2 that we released a few days before on August 3, 2018. One month later, after September 3, 2018, we're going to release Onionoo protocol version 7.0 which will make a couple backward-incompatible changes: - extend the "version" parameter to support lists and ranges, - remove redundant "1_week" and "1_month" graphs from clients documents, - change "3_months" graphs to "6_months" graphs in all documents containing history objects, - remove the "fingerprint" parameter, and - remove the previously deprecated "as_number" field from details documents. You can find more details on the Onionoo protocol page: https://metrics.torproject.org/onionoo.html If you're using any of these fields or parameters, be sure to either update your Onionoo client to support the new protocol version, or pester your Onionoo client developer to do that for you. On behalf of the Tor metrics team, Karsten

2 2

Tor Browser for arm64/v8 on RPi3
by procmem 08 Aug '18

08 Aug '18

@intrigeri I'll post there. Thanks for the heads up.

1 0

[release] Onionoo 6.2-1.16.0
by Iain Learmonth 08 Aug '18

08 Aug '18

Hi, Onionoo's protocol was extended and has a minor version jump to 6.2. Download available at: https://dist.torproject.org/onionoo/6.2-1.16.0/ Protocol changes (also summarized in [0]): Added an "as" field to details document, deprecated the "as_number" field, added an "as_name" parameter to search for relays by AS name, and added support for comma-separated lists in the "as" and the "lookup" parameters. Software changes are summarized in the changelog [1]. The changes are already deployed on all onionoo.torproject.org instances. Unfortunately there are two known bugs affecting this release that were not fixed before deployment: Timestamps in graph history documents are incorrectly formatted which is currently breaking graphs in relay search. No data is lost and the graphs will reappear once this is resolved. (See #27039 [2]) Reverse DNS names are still being looked up slowly and so are missing for most relays. (See #27050 [3]) Please direct comments and questions to the metrics-team mailing list [4]. Thanks, Iain -- on behalf of the Metrics Team. [0] https://metrics.torproject.org/onionoo.html#versions_6_1 [1] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?h=onionoo-6.2-… [2] https://bugs.torproject.org/27039 [3] https://bugs.torproject.org/27050 [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Reviewing Trac #18642 (Teach the OOM handler about the DNS cache)
by neel＠neelc.org 06 Aug '18

06 Aug '18

Hi tor-dev@ mailing list, I have a patch for Bug #18642 (Teach the OOM handler about the DNS cache) which I would like reviewed. The URL is here: https://trac.torproject.org/projects/tor/ticket/18642 (https://trac.torproject.org/projects/tor/ticket/18642) Originally, dgoulet chose he would review, but after no response on the patch, he has emailed me that he's on vacation until the 16th of August, hence the reason why I'm emailing here. I am really keen on getting this patch in, and if there's any Tor developer here, could someone please review and merge it? Thank You, Neel Chauhan === https://www.neelc.org/

3 3

Tor Browser for arm64/v8 on RPi3
by procmem 06 Aug '18

06 Aug '18

We at Whonix are currently porting to (non-VM) physical builds on arm64 - specifically RPi3. While this is great for headless applications we are interested in GUI user adoption. Without Tor Browser for arm64 this won't be as safe as it can be. Can you please consider releasing builds for this hardware platform?

2 1

Tor Relay Guide Disagreements
by nusenu 03 Aug '18

03 Aug '18

Hi Vinícius, (moving this discussion to the tor-dev mailing list since this isn't limited to the OpenBSD ticket scope https://trac.torproject.org/projects/tor/ticket/26619#comment:14 ) Vinícius wrote: > you [nusenu] took over /FreeBSD, /BSDUpdates, and /OpenBSD and enabled the 'read- > only' mode all by yourself without even consulting the original author or > anyone else [...] > is there any particular reason why you enabled the read-only mode on > /FreeBSD, /BSDUpdates, and /OpenBSD? I think this a pretty odd behavior. > I'm sorry. if you do want to own all these pages (and many other more), > please tell us. The Tor Relay Guide wiki page [1] has been 'read-only' pretty much since we launched it, it has been decided a few months ago in [0]. Anyway read-only mode shouldn't affect you personally. Since you are listed on the tor people page I assume you can simply ask for the permissions to edit 'read-only' pages. I'd still ask you to open tickets for changes like your change to the FreeBSD page instead of applying them directly so we can discuss them before applying and to avoid the necessary efforts. On 2018-07-10 I split out the OS specific instructions into their subpages: /DebianUbuntu /FreeBSD ... because of this move content that was previously read-only until then became writable but that wasn't an intentional step. On 2018-08-02 you changed the FreeBSD page [4], here are two lines (examples) of your replacements: my text: change the nickname "myNiceRelay" to a name that you like Change the email address bellow and be aware that it will be published got replaced with: CHANGE THE NICKNAME WRITE YOUR EMAIL ADDRESS I'm not sure I would consider these replacements an improvement since they remove information without giving any reasoning for removing it in the comment. Besides the removal of information this also introduces inconsistency in the torrc file we used so far in the guide. I reverted your change and addressed the issue you brought up (net.inet.ip.random_id ordering, /etc/pkg/FreeBSD.conf modification) and made the content read-only again (like it was until 2018-07-10). > ggus is that page's [/OpenBSD] author and he allowed me to edit the contents of that > page (the same is also applied to the /FreeBSD page; There has been no comment by ggus on #26619 (/OpenBSD) for a month so I went ahead and assigned it to me, but I'll pull out of that ticket now. https://trac.torproject.org/projects/tor/ticket/26619 ggus didn't create /FreeBSD [3]. > should we always open tickets with suggestions? - sadly it > also sounds extra odd, because when I did open tickets (#27006 and > #27007), a few minutes later you changed contents all by yourself #27006 is about /DragonFlyBSD I've never touched that page? https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DragonFlyBSD?ac… #27007 was about creating /NetBSD - which you did. I didn't consider my change - where I replaced the ORPort to use 443 (because we used that port everytime that works out of the box on a platform) to be part of the "create the /NetBSD page": https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/NetBSD?action=d… Going forward I'd propose the following to minimize the fraction and overhead: I assume you maintain: /TorRelayGuide-ptbr /TorRelayGuide/OpenBSD /TorRelayGuide/NetBSD /TorRelayGuide/DragonFlyBSD I'll keep maintaining: /TorRelayGuide /TorRelayGuide/DebianUbuntu /TorRelayGuide/CentOSRHEL /TorRelayGuide/Fedora /TorRelayGuide/FreeBSD /TorRelayGuide/openSUSE All pages should be read-only and writable to authorized users/maintainer, but feel free to have the pages you maintain world writable. All non-maintainer changes are expected to go through a ticket. After a timeout of 7 days with no maintainer response the ticket opener might proceed with applying the proposed change. I'll propose a list of requirements for a platform to be listed on the main page. kind regards, nusenu [0] https://trac.torproject.org/projects/tor/ticket/24497 [1] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide [2] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD [3] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?action=… [4] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_ema… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

WTF-PAD and the future
by George Kadianakis 03 Aug '18

03 Aug '18

Hello Mike, I had a talk with Marc and Mohsen today about WTF-PAD. I now understand much more about WTF-PAD and how it works with regards to histograms. I think I might even understand enough to start some sort of conversation about it: Here are some takeaways: 1) Marc and Mohsen think that WTF-PAD might not be the way forward because of its various drawbacks and its complexity. Apparently there are various attacks on WTF-PAD that Roger has discovered (SENDME cells side-channels?) and also the deep learning crowd has done some pretty good damage to the WTF-PAD padding (90%-60% accuracy?). They also told me that achieving needed precision on the timings might be a PITA. 2) From what I understand you are also hoping to use WTF-PAD to protect against circuit fingerprinting and not just website fingerprinting. They told me that while this might be plausible, there is no current research on how well it can achieve that. Are we hoping to do that? And what research remains here? How can I help? Which parts of the Tor circuit protocol are we hoping to hide? 3) Marc and Mohsen suggested using application-layer defences because the application-layer has much better view of the actual structures that are sent on the wire, instead of the black box view that the network layer has. In particular they were mainly concerned about onion services fingerprinting because they are part of a restricted closed world, whereas they were less concerned about the entire internet because of its vast size. They suggested that we could investigate using the service-side "alpaca" library for onion services (e.g. as part of securedrop?) which should resolve the most pressing concern of HS identification. 4) They also told me of research by Tobias Pulls which eliminates the needs for histograms in WTF-PAD and instead it samples from the probability distribution directly. They think that this can simplify things somewhat. Any thoughts on this? Let me know what you think. I still don't understand the entire space completely yet, so please be gentle. ;) Cheers! :)

5 7