tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Simulating how Laplace noise added to directory-request statistics would affect user number estimates
by Karsten Loesing 19 May '17

19 May '17

Hi everyone, we'd like to improve directory-request statistics by obfuscating values on relays before they are reported to the directory authorities. A possible obfuscation method is to add Laplace noise to request counts for all ~250 countries, so that it's unclear whether a request was actually made by a user or is just noise. In fact, we did a similar thing to onion service statistics two years ago. But before we do this we need to find out whether obfuscated values would still be useful enough to estimate user numbers in the Tor network. We ran a simulation using archived descriptors and put our results including a graph, CSV files, and simulation code on this wiki page: https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Obfusca… The result is that we can't just go ahead and put in this noise, because we'd have to improve our user number estimation algorithms first. Otherwise we might risk losing one of our most important statistics: the number of daily Tor users by country. If you have any thoughts on these results or want to help make the simulation more accurate, please let us know! All the best, Karsten (for the metrics team)

1 0

[release] metrics-lib/DescripTor 1.7.0
by iwakeh 17 May '17

17 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! During the next time several releases of metrics-lib/DescripTor are planned culminating in a major release around the end of June. The first of this series is 1.7.0: https://dist.torproject.org/descriptor/1.7.0/ - From the change-log: * Medium changes - Parse "padding-counts" lines in extra-info descriptors [0]. - Some bug fixes avoiding dropped content - and test improvements. for details see [1]. Please direct comments and questions to the metrics-team mailing list [2]. Cheers, iwakeh [0] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1160 [1] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md?id=6941084… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZHD24AAoJEPeEx9Sa/gvi8f4P/AgD8VU99oifrGT9z7GKJgwS +dAb9ba14MpT0Jk1/RuP8CQQgsoV2AcqcDI1xsOpmR9nbIEbxGmAJxCsu8IxoC9L 0n1gvdIo7034yEPPv4vI+AI+KnS4KgHJAhpOcCPKsbeHsjSqCHRpphyJehkm53os dhFPRuQWmyHJ7pvN5R6HIJJ7htluzyt+zhz9XNhdyQ4OrNSgl/M76PAMRfeJt3WX 0e2eOeGk92zXxv+fYtUbTsrr6UwjQkR7Nx4qW49tqKyLy/0CDdHUnFmmYnrddOAs b0ZMpKzRCN8cKPXxFedV/uKD5eNNy//p1w/WAKeuKONGXogNKHsxxrnQ68CuEypx OTVq8cI4XPX62hMw61P9HhepCHzj3LPjhZ8t19IZ0jAguT2ESh2R0UkTO/v9Ul33 DwiJd3U1yWxYyKGGIJg988jk8KNUiM83aoyclriGFwUwolxbD+pBmmZicGRnR031 xOzP+f6Q0v/RnJG4GyydF+X+B2RO6/bllM9YDogWAwoj7DGS1CAP8/YEorkCQXg+ RBLsaZIXjRh0uPpanao6iL6xX+yBzu35ihRhLKNusX6bDubiA95Mr0F4OoDzj4sa 9d3wWX2OyGXQmfS+tVrLCtOQn1CkkLOVYo9G+DDomouhgzUM/TBAefy2IMz0IeJS ioVzKXE2IC4UTX1Y7sWh =pe7s -----END PGP SIGNATURE-----

1 0

(no subject)
by harshit tandon 15 May '17

15 May '17

I would like to contribute to tor browser how can I help regards, Harshit

3 2

Re: [tor-dev] Feedback Extension for Tor Browser
by Jayati Dev 13 May '17

13 May '17

