Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 328
    • Issues 328
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 32
    • Merge requests 32
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #32823
Closed
Open
Issue created Dec 20, 2019 by eighthave@eighthaveContributor

support Android SharedPreferences xml as a torrc format

With Tor Browser, Orbot, and other apps on Android, some Tor settings are managed via the SharedPreferences/PreferenceFragment Android classes. When used in their standard setup, these handle the whole lifecycle of preferences. Right now, we have to do a lot of tricks to get the settings from the Android classes, convert them to torrc format, then handle reloading Tor at the right time.

Android's SharedPreferences writes out to a standard xml file, e.g /data/data/org.torproject.android/shared_prefs/org.torproject.android_preferences.xml. This XML file has a simple format that has been the same since the beginning. If Tor can read this format as an optional torrc format, and also potentially automatically reload the config when that file changes, then the Android code will be drastically simpler. This will greatly improve the interaction around any kind of user-facing setting, like bridges, exit countries, pluggable transports, etc.

Here's an example of what the XML would look like:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <boolean name="RunAsDaemon" value="true" />
    <boolean name="AvoidDiskWrites" value="true" />
    <string name="TransPort">auto</string>
    <int name="DNSPort" value="5400" />
    <string name="TransPort" value="auto" />
    <string name="Bridges">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0,obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0,meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>

We might want an alternate format for bridge lines, where would be a dedicated XML file for only bridge lines with the name specifying the line number:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="0">obfs4 77.81.104.251:443 115C90EBD0EB631C177560A872535772215478D9 cert=UsuF7oN4KNKviZP54JOyTCoCphrdM5gwZK4vT8GnCAcmqLUJEJxyw1dpko9a/ii6He4iZg iat-mode=0</string>
    <string name="1">obfs4 5.249.146.133:80 FAF3A0073330D6AD92F3B4874B0D945562A633EF cert=TRe8bAODtjcGij7EPQaUayWEOqR99wDh2l3B4hFtCsn1JTJCph03pRZ9tx8wynpLYKWMQg iat-mode=0</string>
    <string name="2">meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com</string>
</map>

Yxml is a 6k C XML parser in a single file under an MIT license. It has been maintained since 2013. It would fit the bill quite nicely. https://dev.yorhel.nl/yxml

Yes, XML is not an ideal format. We don't need the most problematic parts of XML for this, e.g. namespaces, custom entities, etc. and Yxml does not support them anyway.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking