Opened 5 months ago

Last modified 4 weeks ago

#23684 new enhancement

Make it easier for mobile app developers to embed tor

Reported by: hellais Owned by:
Priority: Medium Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-mobile, s8-api
Cc: darkk, brade, mcs, sbs, mtigas Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor8


The use-case that we are trying to improve is the following:

I am mobile app developer and I want to use Tor as part of my software and possibly instrument it in some way via it's control port.

See also:

The current situation of Tor integration on mobile platforms is a bit suboptimal. The best solution would allow developers to "execute" Tor in the same way on all platforms uniformly.

Currently the approaches taken for integrating Tor into mobile apps is one of two:

a) Tor is started as a process and the user speaks to it via the control port (this is only possible on Android though).
Example: OrBot

b) The tor main() is wrapped and is called as part of some wrapper library written in the platform native language (this approach is the most common one on iOS).
Example: Tor.Framework, CPAProxy

Both of these approaches are not the easiest from a mobile app developers perspective.

To make the developer experience easier, it would be best if some of the following things happened:

  1. The build process of tor allowed you to also get a shared library
  1. There is some API call or function that is documented and supported officially by the Tor library (1.) that allows the developer to start and stop tor.

If these two things were supported in tor natively, it would be possible to pack tor as a gradle and cocoapod dependency (which is the way in which mobile developers usually add dependencies to their project).

The other problem is related to usage of pluggable transports, which tor expects to be able to fork and start them and is something that we cannot do on iOS.

I suggest we can use this as a master ticket to track all the various improvements that are needed and attach child tickets for the various units of work that this can be split up into.

Child Tickets

#23845enhancementclosednickmDocument a stable tor main function
#23846enhancementnewUse libtool for building shared library
#23847enhancementnewMake sure Tor can shut down via control port, and start again in same process
#23848enhancementclosednickmReplace all exit() calls with return code style
#23900enhancementclosednickmLet programs call tor_main with a preconstructed control socket
#24204defectacceptednickmImprove the in-process Tor API: create owning control port
#24588defectclosednickmMake signal handlers optional, for starting Tor in-process

Change History (11)

comment:1 Changed 5 months ago by mcs

Cc: brade mcs added

comment:2 Changed 5 months ago by dgoulet

Keywords: tor-mobile added
Milestone: Tor: unspecified

comment:3 Changed 4 months ago by hellais

Here is the branch simone worked on for fixing the libtool issues:

comment:4 Changed 4 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.4.x-final

comment:5 Changed 4 months ago by hellais

Cc: sbs added

comment:6 Changed 4 months ago by nickm

Sponsor: Sponsor8

comment:7 Changed 4 months ago by ahf

Keywords: s8-api added

comment:8 Changed 4 months ago by mtigas

Cc: mike@… added

comment:9 Changed 4 months ago by arma

Cc: mtigas added; mike@… removed

comment:10 Changed 4 weeks ago by yurivict271

If tor_api.h is now an API header, shouldn't it be installed along with some shared libraries?
I don't see any relevant options in

comment:11 Changed 4 weeks ago by nickm

We haven't settled on a stable library plan yet. This is still a work in progress.

Note: See TracTickets for help on using tickets.