Thus spake Robert Ransom (rransom.8774@???):
> On 8/28/12, adrelanos <adrelanos@???> wrote:
>
> > I really think before you activate IsolateDestAddr/Port for web, Nick's
> > or Roger's option is required.
>
> Nick or Roger would say no. But they are planning to specifically
> leave those options disabled for the web browser. (That's what
> “enabled by default (but for the web browser)” meant.)
Here's the ticket for implementing Tor Browser's use of the circuit
isolation feature:
https://trac.torproject.org/projects/tor/ticket/3455
Summary: we plan on using some variation of the "url bar isolation"
property from
https://www.torproject.org/projects/torbrowser/design/#privacy to guide
our circuit reuse implementation. So long as the url bar stays the same,
we'll use the same circuit for sure. This shouldn't be *too* tricky to
do using mozIThirdPartyUtil.
I'm still debating if we should *also* try to track user
click-nagivation, and use the same circuit so long as the user is
clicking on links (as opposed to entering a fresh new value in the URL
bar). This could be modeled by tracking the referer, or the last url bar
domain to be entered. This will be trickier to implement, but will
reduce client circuit creation.
Either route will require a patch to Firefox, since it is not possible
to set SOCKS usernames+passwords from a .xpi right now.
Roger also wants to turn this into a research project of some kind to
determine the optimal circuit isolation mechanism network-wide, but that
seems like a waste of time to me, since what I'm proposing doesn't
strike me as very resource-intensive in the common case. I'm open to
suggestions on how to make it less painful, though.
--
Mike Perry
