IMO, your improvements make the user experience much worse. The current version
is far more space efficient, your new versions wastes giant amounts of screen
space.
> * There is no super-wide list of relays that doesn't fit even into Tor
> Browser window (panels instead with upstatus indication)
>> 3. Additional RELAY_COMMAND_* types for clients to request out-of-band
>> HMAC request cells for Proposal 253.
Do you need to request that data? How about always sending it from middle
nodes? (Less leakage about the client.)
>> 4. Additional RELAY_COMMAND_* opcodes for clients to request padd
From: Damian Johnson
To: "tor-dev@lists.torproject.org"
Subject: Re: [tor-dev] Let's identify which measurement-related tools needwork
when relays switch from RSA identities to ed25519 identities
Date: Tue, 8 Sep 2015 09:16:15 -0700
> On a side note it would be nice to have a spec patch before
Original Message
From: John Brooks
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Proposal: Single onion services
Date: Fri, 4 Sep 2015 15:31:15 -0600
> tordev...@safe-mail.net wrote:
>
> > Doesn't your proposal imply that you are turning all relays into
> > exit-nodes
Is there some documentation, how the tor-browser git repository is set up?
In particular, how are new Firefox releases imported? How can I get a diff of
Tor changes to the underlying Firefox release?
___
tor-dev mailing list
tor-dev@lists.torproject.org
Doesn't your proposal imply that you are turning all relays into exit-nodes
lite? The last relay in the path will know what service you are connecting to
(at least if that service is hosted with a unique relay), right?
Have you considered all the implications?
___
From: Sharif Olorin
To: tor-dev
Subject: Re: [tor-dev] Should cloud-hosted relays be rejected?
Date: Wed, 02 Sep 2015 08:32:58 +
> > I'm not talking about those providers hosting exit nodes. I'm talking about
> > general web sites and resources hosted by them and the traffic that goes
> >
From: nusenu
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Should cloud-hosted relays be rejected?
Date: Tue, 1 Sep 2015 19:23:35 +0200
> > It has other benefits. Those big providers see a huge amount of exit
> > traffic and can potentially do correlation against that.
>
> I disagree on
From: nusenu
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Should cloud-hosted relays be rejected?
Date: Tue, 1 Sep 2015 00:58:05 +0200
> I don't think banning GCE, AWS and MS Azure is an efficient method to
> significantly increase the cost of attacks because it is trivial for an
> att
Original Message
From: Zack Weinberg
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Remove NULL checks for *_free() calls
Date: Mon, 31 Aug 2015 10:29:31 -0400
> > But you did find some places they forgot to assign NULL after free.
>
> Unfortunately, setting pointers t
Original Message
From: Yawning Angel
Subject: Re: [tor-dev] Number of directory connections
Date: Fri, 21 Aug 2015 16:49:18 +
>> It looks like when the consensus is older than 5 days, a directory authority
>> is used (and the
>> UseEntryGuardsAsDirGuards setting basically
Original Message
From: "l.m"
Subject: Re: [tor-dev] Number of directory connections
Date: Fri, 21 Aug 2015 09:31:25 -0400
> Oh I see, so they happened before. I wasn't sure about that. In that case the
> last consensus stored locally must have been many days old. If that's the
Original Message
From: George Kadianakis
Subject: Re: [tor-dev] Number of directory connections
Date: Fri, 21 Aug 2015 15:02:02 +0300
> There are many unlucky people whose guard is not a directory cache, so they
> have
> to reach out to additional guards to get directory docume
Original Message
From: "l.m"
Subject: Re: [tor-dev] Number of directory connections
Date: Fri, 21 Aug 2015 08:02:22 -0400
> UseEntryGuardsAsDirGuards defaults to 1 in torrc.
>
> So if you did not change this default you will use entry guards for tunneling
> directory connecti
Original Message
From: Mike Perry
Subject: [tor-dev] Proposal: Padding for netflow record resolution reduction
Date: Thu, 20 Aug 2015 21:12:54 -0700
> Tor clients currently maintain one TLS connection to their Guard node to
> carry actual application traffic, and make up to 3 ad
> > zoossh's test framework says that it takes 36364357 nanoseconds to
> > lazily parse a consensus that is cached in memory (to eliminate the I/O
> > bottleneck). That amounts to approximately 27 consensuses a second.
> >
> > I used the following simple Python script to get a similar number for
>
TBB 5.0 Bug 16771 which seems to be causing a lot of crashes was apparently
introduced with commit 77dcb2dfde4bdc1a2f6c399a1173f65908dccd5c on 2015-07-02
(new request isolation feature). The first release including that commit was
apparently TBB 5.0a4 announced 2015-08-03.
So there was only 1 w
17 matches
Mail list logo
