[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:

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 pronunciation

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 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 service?

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 mikepe...@torproject.org 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

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

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 -- I

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 should call them

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 terms won't

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 Aaron D. Jaggard
On Apr 20, 2015, at 1:40 PM, Paul Syverson paul.syver...@nrl.navy.mil 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.

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 security