Hi guys, What you explained is a little over my head. Also my capacities are very limited at the moment. I will look into it, soon!
Thanks S l.m: > Hi teor, > > You could run TorBirdy through its own instance of the tor client > software, with a separate socks port. > > This would avoid many of the issues you're trying to work around in > b) and c), as TorBirdy could happily send NEWNYM to its own client > instance all it liked. There is a slightly increased network load > involved in running two instances, and there could be security > implications of running separate tor clients - but mainly if their > connections are distinguishable. > > teor > > Good point. Then again you can do that with any application and tor. > The main motivator is the use case for shared tor process. Tor itself > encourages this use case by supporting multiple socks ports and > isolation flags. Is it reasonable to expect everyone to run multiple > tor processes to isolate the NEWNYM signal? It also raises the > question of *how* they would issue the NEWNYM signal. A patch would > involve adding a simple controller to TorBirdy. In some use cases it > probably isn't even a concern to share NEWNYM. That is sometimes just > a NEWNYM is fine, ignoring the problem of changing exit. So if a patch > were created it should support both use cases: issue a NEWNYM or > emulate it for shared use-cases? > > I think it might be too much to ask a tor process to issue NEWNYM to a > specific isolation context. But given the shared-process use case is > encouraged--is this a preferable solution? > > --leeroy > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk