Hi Everyone,
As part of our Sponsor 30 work, we are looking to improve the new about:torconnect experience by adding automatic tor settings configuration for censorship circumvention.
This document outlines and discusses the *technical* challenges associated with this work, and does not go into any great detail on the right UX would be (in terms of easy of use, user trust, etc).
Anyway, if you see any pitfalls or problems with anything here, do let us know.
------------------------------8<--------------------------------------
# Mostly Automatic Bridge Configuration to Bypass Internet Censorship
Our goal for this work is to enable Tor Browser users to access tor without having to navigate to about:preferences#tor to configure bridges. Technically speaking, this is a trivial problem assuming you know:
- which bridge settings work at the user's location - the location of the user
## Circumvention Settings Map
For now, it seems sufficient to maintain a map of countries to some data-structure containing information about which censorship circumvention techniques work and which ones do not. A proposed example format can be found here:
- https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob...
This map would at be distributed and updated through tor-browser releases.
### Problems
#### Censorship Changes Invalidate the Map
The obvious problem with distributing the censorship-circumvention settings map with Tor Browser is that if the techniques used in a location change such that old settings no longer work, you will be left with a non-functional Tor Browser with no way to update it apart from acquiring a fresh install with the updated settings or by manually configuring Tor Browser's bridge settings (so what users have to do now)
A fix for this would be to provide a rules update mechanism whereby updated rules could be fetched outside of tor (via the clearnet, or over moat). Special care would need to be taken to ensure the rule updates from this automatic mechanism actually came from the Tor Project (via some sort of signature verification scheme, for example).
Another wrinkle here is that rules would also need to be distributed somewhere that is difficult to censor. It seems likely that we may need different locations and mechanisms for acquiring the rule-set based on the user's location.
Whatever the mechanism, updates should happen at least before the user attempts to auto-configure. Otherwise, perhaps we should periodically auto-update the the settings at a reasonable cadence.
#### Time Investment to Update Map
Another problem with solely distributing the rules through Tor Browser, is that censorship events would now require a Tor Browser release just to push new rules out to people. Publishing new Tor Browser releases is not a simple task, and enabling adversaries to force Tor Browser releases by tweaking their censorship systems seems like a cute way to DDOS the Applications team.
An alternate update channel is definitely necessary outside of periodic Tor Browser releases.
#### Are Per-Country Entries Granular Enough?
One could imagine highly localized censorship events occurring which require special settings that are not needed in the rest of the country. For instance, if there is a clearnet blackout in Minneapolis, would we want to pipe *all* of our US users through the same bridges? Seems like a potential scalability problem for countries with large populations.
## Determining User Location
A user's location can be determined by accessing location services through the clearnet. Mozilla offers a such a service ( https://location.services.mozilla.com/ ) with a very simple HTTP interface. Prior to bootstrapping, Tor Browser can access the location service by temporarily enabling network DNS:
- network.dns.disabled=false
and making an exception for the location service URL to bypass the proxy by:
- network.proxy.no_proxies_on="location.services.mozilla.com"
The location service would send back a country code in a JSON object which we can use to look up appropriate bridge settings in our map described above.
### Problems
So the functionality of this approach is pretty easy to implement: tweak some prefs, make an XMLHttpRequest, change the prefs back.
One possible problem we may face is if censors start blocking Mozilla's location services. Maybe we should have a pool of location service providers to make this more difficult (though we would need to do the research and figure out how feasible this is from a cost perspective).
It is also possible to add location service functionality to moat, though this would also be a bit of an engineering endeavor.
If we move forward with Mozilla's location services, we will need to acquire an API key, but I would not expect this to be an issue. We will also need to make arrangements with them to surpass the current limit of 100,000 daily API requests ( see: https://location.services.mozilla.com/terms )
The big challenge here is engineering the right UX which maintains our users trust. I think we need to be very explicit with this convenience feature, and definitely not just have it silently happen in the background. Users should also be able to opt-out, and manually select their country for the purposes of getting the right settings out of the above mentioned map.
It should be very difficult to accidentally enable this automatic lookup. This will likely require a fair bit of iteration on the about:torconnect page design and flow.
## Circumvention Settings Map
Do we ever see FallbackDirs censored but relays not? Not sure if that's useful.
It seems like this entire data structure could be condensed into a very small format (2 bytes per country; maybe even 1 byte if you dropped a few things). 2 bytes per country-name; 4 countries and right now it's 16 bytes. That's small enough to fit in a standard 256-bit random nonce or counter, smuggled inside a cryptographic protocol like TLS. Or put into a DNS TXT record.
#### Time Investment to Update Map
Updating such a file is the exact purpose of the Remote Settings feature of Firefox: https://firefox-source-docs.mozilla.org/services/settings/index.html
I'm sure Tor is loath to run additional infrastructure on top of the update server but... this exists. I think one Remote Settings bucket is enabled by Tor Browser? Maybe OneCRL? (Or maybe I'm thinking of Addon-Blocklist which I don't think is Remote Settings....)
Mozilla might be able to host this _for_ Tor (and Tor devs have the admin control on the bucket) but obviously that would allow some level of control of Tor Browser by Mozilla.
#### Are Per-Country Entries Granular Enough?
It seems like today this problem is not worth trying to address. Seems difficult, and has it ever actually been needed?
## Determining User Location
Doesn't tor ship with a geoip database that can do this given the user's internet-facing IP with some but not perfect accuracy?
-tom
On Thu, 8 Jul 2021 at 12:22, Richard Pospesel richard@torproject.org wrote:
Hi Everyone,
As part of our Sponsor 30 work, we are looking to improve the new about:torconnect experience by adding automatic tor settings configuration for censorship circumvention.
This document outlines and discusses the *technical* challenges associated with this work, and does not go into any great detail on the right UX would be (in terms of easy of use, user trust, etc).
Anyway, if you see any pitfalls or problems with anything here, do let us know.
------------------------------8<--------------------------------------
# Mostly Automatic Bridge Configuration to Bypass Internet Censorship
Our goal for this work is to enable Tor Browser users to access tor without having to navigate to about:preferences#tor to configure bridges. Technically speaking, this is a trivial problem assuming you know:
- which bridge settings work at the user's location
- the location of the user
## Circumvention Settings Map
For now, it seems sufficient to maintain a map of countries to some data-structure containing information about which censorship circumvention techniques work and which ones do not. A proposed example format can be found here:
https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob...
This map would at be distributed and updated through tor-browser releases.
### Problems
#### Censorship Changes Invalidate the Map
The obvious problem with distributing the censorship-circumvention settings map with Tor Browser is that if the techniques used in a location change such that old settings no longer work, you will be left with a non-functional Tor Browser with no way to update it apart from acquiring a fresh install with the updated settings or by manually configuring Tor Browser's bridge settings (so what users have to do now)
A fix for this would be to provide a rules update mechanism whereby updated rules could be fetched outside of tor (via the clearnet, or over moat). Special care would need to be taken to ensure the rule updates from this automatic mechanism actually came from the Tor Project (via some sort of signature verification scheme, for example).
Another wrinkle here is that rules would also need to be distributed somewhere that is difficult to censor. It seems likely that we may need different locations and mechanisms for acquiring the rule-set based on the user's location.
Whatever the mechanism, updates should happen at least before the user attempts to auto-configure. Otherwise, perhaps we should periodically auto-update the the settings at a reasonable cadence.
#### Time Investment to Update Map
Another problem with solely distributing the rules through Tor Browser, is that censorship events would now require a Tor Browser release just to push new rules out to people. Publishing new Tor Browser releases is not a simple task, and enabling adversaries to force Tor Browser releases by tweaking their censorship systems seems like a cute way to DDOS the Applications team.
An alternate update channel is definitely necessary outside of periodic Tor Browser releases.
#### Are Per-Country Entries Granular Enough?
One could imagine highly localized censorship events occurring which require special settings that are not needed in the rest of the country. For instance, if there is a clearnet blackout in Minneapolis, would we want to pipe *all* of our US users through the same bridges? Seems like a potential scalability problem for countries with large populations.
## Determining User Location
A user's location can be determined by accessing location services through the clearnet. Mozilla offers a such a service ( https://location.services.mozilla.com/ ) with a very simple HTTP interface. Prior to bootstrapping, Tor Browser can access the location service by temporarily enabling network DNS:
- network.dns.disabled=false
and making an exception for the location service URL to bypass the proxy by:
- network.proxy.no_proxies_on="location.services.mozilla.com"
The location service would send back a country code in a JSON object which we can use to look up appropriate bridge settings in our map described above.
### Problems
So the functionality of this approach is pretty easy to implement: tweak some prefs, make an XMLHttpRequest, change the prefs back.
One possible problem we may face is if censors start blocking Mozilla's location services. Maybe we should have a pool of location service providers to make this more difficult (though we would need to do the research and figure out how feasible this is from a cost perspective).
It is also possible to add location service functionality to moat, though this would also be a bit of an engineering endeavor.
If we move forward with Mozilla's location services, we will need to acquire an API key, but I would not expect this to be an issue. We will also need to make arrangements with them to surpass the current limit of 100,000 daily API requests ( see: https://location.services.mozilla.com/terms )
The big challenge here is engineering the right UX which maintains our users trust. I think we need to be very explicit with this convenience feature, and definitely not just have it silently happen in the background. Users should also be able to opt-out, and manually select their country for the purposes of getting the right settings out of the above mentioned map.
It should be very difficult to accidentally enable this automatic lookup. This will likely require a fair bit of iteration on the about:torconnect page design and flow.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Richard Pospesel -
Tom Ritter