[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #32823 [Core Tor/Tor]: support Android SharedPreferences xml as a torrc format
#32823: support Android SharedPreferences xml as a torrc format
-------------------------------------------------+-------------------------
Reporter: eighthave | Owner: (none)
Type: enhancement | Status: new
Priority: Medium | Component: Core
| Tor/Tor
Version: | Severity: Normal
Keywords: Android, xml, tbb-mobile, torrc, | Actual Points:
sharedpreferences |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32823>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs