Hi Nick:
- Using process isolation to isolate Tor from its controllers makes it
easier to tell Tor bugs from controller bugs....
- Using process isolation to isolate Tor from its controllers can also
make it easier to secure each of the two domains properly against bugs in the other, especially if you're using OS or VM sandboxing features.
This is a point I think is valid to consider. Thanks for pointing it. However a library is not equal to lack of process isolation. I could have the application (for instance the browser) launch a process being a thin layer around the library and exchange data using some IPC mechanism. That could be a future step.
plus maybe another library that would find a running Tor or launch one as needed.
Is there a standard way of doing this? If not maybe would be good idea to define it. A way to know if Tor is running and the listening interfaces/ports. Authenticating it if possible, I would not like to have malware pretending to be Tor and have it easily steal all my network traffic because of this. Perhaps finding the binary somehow and check the hash? And avoid malware using Tor as a presentation key to then shut it down and replace it. Good questions I think. Maybe this should be just configurable by end user instead of doing it automatically until they are answered.
If platform dependent I think could be defined for each platform.
That way we wouldn't have a huge pile of apps all stuck downloading their own directory information
I have no intentions to drop cached information, I actually pretend to share it as much as possible. Ok is not a perfect world, some will happen. Maybe this could be defined as well to allow diverging implementations filling other niches than Tor, share already downloaded data or refresh it in a cooperative way.
Nonetheless, people keep wanting to do it the way you suggest, and it's free software, so do what you like.
Correct, freedom of choice ;). Other ppl is not able to decide what's best for me! Anyways recommendations are always welcome.
Regards Waldo