Hello, The feedback extension project is not a part of GSoC this year, but I was wondering if its still possible to help with the project, if someone isn't already working on it? Thanks, Jayati > On 11-May-2017, at 5:30 PM, "tor-dev-request(a)lists.torproject.org" <tor-dev-request(a)lists.torproject.org> wrote: > > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. man page: MyFamily (nusenu) > 2. Re: man page: MyFamily (nusenu) > 3. Re: man page: MyFamily (teor) > 4. Re: man page: MyFamily (nusenu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 10 May 2017 21:30:00 +0000 > From: nusenu <nusenu-lists(a)riseup.net> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] man page: MyFamily > Message-ID: <65cc7527-0dff-fa55-5442-0f1ba7fe1b7c(a)riseup.net> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I wanted to help improve the man page section for MyFamily in the light > of today's MyFamily change [1]. > > I sometimes contact relay operators about their MyFamily configuration > and a common request is: "Please send me an example" > > So I added an example to the man page (including the new multiline > support in 031) > > - replaced "node" with "fingerprint" > (no one is using nicknames anymore, or onionoo does not display > fingerprints?) Are nicknames still supported? (Roger started to remove > remaining bits of the past Named "world" so this might be another place?) > - made clear that you can still have multiple fingerprints in a single > line (if this will be deprecated at some point I can add a deprecation info) > - added info that the fingerprint can be prefixed with $ > - changed "This option can be repeated many times, for multiple families" > to > "This option can be repeated many times, for multiple fingerprints" > (from one relay's view there is only one family) > > nusenu > > inline patch below (I can paste it to trac if you like) > > [1] > https://gitweb.torproject.org/tor.git/commit/?id=d76cffda601eed40d6a81eadb1… > https://trac.torproject.org/projects/tor/ticket/4998#comment:11 > > 1735c1735 > < [[MyFamily]] **MyFamily** __node__:: > --- >> [[MyFamily]] **MyFamily** __fingerprint__,__fingerprint__,__...__:: > 1738,1739c1738,1741 > < their identity fingerprints. This option can be repeated many > times, for > < multiple families. When two servers both declare that they are in the > --- >> their (possibly $-prefixed) identity fingerprints. >> This option can be repeated many times, for >> multiple fingerprints, all fingerprints in all MyFamily lines will > be merged. >> When two servers both declare that they are in the > 1745,1746c1747,1753 > < When listing a node, it's better to list it by fingerprint than by > < nickname: fingerprints are more reliable. > --- >> Example: + >> MyFamily > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB > + >> MyFamily CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC + >> + >> is identical to: + >> + >> MyFamily > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC > > >

1 0

txtorcon 0.19.2
by meejah 12 May '17

12 May '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fixing two more problems with the 0.19.1 release, I hereby give you version 0.19.2 which adds: * Work around a bug in "incremental" library (Issue 233) * Fix for Issue 190 from Felipe Dau * add txtorcon.Circuit.when_built You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.19.2 https://github.com/meejah/txtorcon/releases/tag/v0.19.2 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.19.2.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.19.2.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check c0e05ff4878468474167536a7b30edec23ae69eb26869c3e9ed9878e63ddc882 dist/txtorcon-0.19.2.tar.gz 0e2e85424c8f4c4627066ceebee59a931300e3712007f0a7620791729c80d459 dist/txtorcon-0.19.2-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZFSkrAAoJEMJgKAMSgGmnlwYIAIc2mFs0tQngDVYauEdg+WTD 0TMDGpXoQTFXgAj2st6MA+UITgc1od3PveIeNkYi7bCYxGndQbZeGJ14itXTwTZR lce9jHkn2ZG7LHhqcqC1Zdzp1+6lHQSgT81tPYzfUXhrqUHWjJjEHlSjAllZDD4E zbV9y8zdSuQYK65VqFPnGl4BzOKBAL3VEwrtzf2wYejykodZsXp5Aygl7WAmuSXv bl5avMfp0GLAu+5XvpfAqdAUQimtSE5/ODIWogF1Emqvu19qIwspQJk81A3yUSCa wD22S3BQc8RuE9GSjk75ykA8fYAfv8n1fYSqbaJazR7fe9ZMRsNPcwEiyF86jlw= =cZ/A -----END PGP SIGNATURE-----

1 0

Which network simulator are you using/suggesting for testing Tor
by vmon 11 May '17

11 May '17

Hello Tor-devers, A friend of mine wants to simulate Tor and measure the network performance by tweaking various node selection heuristics etc. He was wondering what simulator usually people who perform and study Tor uses. This was the best he came up with https://shadow.github.io/ but was wondering if anyone has a better suggestion. Thanks a lot for your help, vmon

2 1

man page: MyFamily
by nusenu 11 May '17

11 May '17

Hi, I wanted to help improve the man page section for MyFamily in the light of today's MyFamily change [1]. I sometimes contact relay operators about their MyFamily configuration and a common request is: "Please send me an example" So I added an example to the man page (including the new multiline support in 031) - replaced "node" with "fingerprint" (no one is using nicknames anymore, or onionoo does not display fingerprints?) Are nicknames still supported? (Roger started to remove remaining bits of the past Named "world" so this might be another place?) - made clear that you can still have multiple fingerprints in a single line (if this will be deprecated at some point I can add a deprecation info) - added info that the fingerprint can be prefixed with $ - changed "This option can be repeated many times, for multiple families" to "This option can be repeated many times, for multiple fingerprints" (from one relay's view there is only one family) nusenu inline patch below (I can paste it to trac if you like) [1] https://gitweb.torproject.org/tor.git/commit/?id=d76cffda601eed40d6a81eadb1… https://trac.torproject.org/projects/tor/ticket/4998#comment:11 1735c1735 < [[MyFamily]] **MyFamily** __node__:: --- > [[MyFamily]] **MyFamily** __fingerprint__,__fingerprint__,__...__:: 1738,1739c1738,1741 < their identity fingerprints. This option can be repeated many times, for < multiple families. When two servers both declare that they are in the --- > their (possibly $-prefixed) identity fingerprints. > This option can be repeated many times, for > multiple fingerprints, all fingerprints in all MyFamily lines will be merged. > When two servers both declare that they are in the 1745,1746c1747,1753 < When listing a node, it's better to list it by fingerprint than by < nickname: fingerprints are more reliable. --- > Example: + > MyFamily AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB + > MyFamily CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC + > + > is identical to: + > + > MyFamily AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

2 3

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
by Sebastian Hahn 09 May '17

09 May '17

Dear all, below mail was meant to make it to tor-dev, but I got a bounce and didn't notice until now. Whoops, my apologies. > On 8. Dec 2016, at 14:29, Sebastian Hahn <tor(a)sebastianhahn.net> wrote: > > Hi, > >> On 08 Dec 2016, at 14:03, nusenu <nusenu(a)openmailbox.org> wrote: >> >> Dear tor directory authorities, >> >> TLDR: Would you blacklist relays with end-to-end correlation capabilities? >> >> I'm asking to find out whether it makes sense to put any effort into >> finding such operators [2]. If most dir auths would not blacklist such >> relays than it does not make sense to look for them I guess. >> >> So please let us know whats your opinion on that - thank you. >> >> >> More information below and there [1]: >> >> >> The process could look something like this: >> >> - someone identifies such a relay groups (basically based on contactinfo >> [2]) >> - contact the operators asking to fix this (ideally this would be a >> @torproject.org sender) >> - give them 15 days to fix it >> - if not fixed: blacklist respective guard relays >> - give them the possibility to get removed from the blacklist once fixed > > I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. > > Additionally, it's yet one more thing to update the dirauths' configs > for, but with rather more overhead as we might get multiple mails back > and forth about how MyFamily is annoying to maintain, how they're just > trying to help, etc. All not so bad arguments. > > If we did this, also why would we blacklist the nonexit relays? That > seems to not make sense, as a relay operator could have multiple relays > that act as guard and exit simultaneously. I think we'd need to > blacklist at least all the exit relays, if not all of them. BadExiting > them would then be the more sensible choice. Scarcity of resources has > in the past led us to bad designs like Valid/Invalid relays etc, which > causes way more annoyances than good things. > > Cheers > Sebastian Cheers Sebastian

1 0

Re: [tor-dev] [tor-commits] [tor/master] Bug 17592: Clean up connection timeout logic.
by Roger Dingledine 09 May '17

09 May '17

On Mon, May 08, 2017 at 06:00:18PM +0000, nickm(a)torproject.org wrote: > commit d5a151a06788c28ac1c50398c6e571d484774f47 > Author: Mike Perry <mikeperry-git(a)torproject.org> > Date: Tue Feb 21 21:28:00 2017 -0500 [...] > + - Increase the intial circuit build timeout testing frequency, to help > + ensure that ReducedConnectionPadding clients finish learning a timeout > + before their orconn would expire. The initial testing rate was set back > + in the days of TAP and before the Tor Browser updater, when we had to be > + much more careful about new clients making lots of circuits. With this > + change, a circuit build time is learned in about 15-20 minutes, instead > + of ~100-120 minutes. Fyi, the current Tor network has "cbttestfreq=60" set in its consensus params. Is this something we should change? --Roger

2 1

Chutney Default: DNS or Offline?
by teor 07 May '17

07 May '17

Dear chutney users, Do you use DNS with chutney? (Chutney uses IP addresses by default.) Chutney has never worked offline, because Tor Exits check DNS before publishing their exit policy. And if DNS fails while a test is being run, chutney fails. (See Tor bug #21900.) We can make chutney work offline by disabling DNS. See the chutney bug at: https://trac.torproject.org/projects/tor/ticket/21903 But we need to decide what the default is: Do you want chutney to work offline by default? Or do you want chutney to have working DNS by default? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev