Hi all! My April was split between SoP prep and Nyx. Changes for the later
unfortunately aren't yet ready so this is gonna be a shorter status report
than usual.
Tor Summer of Privacy
-
> Date: Sun, 3 May 2015 12:34:51 -0400
> From: CJ Ess
>
> On Sun, May 3, 2015 at 11:06 AM, teor wrote:
>
>>> Date: Sun, 3 May 2015 02:50:46 -0400
>>> From: CJ Ess
>>>
>>> So I'm doing a bit of an experiment, the idea being that if you have a
>>> group of tor users sharing common infrastructu
> Date: Sun, 3 May 2015 16:23:08 -0700
> From: coderman
>
>> I suggest also adding mandatory audit logging to the scope of the
>> router software. In my opinion any and all state changes, whether
>> automatic (Tor circuit change) or manual (administrator changing
>> configuration) must be logged
On 5/3/15, warms0x wrote:
> ...
> I am bored so I figured I would read this big document, here are some
> comments from somebody who took the time to care:
thanks! :)
> 1.3 > Warning conditions:
>
> Is the "Client privacy leak detected" meaning the software would warn
> in the case of a LAN cl
On Sat, 2 May 2015 20:37:17 -0700
coderman wrote:
> a friend and i are working on a Tor router design that doesn't
> compromise anonymity for convenience. [0][1][2][3][4]
>
> we're soliciting feedback as part of a go / no-go decision on
> continuing this effort.
>
> in particular, the design is
So underlying idea in this case is to pass thru the proxy credentials from
the browser, so they don't have to be had coded in plain text in the tor
config - you exit the browser and the credential goes away (or maybe its
encrypted in the browser password manager), if you change your password you
do
> Date: Sun, 3 May 2015 02:50:46 -0400
> From: CJ Ess
>
> So I'm doing a bit of an experiment, the idea being that if you have a
> group of tor users sharing common infrastructure then its a slightly
> different situation then one lone user, and you wantto emphasize that
> resources should not b
On 5/3/15, intrigeri wrote:
> ...
> Just to clarify, the threat model explicitly doesn't include "Attacker
> is able to reconfigure Tor on a client system to use an arbitrary set
> of bridges", right?
correct.
neither bridges nor pluggable transports are supported. i have added a
FAQ entry for t
Hi,
coderman wrote (03 May 2015 03:37:17 GMT) :
> a friend and i are working on a Tor router design that doesn't
> compromise anonymity for convenience. [0][1][2][3][4]
Thanks!
> please provide feedback in reply on this thread or to me directly.[6]
Just to clarify, the threat model explicitly d
