On 5/2/15, coderman wrote:
> ...
> we're soliciting feedback as part of a go / no-go decision on
> continuing this effort.
>
> in particular, the design is intended to meet the scrutiny of Nick M.,
> Roger, and Mike P. as the focus on support for Tor Browser and Tor on
> each client indicates...
On 5/4/15, Mike Perry wrote:
> ...
> In my opinion, the most interesting use case for these devices is where
> Tor Launcher implements a peering mechanism whereby the user can click a
> button at some point in the initial connection wizard that says "My
> Router Knows My Tor Configuration."
hi Mi
On 5/4/15, Mike Perry wrote:
> ...
> In my opinion, the most interesting use case for these devices is where
> Tor Launcher implements a peering mechanism whereby the user can click a
> button at some point in the initial connection wizard that says "My
> Router Knows My Tor Configuration."
>
> Wh
coderman:
> 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
On 5/4/15, coderman wrote:
> ...
> this deserves a longer answer, but you're right. if the attacker is
> using Tor itself a Tor enforcing gateway can't protect against those
> attacks.
i have updated the document to make this more clear.
it is hard to express the nuance of vulnerability here. fo
On 5/4/15, Leif Ryge wrote:
> ...
> So, unlike a transparent tor router, this system is not intended to prevent
> malicious software on client computers from being able to learn the client
> computer's location, right?
hello Leif!
this deserves a longer answer, but you're right. if the attacker
On Sat, May 02, 2015 at 08:37:17PM -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]
So, unlike a transparent tor router, this system is not intended to prevent
malicious software on client computers from
On 5/3/15, teor wrote:
> ...
> Some users will want as little logging as possible, as it can lead to
> privacy leaks if the device is compromised - may I suggest you turn it off
> by default?
you are correct; the default should be no logging. i have updated the
document, and noted that any loggin
> 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
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
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 intended to meet the scrutiny of Nick M.,
Roger, and Mike P. as
14 matches
Mail list logo