Re: [tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[Michael Rogers]

On 13/01/16 20:42, s7r wrote:
> After prop 250, a malicious HSDir can not do so much, but a merged
> HSDir + IP can for example kill the circuit and force the hidden
> service to rebuild it. Under the current design, we retry for some
> times and give up if an introduction point is unreliable, but with 246
> we have to retry much more. If the same attacker also holds a
> reasonable % of middle bandwidth fraction in the Tor network, it will
> at least perform a successful guard discovery over the hidden service
> which is terrible. This may be fixed by not retrying a HSDir+IP too
> many times as described in section 4.3 of the proposal, but it will
> automatically lead to a capacity decrease (we have 5 HSDir + IP left
> out of 6).

The countermeasures in section 4.3 could be problematic for mobile
hidden services, which have unreliable internet connections and
therefore lose their intro circuits frequently. A service that lost its
internet connection more than INTRO_RETRIES times in a consensus period
would be left with no introduction points.

The discussions on guard selection have suggested that clients can't
easily distinguish between relay failures and internet connection
failures. On Android the OS broadcasts connectivity events that could be
used to reset the retry counter via the control port, but I don't know
about other platforms.

Cheers,
Michael


0x9FC527CC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/01/16 20:42, Damian Johnson wrote:
>> This was Stem commit c01a9cda4e7699c7f4bd642c8e81ed45aab7a29b
>> and Python version 2.7.10.
> 
> Great, thanks! Also what was the metrics-lib and zoossh commits?

metrics-lib: 8767f3e3bb8f6c9aa8cdb4c9fb0e9f2b545a7501
java version "1.7.0_51"

Zoossh: 2380e557e35532fd25870c8fc7a84a3fc951dbfc
go version go1.5.2 darwin/amd64

>> Or should we add these performance tests for metrics-lib, Stem,
>> and Zoossh to their own repository that also comes with scripts
>> to fetch data from CollecTor?  (Not sure if this is a smart thing
>> to do, but I figured I should ask before adding things to the
>> metrics-lib repository.)
> 
> Sinister plan #572 is that I'll add these results and scripts to
> the page we have with the library comparison. Probably tomorrow. If
> you'd care to clean up the metrics-lib examples that would be
> great. Otherwise I'll include what we have and you can send me
> patches later with what you'd like.

Sounds like a good plan.  Thanks for doing this!

Here's one thing I realized when composing this message.  When I
pasted Zoossh results earlier, I compared them to the results for
metrics-lib and Stem processing tarballs.  But Zoossh can only process
extracted tarballs.  I just re-ran metrics-lib and Stem with extracted
tarballs and included all results below:

server-descriptors-2015-11.tar.xz:
 - metrics-lib: 0.334261 ms

server-descriptors-2015-11.tar:
 - metrics-lib: 0.285430 ms
 - Stem: 1.02 ms (357%)

server-descriptors-2015-11/:
 - metrics-lib: 0.682293 ms
 - Zoossh: 0.458566 ms (67%)
 - Stem: 1.11 ms (163%)

extra-infos-2015-11.tar.xz:
 - metrics-lib: 0.274610 ms

extra-infos-2015-11.tar:
 - metrics-lib: 0.215500 ms
 - Stem: 0.68 ms (316%)

consensuses-2015-11.tar.xz:
 - metrics-lib: 255.760446 ms

consensuses-2015-11.tar:
 - metrics-lib: 246.713092 ms
 - Stem: 1393.10 ms (565%)

consensuses-2015-11/:
 - metrics-lib: 283.910864 ms
 - Stem: 1303.53 ms
 - Zoossh: 83 ms

microdescs-2015-11.tar.xz[*]:
 - metrics-lib: 0.099397 ms

microdescs-2015-11.tar[*]:
 - metrics-lib: 0.066566 ms
 - Stem: 0.66 ms (991%)

[*] The microdescs* tarballs contain microdesc consensuses and
microdescriptors, but I only cared about the latter; what I did is
extract tarballs, delete microdesc consensuses, and re-create and
re-compress tarballs

I'm attaching a slightly updated version of the metrics-lib code.
It's not cleaned up, but it's what I used to perform the measurements
above.

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWl3cmAAoJEJD5dJfVqbCrew8H/1JnOCbZAXD9dBQUIYsZPu//
jngO1Khf2lcggcHcxNMkhZS67KMmdKnyu0ZdjBHGdRNLZbQhhbDf5kQVtdx4xGim
h4+cMgNEWqVp2gvfr/pvF6luns1rXfKREN/uxs9B1zrk5nEqWjAuPWqdgFbqA3Ui
03VOd1inUNZ7fWFwJpvSzb5RuZHusmLAWsDXO/607cJ/Of99QUIU5NWEBwwVTvgl
ATd1+Slo2KIsNSpVPgtIbv345X7kTs2Jvt/ZvJsotQuRzn18d0A2ZayCddpQ896Z
gffIp+xY+19tr1x27bwbDS44Jhb3p1Y1cKqvAUjZXzk8iSecxL+kSn5JCEdl2YY=
=7nr/
-END PGP SIGNATURE-
/* Copyright 2016 The Tor Project
 * See LICENSE for licensing information */
package org.torproject.descriptor;

import java.io.File;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
import java.util.SortedMap;

public class MeasurePerformance {

  /* Check if all necessary files are available and then measure
   * performance of some more or less common use cases. */
  public static void main(String[] args) {
if (!filesAvailable()) {
  return;
}
/*measureListOutdatedRelays(null);
pause();*/
measureAverageAdvertisedBandwidth(new File(resDir, resPaths[0]));
pause();
measureAverageAdvertisedBandwidth(new File(resDir, resPaths[1]));
pause();
measureAverageAdvertisedBandwidth(new File(resDir, resPaths[2]));
pause();
/*measureFractionRelaysExit80ServerDescriptors(null);
pause();
measureSumOfWrittenAndReadBytes(null);
pause();*/
measureCountriesV3Requests(new File(resDir, resPaths[3]));
pause();
measureCountriesV3Requests(new File(resDir, resPaths[4]));
pause();
measureAverageRelaysExit(new File(resDir, resPaths[5]));
pause();
measureAverageRelaysExit(new File(resDir, resPaths[6]));
pause();
measureAverageRelaysExit(new File(resDir, resPaths[7]));
/*pause();
measureVotesByBandwidthAuthorities(null);
pause();
measureExtendedFamilies(null);
pause();*/
measureFractionRelaysExit80Microdescriptors(
new File(resDir, resPaths[8]));
measureFractionRelaysExit80Microdescriptors(
new File(resDir, resPaths[9]));
  }

  private static File resDir = new File("res");
  private static String[] resPaths = new String[] {
"archive/relay-descriptors/server-descriptors/"
+ "server-descriptors-2015-11.tar.xz",
"archive/relay-descriptors/server-descriptors/"
+ "server-descriptors-2015-11.tar",
"archive/relay-descriptors/server-descriptors/"
+ 

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/01/16 21:01, Philipp Winter wrote:
> On Wed, Jan 13, 2016 at 05:47:03PM +0100, Karsten Loesing wrote:
>> Do the Zoossh results there look plausible?
> 
> I'm surprised that descriptor parsing is so slow, but I think the 
> results are plausible, yes.  I should look into it.

Not to worry.  Turns out I compared the wrong numbers and Zoossh is
still the fastest parser in town (see my earlier reply in this thread).

What you could try, though, is extend Zoossh to parse tarballs rather
than directories.  This is more than 2 times faster in metrics-lib,
and it doesn't clutter your hard disk with thousands or millions of
tiny files.

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWl3eEAAoJEJD5dJfVqbCrKUoIALjQi8Ndy5Tu5NcvOmPoyw0H
tfEZST3jgvDddiQFpG8qPsZ47DmdPgA42d7oW7pJFhJMIn8ZhpvxRJb3r2M0eHGr
zarItm7MtPnidtfA1Bf1HYkOyyLArMgd9Ld+yE0GGDRBT/wjljmGo4k2kuoR8K0d
IeE9W2YsNrI1w6ilxedy6xQnnMfh0UrOxLg6wnYUvpkxrMyRbPVbPX9BAzna/mgx
svAYNsu3kDdc0lFTY/88P8xoVy35vyRaqNiuy7wswNGscGTR3bflq6JDXKdMI0HR
bgK0lrmeQrr2Z5qIu5HnyddG3u08hkpZufiv76oKpm+KsbuBBSD0HMLSu0uw5dU=
=z/EC
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot roadmap feedback

[Georg Koppen]

Nathan Freitas:
> On Tue, Jan 12, 2016, at 10:48 AM, Georg Koppen wrote:
>> Nathan Freitas:
>>> - Overall improved configuration / settings UI to make tuning Orbot a
>>> better, simpler experience... this is an expansion of the new exit
>>> country selector in Orbot v15.1, but also includes managing things like
>>> network usage and so on.
>>
>> Could you explain that point a bit more, what you currently have and
>> what you plan to do? Especially the exit country selector seems kind of
>> scary to me but maybe I am just missing some bits. I looked at the
>> changelog you sent to tor-talk (in the alpha 1 release mail) but did not
>> find anything related.
> 
> The broader idea is to determine which Tor torrc settings are relevant
> to the mobile environment, and that could use a more intuitive user
> interface than the empty text input we currently offer in our Settings
> panel. This may also mean implement a slider type interface mechanism
> similar to Tor Browser. In addition, users are interested in being able
> to control which network types (wifi vs 3g) Orbot runs on, in order to
> conserve spending on bandwidth.

Sounds good to me.

> The Exit country selector option (basically a list of countries that
> starts with "World" as the option) is definitely controversial, but it
> is also something that comes up over and over again as a feature
> request. It is expected especially of a VPN-style app, which Orbot now

True. We see these requests with Tor Browser as well.

> is. It may be we only enable it when the VPN feature is enabled, and
> disable it when Tor is used directly via SOCKS from the Orfox browser.
> We may also need to just sufficiently warn and inform the user so they
> can decide for themselves what to do.

Well, warning/informing the users about possibly harming themselves is
one thing (which is already tricky in this case given the complexity of
the matter). But how do you convey the problem that all the other users
of the Tor network could be affected as well if a bunch of users is
tweaking the exit node selection based on whatever reasoning? And this
does not only have anonymity ramifications but
performance/load-balancing implications as well. How is a user supposed
to make an informed decision in this case?

Georg




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Load Balancing with Overhead Parameters

[Mike Perry]

Tim Wilson-Brown - teor:
> > On 13 Jan 2016, at 00:53, Mike Perry  wrote:
> > 1. Overview
> > 
> > For padding overhead due to Proposals 251 and 254, and changes to hidden
> > service path selection in Proposal 247, it will be useful to be able to
> > specify a pair of parameters that represents the additional traffic
> > present on Guard and Middle nodes due to these changes.
> 
> I don't know if it's worth noting that proposals 252 and 260 (the Single Onion
> Services variants) will reduce traffic to guard and middle nodes, as they
> remove the nodes between the hidden service and client-controlled endpoint
> (rendezvous point in Rendezvous Single Onion Services, extend point in
> Single Onion Services).
> 
> I think these will just be part of the overhead parameters?

Probably, though this will require us to have some estimation on the
amount of network traffic using these services. Will they be broken out
separately in the extra-info hidden service stats?

> > 2. Simplified Load Balancing Equations
> > 
> > Recall that the point of the load balancing equations in section 3.8.3
> > of dir-spec.txt is to ensure that an equal amount of client traffic is
> > distributed between Guards, Middles, Exits, and Guard+Exits, where each
> > flag type can occupy one or more positions in a path. This allocation is
> > accomplished by solving a system of equations for weights for flag
> > position selection to ensure equal allocation of client traffic for each
> > position in a circuit.
> > 
> > If we ignore overhead for the moment and treat Guard+Exit nodes as Exit
> > nodes, then this allows the simplified system of equations to become:
> > 
> >  Wgg*G == M + Wme*E + Wmg*G# Guard position == middle position
> >  Wgg*G == Wee*E# Guard position == equals exit position
> >  Wmg*G + Wgg*G == G# Guard allocation weights sum to 1
> >  Wme*E + Wee*E == E# Exit allocation weights sum to 1
> 
> I think this analysis assumes that all paths in the Tor network are 3-hop 
> paths.

That is correct.
 
> What about the 4-hop paths created by circuit cannibalisation?
> (We don't actually know what proportion of the Tor network has 3-hop vs 4-hop 
> paths.)
> 
> Depending on whether an exit or internal circuit is cannibalised, they can 
> look like:
> G M E E
> G M M E
> 
> Or, if cannibalised from an exit or internal circuit:
> G M E M
> G M M M
> 
> Again, I think these will just be part of the overhead parameters?

Ugh. This will be complicated to work out. Cannibalization rate is a
function of how often you need to build a path, and have circuits
available, but none with the right exit/endpoint at the time. This will
be hard to predict accurately in the wild.

Cannibalization has been the bane of my existence every time I've made
any performance or path selection change to Tor. It was an optimization
introduced because TAP was believed to be too CPU-expensive to allow us
to opt to build fresh circuits when we needed a different endpoint than
was currently available in the open set, and so we needed to add the
new required endpoint to an existing open circuit instead.

Now that we have ntor, I am wondering if we can just remove
cannibalization. My guess is that without it, we will pay some up-front
latency cost in terms of needing to build fresh full circuits in some
(rare?) cases, but probably will have faster and higher capacity
circuits for those cases once they are built (especially since the
Circuit Build Timeout cutoff works better without factoring in
cannibalization time, as well). Circuit build prediction should also
reduce this cost over time, since it will ensure that we always have a
circuit open to recently used endpoint types (either exit ports or
hidserv-capable circs).

David Goulet supposedly has a simulator+test script to examine the
impact of cannibalization. He said that he'd look into updating it for
0.2.7/master, but here's a graph of his results from 0.2.5:
https://people.torproject.org/~dgoulet/hs/rp-025.png

Basically, that says that unless you make a whole lot of rendezvous
connections, cannibalized circuits are slower. I'm not sure why their
speed would be a function of quantity at all.. As I said, circuit
prediction should reduce the need for cannibalization over time, but it
shouldn't actually make the circuits that do get cannibalized any
faster..

All told, I think in the interest of simplification and also better load
balancing, we should still kill cannibalization for most cases. The one
case where I think it may still be desired is in the connection to the
hsdir, since it seems natural to just extend an existing circuit rather
than build a whole new one there.

> And what about hidden service paths (paths that include two middle nodes?)
> G M M

This one definitely needs to be included in the M_o overhead. I believe
the right additive amount is the current estimated percentage of network
hidden service traffic (by bytes), but 

Re: [tor-dev] Proposal: Load Balancing with Overhead Parameters

[David Goulet]

On 14 Jan (08:07:47), Mike Perry wrote:
> Tim Wilson-Brown - teor:
> > > On 13 Jan 2016, at 00:53, Mike Perry  wrote:
> > > 1. Overview
> > > 
> > > For padding overhead due to Proposals 251 and 254, and changes to hidden
> > > service path selection in Proposal 247, it will be useful to be able to
> > > specify a pair of parameters that represents the additional traffic
> > > present on Guard and Middle nodes due to these changes.
> > 
> > I don't know if it's worth noting that proposals 252 and 260 (the Single 
> > Onion
> > Services variants) will reduce traffic to guard and middle nodes, as they
> > remove the nodes between the hidden service and client-controlled endpoint
> > (rendezvous point in Rendezvous Single Onion Services, extend point in
> > Single Onion Services).
> > 
> > I think these will just be part of the overhead parameters?
> 
> Probably, though this will require us to have some estimation on the
> amount of network traffic using these services. Will they be broken out
> separately in the extra-info hidden service stats?
> 
> > > 2. Simplified Load Balancing Equations
> > > 
> > > Recall that the point of the load balancing equations in section 3.8.3
> > > of dir-spec.txt is to ensure that an equal amount of client traffic is
> > > distributed between Guards, Middles, Exits, and Guard+Exits, where each
> > > flag type can occupy one or more positions in a path. This allocation is
> > > accomplished by solving a system of equations for weights for flag
> > > position selection to ensure equal allocation of client traffic for each
> > > position in a circuit.
> > > 
> > > If we ignore overhead for the moment and treat Guard+Exit nodes as Exit
> > > nodes, then this allows the simplified system of equations to become:
> > > 
> > >  Wgg*G == M + Wme*E + Wmg*G# Guard position == middle position
> > >  Wgg*G == Wee*E# Guard position == equals exit position
> > >  Wmg*G + Wgg*G == G# Guard allocation weights sum to 1
> > >  Wme*E + Wee*E == E# Exit allocation weights sum to 1
> > 
> > I think this analysis assumes that all paths in the Tor network are 3-hop 
> > paths.
> 
> That is correct.
>  
> > What about the 4-hop paths created by circuit cannibalisation?
> > (We don't actually know what proportion of the Tor network has 3-hop vs 
> > 4-hop paths.)
> > 
> > Depending on whether an exit or internal circuit is cannibalised, they can 
> > look like:
> > G M E E
> > G M M E
> > 
> > Or, if cannibalised from an exit or internal circuit:
> > G M E M
> > G M M M
> > 
> > Again, I think these will just be part of the overhead parameters?
> 
> Ugh. This will be complicated to work out. Cannibalization rate is a
> function of how often you need to build a path, and have circuits
> available, but none with the right exit/endpoint at the time. This will
> be hard to predict accurately in the wild.
> 
> Cannibalization has been the bane of my existence every time I've made
> any performance or path selection change to Tor. It was an optimization
> introduced because TAP was believed to be too CPU-expensive to allow us
> to opt to build fresh circuits when we needed a different endpoint than
> was currently available in the open set, and so we needed to add the
> new required endpoint to an existing open circuit instead.
> 
> Now that we have ntor, I am wondering if we can just remove
> cannibalization. My guess is that without it, we will pay some up-front
> latency cost in terms of needing to build fresh full circuits in some
> (rare?) cases, but probably will have faster and higher capacity
> circuits for those cases once they are built (especially since the
> Circuit Build Timeout cutoff works better without factoring in
> cannibalization time, as well). Circuit build prediction should also
> reduce this cost over time, since it will ensure that we always have a
> circuit open to recently used endpoint types (either exit ports or
> hidserv-capable circs).
> 
> David Goulet supposedly has a simulator+test script to examine the
> impact of cannibalization. He said that he'd look into updating it for
> 0.2.7/master, but here's a graph of his results from 0.2.5:
> https://people.torproject.org/~dgoulet/hs/rp-025.png

Datapoint here: I'm almost done with #13802 (adding instrumentation
framework to Tor) from which we'll be able to add events to the code so
we can trace anything we want to measure.

Once I'm done with KIST tracing, I'll jump on this one for which I
already have most of the code ready for it. I want to get datapoints
from a real relay and chutney.

I'll update this thread once I get results.

> 
> Basically, that says that unless you make a whole lot of rendezvous
> connections, cannibalized circuits are slower. I'm not sure why their
> speed would be a function of quantity at all.. As I said, circuit
> prediction should reduce the need for cannibalization over time, but it
> shouldn't actually make the circuits that 

Re: [tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network

[Nick Mathewson]

On Thu, Jan 7, 2016 at 12:12 PM, Nick Mathewson  wrote:
> [This is a significantly revised version of the last version of this
> proposal draft, sent here for comment.
>
> The last version of this draft was
> https://lists.torproject.org/pipermail/tor-dev/2015-September/009587.html
> .  This is more or less a complete rewrite, after I convinced myself
> that the original ideas wouldn't work.
>
> Part of the functionality of that old draft has been subsumed in proposal 
> 264.]
>

This is now proposal 266.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I think the solution to change the consensus format - section 3.3 is
by far superior vs changing the ports on directory authorities or
disabling old link protocols at relays side.

Changing the consensus format is the cleanest way to do it and it has
smallest chances to degrade performance on working up to date clients.
Might as well make add the synonym as fast as possible, when we also
add the shared randomness value in the consensus document, because
it'll take quite some time until we are ready to say 'let's disable
all Tor versions before today'.

On 1/14/2016 6:26 PM, Nick Mathewson wrote:
> On Thu, Jan 7, 2016 at 12:12 PM, Nick Mathewson
>  wrote:
>> [This is a significantly revised version of the last version of
>> this proposal draft, sent here for comment.
>> 
>> The last version of this draft was 
>> https://lists.torproject.org/pipermail/tor-dev/2015-September/009587.html
>>
>> 
.  This is more or less a complete rewrite, after I convinced myself
>> that the original ideas wouldn't work.
>> 
>> Part of the functionality of that old draft has been subsumed in
>> proposal 264.]
>> 
> 
> This is now proposal 266.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWl897AAoJEIN/pSyBJlsRLd4H/02MUaOVyHxM/O0iWVcX2qMm
jnwGvlotVpKhCitb6eA19ah0R5iaX4u87VHxPB7+Z7TrJv1Hshe5cFrztNdkKLR2
5JJ/X2pAuC+kiY+LoPBEOSZroIK9/XIt8M4e/RMZeLHtmeiJevlwcx494FiYmcaz
mn2aBSaqy+ncecvg2q23wNUbanga6pCR52I5xIy4hcENl3RzUCUeDWCkLI31KV/U
09evLvByphP/mQormo/iQj/JDpPUtb9deaLSDhegemrIzdutaSyn0Qyzk9c9PWTs
lYkbduw7HOwacGjIrEDmfdbplCiXfVhQxO/q5QYyvpgor4N2etFw2EMqfqrXoDw=
=J1Oy
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Load Balancing with Overhead Parameters

[Nick Mathewson]

On Tue, Jan 12, 2016 at 8:53 AM, Mike Perry  wrote:
> This proposal aims to allow us to load balance properly between Guard,
> Middle, and Exit nodes with the addition of padding traffic to the
> network.
>
> Canonical proposal current lives in my load_balancing-squashed branch:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-load-balancing-with-overhead.txt?h=load_balancing-squashed
>
> Here is the text in-line, for ease of commenting on-list:

Added from the list as proposal 265 before I saw there was a canonical
location :/  .  Please point me at something to pull if the proposal
needs to be updated.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Damian Johnson]

> What you could try, though, is extend Zoossh to parse tarballs rather
> than directories.  This is more than 2 times faster in metrics-lib,
> and it doesn't clutter your hard disk with thousands or millions of
> tiny files.

For what it's worth processing tarballs rather than flat files made a
huge difference for Stem as well (tempted to say it was a 5x
improvement). Since you care so much about Zoossh's speed this could
be a great way to make it even faster. :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.

[Nick Mathewson]

So, one of the longstanding problems with Tor's (change) proposal
system has been that proposals sit around for a long time without
sufficient discussion or approval.  When they're about to be
implemented, we do an informal "hey did anybody look at that?" check,
but that's not really good enough.

Here's what I've been thinking of doing, as discussed at the tor dev
IRC meeting yesterday.

1. Everybody who will review proposals* should nominate one or two
proposals currently in state "Open" or "Draft".  People should
nominate proposals that they themselves didn't write.

2. I'll schedule review & discussion sessions, about one per week,
trying to hit times where interested people can make it.  Everybody
who will review proposals* should try to show up if they can, having
read the proposal or proposals under discussion for that week.  Then
we talk about the proposal(s)!

3. We'll try to move nominated proposals towards "Accepted" or
"Rejected", improving them as necessary.

* I'm not going to be too elitist here, but:  If you show up and
contribute usefully to discussions, I will prioritize your nominations
more than I will prioritize nominations from people who don't
contribute so much.


This is a draft process, so we'll try to see after a month or two
(possibly at the next face-to-face dev meeting?) how it's going.

Here's the schedule I have in mind for the  first meeting, based on
proposals already nominated at the IRC dev meeting.  I'm going to go a
bit aggressively for the first couple of weeks, so that we can get a
sense of how this process works out.  Everything is subject to change.
We'll be putting notes online from these meetings.

  Tuesday January 19:   11am Eastern (1600 UTC)

  Guard node proposals!  We'll be talking about these proposals:
   Prop#259: New Guard Selection Behaviour [DRAFT]
   Prop#241: Resisting guard-turnover attacks [DRAFT]
   Prop#247:  Defending Against Guard Discovery Attacks using
Vanguards [DRAFT]

  Friday January 22:   11 am Eastern (1600 UTC)

 Prop#251: Padding for netflow record resolution reduction [DRAFT]

  Monday January 25: 8pm Eastern (0100 UTC on Tuesday Jan 26)

  Prop#250: Random Number Generation During Tor Voting [DRAFT]

  Friday January 29:  8:30 am eastern (1330 UTC)

 Prop#252: Single Onion Services [DRAFT]
 Prop#260: Rendezvous Single Onion Services [DRAFT]
 Prop#246: Merging Hidden Service Directories and Introduction Points [OPEN]


Also nominated are:

Prop#264: Putting version numbers on the Tor subprotocols [OPEN]
Prop#257: Refactoring authorities and taking parts offline [DRAFT]
Prop#258: Denial-of-service resistance for directory authorities [OPEN]


-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.

[Spencer]

Hi,



Nick Mathewson:
proposals sit around for a long time



Is there a summarized visualization of these, or is it sifting through 
emails and tickets?




contribute usefully to discussions, I will prioritize
your nominations [for proposals] more



Sounds fair and balanced.

Wordlife,
Spencer



___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.

[David Goulet]

On 14 Jan (11:18:26), Nick Mathewson wrote:
> So, one of the longstanding problems with Tor's (change) proposal
> system has been that proposals sit around for a long time without
> sufficient discussion or approval.  When they're about to be
> implemented, we do an informal "hey did anybody look at that?" check,
> but that's not really good enough.
> 
> Here's what I've been thinking of doing, as discussed at the tor dev
> IRC meeting yesterday.
> 
> 1. Everybody who will review proposals* should nominate one or two
> proposals currently in state "Open" or "Draft".  People should
> nominate proposals that they themselves didn't write.
> 
> 2. I'll schedule review & discussion sessions, about one per week,
> trying to hit times where interested people can make it.  Everybody
> who will review proposals* should try to show up if they can, having
> read the proposal or proposals under discussion for that week.  Then
> we talk about the proposal(s)!
> 
> 3. We'll try to move nominated proposals towards "Accepted" or
> "Rejected", improving them as necessary.
> 
> * I'm not going to be too elitist here, but:  If you show up and
> contribute usefully to discussions, I will prioritize your nominations
> more than I will prioritize nominations from people who don't
> contribute so much.
> 
> 
> This is a draft process, so we'll try to see after a month or two
> (possibly at the next face-to-face dev meeting?) how it's going.
> 
> Here's the schedule I have in mind for the  first meeting, based on
> proposals already nominated at the IRC dev meeting.  I'm going to go a
> bit aggressively for the first couple of weeks, so that we can get a
> sense of how this process works out.  Everything is subject to change.
> We'll be putting notes online from these meetings.
> 
>   Tuesday January 19:   11am Eastern (1600 UTC)
> 
>   Guard node proposals!  We'll be talking about these proposals:
>Prop#259: New Guard Selection Behaviour [DRAFT]
>Prop#241: Resisting guard-turnover attacks [DRAFT]
>Prop#247:  Defending Against Guard Discovery Attacks using
> Vanguards [DRAFT]
> 
>   Friday January 22:   11 am Eastern (1600 UTC)
> 
>  Prop#251: Padding for netflow record resolution reduction [DRAFT]
> 
>   Monday January 25: 8pm Eastern (0100 UTC on Tuesday Jan 26)
> 
>   Prop#250: Random Number Generation During Tor Voting [DRAFT]
> 
>   Friday January 29:  8:30 am eastern (1330 UTC)
> 
>  Prop#252: Single Onion Services [DRAFT]
>  Prop#260: Rendezvous Single Onion Services [DRAFT]
>  Prop#246: Merging Hidden Service Directories and Introduction Points 
> [OPEN]

Fosdem is the next day so I'll be at a remote location called Brussels
for this meeting for which I doubt I'll be able to attend. This one is
about onion service proposals and I would really want to discuss those
with others so moving this one before or after Febuary 2nd would be
great for me. If impossible, I'll read the notes I guess :).

Apart from that, this is great and looking forward to those sessions!

Big thanks Nick for organising this!
David

> 
> 
> Also nominated are:
> 
> Prop#264: Putting version numbers on the Tor subprotocols [OPEN]
> Prop#257: Refactoring authorities and taking parts offline [DRAFT]
> Prop#258: Denial-of-service resistance for directory authorities [OPEN]
> 
> 
> -- 
> Nick
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev