[tor-bugs] #33291 [Core Tor/Tor]: Making the tor library size smaller

[Tor Bug Tracker & Wiki]

#33291: Making the tor library size smaller
--------------------------+------------------------
 Reporter:  gaba          |          Owner:  (none)
     Type:  project       |         Status:  new
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-size      |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------

Comment (by teor):

 Replying to [ticket:33291 gaba]:
 > {{{
 > Now, distribution size is thing for sure, the second is amount of space
 on disk when
 > it is unpacked and running. Users of inexpensive phones  with limited
 storage will often
 > scroll through installed apps and look at actual storage size being
 used, and uninstall
 > apps based on that. This means we should be concerned with both
 distribution size an
 > runtime total storage use.
 > }}}

 Tor also downloads directory documents at runtime. Last time I checked,
 the extra storage was 5-10MB.

 Here are some things we could do to reduce that size:
 * store directory documents compressed, and uncompress them when we want
 to parse them
   * this change uses more CPU, but less disk
   * our directory mmap() changes reduced RAM usage, they may make
 compressed directory documents a bit harder. Does android use Tor's
 mmap()?

 >
 > '''Possible routes'''
 >
 >  1. making different parts of tor more optional/modular (like relay
 mode, dirauth mode) . Did we try this before? Is this possible?

 Yes, we created a relay module as part of Sponsor 31, and did
 more work on the existing dirauth module.

 But there's still a lot of relay-only code that we could move into
 the relay module.

 And there is a lot more lower-level code that clients never use.
 We could put it in the relay or dirauth modules, or make more
 modules as needed.

 I'll also do a small amount of relay module work as part of
 Sponsor 55, when adding new features, or modifying existing
 code.

 I suggest that other sponsored work adopts a similar policy.

 We can also continue to move config and control code into the
 relay module, as a separate project.

 And we should continue to delete old, unused code, particularly
 code for obsolete options. There's a large amount of IPv6
 DirPort code in tor that we could delete right now.

 >  2. Is there a TLS stack you can link on android? Only in Java

 Does Orbot / Tor Browser for Android use NSS?
 If so, we can use NSS in tor, rather than OpenSSL.

 Do we need to migrate some PTs off OpenSSL as well?

 >  4. A small java implementation of core onion routing. Would
 applications be able to run it?
 >
 >  * java ones, easily
 >  * other ones with some (considerable?) effort. JNI makes it possible,
 but not necessarily so easy.

 Any re-implementation of tor will probably be
 distinguishable on the network. That's ok, as long as
 enough users are running it.

 But a re-implementation will also come with its own
 bugs, privacy issues, and security issues. And its
 own costs for testing and release management. We
 should think about whether we want to maintain
 two parallel implementations, because that's a huge
 cost.

 As an alternative, we could rewrite tor's client and
 common code in Rust. We could use this Rust code
 in tor on relays, desktops, and mobile.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33291#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online