Thus spake Robert Ransom (rransom.8774@xxxxxxxxx): > On 8/28/12, adrelanos <adrelanos@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk