org/meetings/2015SummerDevMeeting/TorProcessShare.md

-== Sharing One Tor Process Among Many Applications ==
+## Sharing One Tor Process Among Many Applications
 
 These notes are from a session that took place during the Berlin Tor Dev Meeting on the afternoon of 29-Sept-2015 (Tuesday).
 
 Note that solutions may be system/OS dependent, e.g., what makes sense on iOS may not work for Android or the desktop. Due to competing sessions, not much mobile expertise was present, so we mostly discussed desktop issues.
 
-=== The current situation: ===
+### The current situation:
 * Most applications either:
  1. Ship their own copy of tor (e.g., Tor Browser, Ricochet)
  2. Have a dependency on another application (e.g., Tor Birdy asks users to start Tor Browser and leave it running).
@@ -13,7 +13,7 @@ Note that solutions may be system/OS dependent, e.g., what makes sense on iOS ma
  * We do not expect this practice to stop, at least for desktop applications.
 * Orbot does provide "tor as a service" via APIs on Android (several apps developed by the Guardian Project depend on Orbot for their tor).
 
-=== What problems occur when there are many tor processes? ===
+### What problems occur when there are many tor processes?
 * Users need to configure each tor separately, which can be complicated (e.g., when bridges are used).
 * There is more than one guard per system, which is not necessarily desirable.
 * Redundant consensus downloads.
@@ -21,8 +21,8 @@ Note that solutions may be system/OS dependent, e.g., what makes sense on iOS ma
 * More system resources (CPU, memory, etc.) will be used, which is bad (especially on embedded and mobile platforms).
 * [Added by Roger post-meeting: applications that launch their own Tor miss out on system-Tor features like running as a separate user or starting with more file descriptors than a normal user can have. For example, Tor Browser on Linux will never be able to turn its Tor into a useful relay, with the current design.]
 
-=== Possible Solutions for Desktop Systems ===
-==== System Tor ====
+### Possible Solutions for Desktop Systems
+#### System Tor
 * Centrally installed, configured, and managed (like Tails).
 * Needs to be discoverable.
 * Do we assume a standard TCP port or path for a UNIX domain socket (or the Windows equivalent)?
@@ -31,7 +31,7 @@ Note that solutions may be system/OS dependent, e.g., what makes sense on iOS ma
  * Applications could probe via the control port to ensure that the system tor will meet their needs, e.g., Ricochet needs to be able to create hidden services but Tor Messenger may only need Tor-based communication / client access.
 * If the system tor does not provide what an application needs, it could start its own bundled tor daemon.
 * The system tor approach is already being used in Tails and is probably what systems like Debian would prefer.
-==== Shared Tor ====
+#### Shared Tor
 * Each application bundles a tor.
 * Applications do some probing to determine if a tor they can use is already running.
  * Well known control port (or UNIX domain socket path) and cookie auth file path.
@@ -42,11 +42,11 @@ Note that solutions may be system/OS dependent, e.g., what makes sense on iOS ma
  * Sometimes applications patch tor (Tor Browser has a history of doing this).
  * Meek requires a Tor Browser, which means that applications that want to support a meek pluggable transport will have a dependency on Tor Browser anyway.
 
-==== Other Ideas ====
+#### Other Ideas
 * It might be possible to avoid some of the problems associated with having more than one tor by modifying the tor daemon to allow sharing of some state information (e.g., consensus and guard info).
 * It may make sense to take an inventory of what control port access is needed by the applications that we know about, e.g., SETCONF, NEWNYM, ADD_ONION.
 
-=== Next Steps ===
+### Next Steps
 * More discussion among application developers (including iOS/Android) and with core tor developers.
 * Brainstorm possible architectures.
 * Brainstorm solutions to challenging problems (e.g., Tor Browser-specific tor patches, the owning controller issue).