tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Understanding bwauth data in Stem?
by Anna Kornfeld Simpson 09 Dec '14

09 Dec '14

I'm trying to understand how the bandwidth authorities work, and reading the spec [0] got me only partway to an understanding, so I'm trying to use Stem to see what the bwauth measurements look like in practice. I'm working off the "Votes by Bandwidth Authorities" example on the Stem webpage [1]. The query there returns a RouterStatusEntryV3, so I've been looking at the "bandwidth" and "measured" fields to try to understand what's going on [2]. "Bandwidth" maxes out at 10,000 (kb/s??) but "measured" doesn't seem to have the same ceiling, which made me realize that they aren't in the same units. Damian mentioned on IRC that "measured" might be returning the bwauth weight rather than a bandwidth, but what is the meaning of that weight? Does a higher "measured" value mean a higher bandwidth, or a higher bandwidth relative to what the relay advertises? In other words, if I sorted the descriptors by "measured" value, what would that order mean? Separately, is there a way (using Stem or some other tool) to see the raw bwauth measurements rather than the weights? Is that a calculation I can reverse? I haven't looked into the historical data on CollecTor yet, but ideally, I would like to use the historical data to figure out how effective the bwauth measurements seem to be in different situations (for example, the misconfigured to very high bandwidth relay this past February seems to have produced confusing bwauth measurements [3]). If I'm looking for interesting events in the historical bwauth data, would I be looking for high "measured" values, rapid changes, or ...? Thanks! Anna PhD Student, University of Washington [0] https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuth… [1] https://stem.torproject.org/tutorials/examples/votes_by_bandwidth_authoriti… [2] https://stem.torproject.org/api/descriptor/router_status_entry.html [3] https://lists.torproject.org/pipermail/tor-talk/2014-February/032094.html

4 6

Time change for Tor patch workshop meetings: 1800 UTC on Tuesdays
by Nick Mathewson 09 Dec '14

09 Dec '14

Hi! By request, I'm changing the time for the patch workshops from 1700 UTC to one hour later at 1800 UTC on Tuesdays. Bring your patches for tor, and let's chat about them! (Because of the late notice, I will try to be around for the whole time window, but I can't promise too much. I've got meetings all afternoon.) -- Nick

1 0

Git hosting changes, git:// support discontinued
by Sebastian Hahn 08 Dec '14

08 Dec '14

Hi there, git users! Today, weasel changed our gitweb setup to use cgit from now on in the wake of a migration to wheezy. This move hopefully improves speed without taking away any needed functionality. At the same time, we've discontinued supporting clones via the git:// Protocol. It is unauthenticated and you probably shouldn't use it if at all possible. Access via https:// has been provided for years, and should continue to work without any hiccups. If there are questions or concerns, let's here them. Cheers Sebastian

4 9

Re: [tor-dev] [tor-reports] Help desk report for November 2014
by David Fifield 08 Dec '14

08 Dec '14

