[tor-dev] Experimenting with private tor setup

2015-04-20 Thread CJ Ess
I've been experimenting with a private tor setup - I've managed to setup a couple directory authorities, six routers/exit nodes (which seemed to be the minimum to bootstrap everything), and a client. Its a pretty normal setup (aside from everything running on my development box) and passes traffic

[tor-dev] Possible anomaly in meek user graph circa April 15, 2015

2015-04-20 Thread David Fifield
The latest meek user graph shows two recent large increases. The first increase from 2000 to 3000 is around April 9. The second from 3000 to 5000 is all on April 15. The first increase makes sense; it corresponds with the removal of a bottleneck on meek-azure: https://lists.torproject.org/pipermail

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread A. Johnson
> I think new users might not appreciate the difference between similarly named > terms and then choose the wrong one to their detriment. It seems better that > they should later learn of shared technology that's not clear from the naming > differences than be surprised by differences in securi

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread Aaron D. Jaggard
> On Apr 20, 2015, at 1:40 PM, Paul Syverson wrote: > > On Mon, Apr 20, 2015 at 01:05:16PM -0400, A. Johnson wrote: >>> This is another reason why [modifier] onion service is >>> problematic; it will almost certainly get shortened in use, just >>> as location-hidden service did. >> >> The obv

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread Speak Freely
Whether it's public/fast/direct or hidden, they are both Must-Tor services. You can't get away from that basic requirement. Tor Services, being either Fast/Direct/Public or Hidden/Onion, could be the generic term for either. It would get away from any possibility of what OS is - Onion Service vs.

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread Paul Syverson
On Mon, Apr 20, 2015 at 01:05:16PM -0400, A. Johnson wrote: > > The problem with "fast", "direct", and maybe "bare" is that they > > describe some property we're trying to provide with these. Like > > hidden, I think the chance that they will evolve or be applied in some > > way for which these ter

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread A. Johnson
> The problem with "fast", "direct", and maybe "bare" is that they > describe some property we're trying to provide with these. Like > hidden, I think the chance that they will evolve or be applied in some > way for which these terms won't apply is too great. I disagree in general. Hidden service

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread Paul Syverson
On Mon, Apr 20, 2015 at 08:51:59AM -0400, A. Johnson wrote: > >> > >> Why not simply "onion service"? > > > > Because we have already started using "onion service" to cover what we > > previously called "hidden services” > > Right. > > > My latest thinking about the terminology is that we shoul

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread A. Johnson
> Following on Aaron's suggestion, and further pushing my own wee agenda, > what about PS? it works because even if someone confused the acronym for > something else, it still works. And it matches well with HS/OS. > - Public (Onion) Service > - Peeled (Onion) Service > - Pseudo (Onion) Service <--

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread Speak Freely
Following on Aaron's suggestion, and further pushing my own wee agenda, what about PS? it works because even if someone confused the acronym for something else, it still works. And it matches well with HS/OS. - Public (Onion) Service - Peeled (Onion) Service - Pseudo (Onion) Service <-- I like this

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread A. Johnson
>> >> Why not simply "onion service"? > > Because we have already started using "onion service" to cover what we > previously called "hidden services” Right. > My latest thinking about the terminology is that we should call them > something like "client side onion service" (CSOS, suggested > pr

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

2015-04-20 Thread Paul Syverson
On Mon, Apr 20, 2015 at 12:04:24AM +0200, Moritz Bartl wrote: > Thanks George! > > On 04/09/2015 08:58 PM, George Kadianakis wrote: > > - We really really need a better name for this feature. I decided to > > go with "Direct Onion Services" which is the one [...] > > Why not simply "onion servi

Re: [tor-dev] Website Fingerprinting Defense via Traffic Splitting

2015-04-20 Thread Daniel Forster
Hi Marc, your plans for the wfpadtools framework sound really interesting. An evaluation framework of website fingerprinting defenses would be really useful! I would be happy to use it to evaluate the splitting/padding approach. Like you and Mike said, I have to implement the splitting in Tor fir

Re: [tor-dev] Website Fingerprinting Defense via Traffic Splitting

2015-04-20 Thread Daniel Forster
On Jan 7, 2015, at 9:13 PM, Mike Perry wrote: > I think regardless of our current entry guard choice (which is governed > by the consensus and subject to relatively easy change, btw), having a > datapoint on how traffic splitting affects Website Traffic > Fingerprinting accuracy would be a very