> ## 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 <rich...@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/main/state-of-censorship.json > > 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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev