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