On Mon, Dec 01, 2014 at 09:41:58AM -0600, Colin C. wrote: > Top answer templates used by the support team for this month: > > usage | article > -------+----------------------------------------------------------------- > 67 | Get your own bridges. > 36 | Get TB's Tor Log. > 33 | Exclude Tor Browser from an Antivirus/Firewall/AntiMalware > 30 | Tor Browser doesn't work (Windows) > 13 | Redirect to Guardian Project's support > 11 | How to get bridges and use Tor in mainland China > 11 | Please try meek > 10 | [debug] Tor Browser 4.0 is crashing on Windows > 9 | Can't connect to my favorite onion site! > 8 | Unsupported language > 7 | Redirect to Tails support > 7 | Suggest the tor-talk mailing list > 6 | Tor-related error window from browser. > 5 | How to use bridges > 5 | Set Country > 4 | TBB no Flash/Java other plugins (Replied to from https://lists.torproject.org/pipermail/tor-reports/2014-December/000711.html.) I'm interested to know if we can use help desk requests to detect new censorship events. When you answer with "Get your own bridges" or "Please try meek" or "How to use bridges," do you have an idea of what country or what language the request comes from? Do you keep track of any such numbers, even just a gut feeling? What about cases like the recent https://trac.torproject.org/projects/tor/ticket/12727 blocking in Iran last August, did you have an increase in Farsi requests or requests for bridges then? I don't mean to impose a lot of bookkeeping on you. I just want to see if this is a worthwhile idea. David Fifield

1 0

botnet detection
by Enkidu Mo Shiri 07 Dec '14

07 Dec '14

is there any new method for botnet detection through tor?anyway can find the hidden service which been used by botmaster to c&c botnets? as communication all are encrypted and the decryption happens only node by node, how can i detect which HS been used bt botmaster? help me plz

1 0

Re: [tor-dev] [tor-reports] Help desk report for November 2014
by David Fifield 06 Dec '14

06 Dec '14

On Mon, Dec 01, 2014 at 09:41:58AM -0600, Colin C. wrote: > Hi everyone, > > Here is the help desk chart for November 2014: > > | ar | en | es | fa | fr | zh | Total | (Rejected) > ----------+------+------+------+------+------+------+-------+----------- > boklm | | | | | 7 | | 7 | > harmony | | 113 | | 38 | | | 151 | 33 > jason | | 271 | | | | 76 | 347 | 38 > lunar | | 36 | | | 28 | | 64 | 22 > mttp | | 140 | | | | | 140 | 1 > noel | | 2 | 56 | | | | 58 | > phoul | | 185 | | | | | 185 | 39 > sherief | 6 | 277 | | | | | 283 | 45 > vmon | | | | 2 | | | 2 | > ----------+------+------+------+------+------+------+-------+----------- > Total | 6 | 1024 | 56 | 40 | 35 | 76 | 1237 | 182 > (Open) | 1 | 40 | 1 | 14 | 4 | 4 | 64 | > > That's almost 41 tickets resolved each day on average. > > See also the attached charts for the amount of incoming tickets each > day and for the past twelve months. > > Top answer templates used by the support team for this month: > > usage | article > -------+----------------------------------------------------------------- > 67 | Get your own bridges. > 36 | Get TB's Tor Log. > 33 | Exclude Tor Browser from an Antivirus/Firewall/AntiMalware > 30 | Tor Browser doesn't work (Windows) > 13 | Redirect to Guardian Project's support > 11 | How to get bridges and use Tor in mainland China > 11 | Please try meek > 10 | [debug] Tor Browser 4.0 is crashing on Windows > 9 | Can't connect to my favorite onion site! > 8 | Unsupported language > 7 | Redirect to Tails support > 7 | Suggest the tor-talk mailing list > 6 | Tor-related error window from browser. > 5 | How to use bridges > 5 | Set Country > 4 | TBB no Flash/Java other plugins (Replied to from https://lists.torproject.org/pipermail/tor-reports/2014-December/000711.html.) Colin, is it possible to see what's in the answer templates? At the 2014 dev meeting, a note in the support session (https://trac.torproject.org/projects/tor/wiki/org/meetings/2014SummerDevMee…) said "Lunar wants to take the RT articles out of the RT DB, put them on a public web page, allow others to review them." Does anything like that exist? David Fifield

2 1

Summary of meek's costs, November 2014
by David Fifield 05 Dec '14

05 Dec '14

Here's the summary of meek's CDN fees for November 2014. Earlier reports: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html If you're just tuning in, meek is a pluggable transport introduced a few months ago. https://trac.torproject.org/projects/tor/wiki/doc/meek. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.65 + $362.60 + $0.00 = $587.25 -- total by CDN $273.80 + $500.58 + $0.00 = $774.38 grand total Average usage (by count of simultaneous users) was about 3.04× greater in November than in the October (750 users per day versus 247). See the attached userstats-bridge-transport-meek-2014-09-01-2014-11-30.png. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The number of users was 3.04× according to Tor Metrics, but the cost for meek-google was 5.50× and meek-amazon was 2.78×. A possible explanation is that in addition to gaining more users, each user is also using more bandwidth. App Engine bandwidth was up 4.76× compared to last month and Amazon bandwidth was up only 2.65×. == App Engine a.k.a. meek-google == Google is migrating App Engine accounts to their new "Cloud Platform." Because I had to create a new Cloud Platform account, I got a free trial credit of $300. For technical reasons (relating to the Cloud Platform migration) I couldn't apply the credit until November 11. Up to then, we had been charged $75.70 for the month. The remaining $148.95 was paid by the credit. After this one, I have another $500 credit, which should get us into the new year. Here is how the costs broke down: 1375 GB $165.10 1191 instance hours $59.55 The attached meek-google-costs-2014-12-01.png shows the breakdown of costs between bandwidth and instance hours for the last few months. The attached meek-google-2014-12-01.png shows B/s for the month. There's a nice visible daily and weekly cycle. == Amazon a.k.a. meek-amazon == The Amazon bill breaks down in a complicated way by region. Asia Pacific (Singapore) 76M requests $91.43 500 GB $75.34 Asia Pacific (Sydney) 245K requests $0.01 1 GB $0.25 Asia Pacific (Tokyo) 27M requests $33.05 160 GB $26.23 EU (Ireland) 50M requests $58.34 490 GB $51.78 South America (Sao Paulo) 450K requests $0.00 3 GB $0.06 US East (Northern Virginia) 13M requests $13.12 115 GB $12.99 -- total 167M requests $195.95 1269 GB $166.65 == Azure a.k.a. meek-azure == Azure is still on a free grant for a year. Unfortunately I don't see a way to find out what it would be costing or even get a report of monthly bandwidth usage. The attached meek-azure-2014-12-01.png shows GB/hour for the last seven days of the month. David Fifield

1 0

Pluggable transports meeting tomorrow (16:00UTC Wednesday 3rd of December 2014)
by Yawning Angel 03 Dec '14

03 Dec '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel

1 0

Re: [tor-dev] Feedback on obfuscating hidden-service statistics
by George Kadianakis 02 Dec '14

02 Dec '14

"A. Johnson" <aaron.m.johnson(a)nrl.navy.mil> writes: > Hello all, > > <snip> > >> We put in some simple obfuscations in order to not reveal too >> sensitive data: we multiplied actual values with a random number in >> [0.9, 1.1] before including those obfuscated values in extra-info >> descriptors. Maybe there's something smarter we could do? Or is this >> okay? > > I actually think that additive rather than multiplicative noise > (i.e. randomness) makes sense here. Let’s suppose that you would like > to obscure any individual connection that contains C cells or fewer > (obscuring extremely and unusually large connections seems hopeless > but unnecessary). That is, you don’t want the (distribution of) the RP > cellcount from any relay to change by much whether or not C cells are > removed The standard differential privacy approach would be to *add* > noise from the Laplace distribution Lab(\epsilon/C), where \epsilon > controls how much the statistics *distribution* can multiplicatively > differ. I’m not saying that we need to add noise exactly from that > distribution (maybe we weaken the guarantee slightly to get better > accuracy), but the same idea applies. This would apply the same to > both large and small relays. You *want* to learn roughly how much RP > traffic each relay has - you just want to obscure the exact number > within some tolerance. > Hello Aaron, I posted an initial draft of the proposal here: https://lists.torproject.org/pipermail/tor-dev/2014-November/007863.html Any feedback would be awesome. Specifically, I would be interested in undertanding the concept of additive noise a bit better. As you can see the proposal draft is still using multiplicative noise, and if you think that additive is better we should change it. Unfortunately, I couldn't find any good resources on the Internet explaining the difference between additive and multiplicative noise. Could you expand a bit on what you said above? Or link to a paper that explains more? Or link to some other system that is doing additive noise (or even better its implementation)? Thanks!

2 4

Is PublishServerDescriptor needed to collect metrics?
by David Fifield 02 Dec '14

02 Dec '14

If a bridge has PublishServerDescriptor 0 does that prevent it from counting in metrics? If so, what's the right setting to enable metrics (0|1|v3|bridge,...)? Is there a way to send metrics data without also ending up in BridgeDB? David Fifield

4 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev