Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:33:13Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31701Reachability tests for new obfs4 bridges2020-06-13T18:33:13ZCecylia BocovichReachability tests for new obfs4 bridgesAs a follow up to #29279, we can now set up some new reachability tests on a subset of the bridges we've gotten through our bridge campaign \o/
We probably don't want to test all of the new bridges in case these tests cause a bunch of b...As a follow up to #29279, we can now set up some new reachability tests on a subset of the bridges we've gotten through our bridge campaign \o/
We probably don't want to test all of the new bridges in case these tests cause a bunch of bridges to get blocked when they otherwise wouldn't.
As mentioned in [#29279:comment:9](https://trac.torproject.org/projects/tor/ticket/29279#comment:9), we should sample bridges from our various distribution mechanisms (email, private, and HTTPS), and also from any finer grained partitions we have (email provider, subnet, etc.).Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/34260Make BridgeDB take into account its BlockedBridges table2020-06-13T18:30:04ZPhilipp Winterphw@torproject.orgMake BridgeDB take into account its BlockedBridges tableBridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at #34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://gitweb.torpr...BridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at #34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/bridges.py?id=2ccf7ef9dee07c0d645a5dfed5b099678c243fc5#n936)) but we still have to make it process BlockedBridges and take it into account when handing out bridges.https://gitlab.torproject.org/legacy/trac/-/issues/34116Set up OONI's MetaDB on polyanthum2020-06-13T18:30:03ZPhilipp Winterphw@torproject.orgSet up OONI's MetaDB on polyanthumAs part of #32740, we need to sync OONI's test results with BridgeDB's SQLite database; in particular its BlockedBridges table. [Over here](https://trac.torproject.org/projects/tor/ticket/32126#comment:4) and [here](https://github.com/oo...As part of #32740, we need to sync OONI's test results with BridgeDB's SQLite database; in particular its BlockedBridges table. [Over here](https://trac.torproject.org/projects/tor/ticket/32126#comment:4) and [here](https://github.com/ooni/backend/issues/396#issuecomment-620611456), hellais suggested to set up a copy of OONI's MetaDB and have it sync with their canonical database. We can then use our local copy on polyanthum to update BridgeDB's SQLite database.
Instructions for setting up a MetaDB are available at:
https://github.com/ooni/sysadmin/blob/master/docs/metadb-sharing.mdPhilipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32740Implement a feedback loop between BridgeDB and OONI2020-06-13T18:29:55ZPhilipp Winterphw@torproject.orgImplement a feedback loop between BridgeDB and OONIBridgeDB is unaware of where its bridges are blocked. This means that if bridge 1.2.3.4 is blocked in Iran, BridgeDB will still hand it out to users from Iran, who will find themselves unable to use the bridge.
To fix this problem, we s...BridgeDB is unaware of where its bridges are blocked. This means that if bridge 1.2.3.4 is blocked in Iran, BridgeDB will still hand it out to users from Iran, who will find themselves unable to use the bridge.
To fix this problem, we should implement a feedback loop between BridgeDB and OONI. BridgeDB should hand the bridge 1.2.3.4 to OONI and have it tested in as many countries as possible. The result should then make it back to BridgeDB, so BridgeDB knows that 1.2.3.4 shouldn't be handed out to people in Iran.
OONI already has GitHub issues for this project:
* https://github.com/ooni/orchestra/issues/51
* https://github.com/ooni/orchestra/issues/68
There are several open questions:
* How does BridgeDB share a bridge with OONI?
* How should BridgeDB decide what bridges it wants tested, and how often?
* How should OONI's test results feed back into BridgeDB?
* How can we implement this feedback loop without making bridges easier to enumerate?Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28531Publish a snapshot of what PTs are needed for successful Tor use in each country2020-06-13T18:29:47ZRoger DingledinePublish a snapshot of what PTs are needed for successful Tor use in each countrySeveral countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic curre...Several countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic currently, e.g.:
* OONI has "vanilla Tor" measurements in some countries.
* We have anecdotal stories from talking to users in various places.
* There's the censorship wiki: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki (#6149)
* metrics-timeline has something similar: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline
* And the Berkeley folks wrote up their own Tor censorship timeline: https://www.icsi.berkeley.edu/~sadia/tor_timeline.pdf
But what is the situation, this month, in every country? Which ones block the Tor directory authorities, which ones block the public relays, which ones block the default (i.e. included in tor browser) bridges, which ones enumerate bridges from bridges.torproject.org and block them by IP address, which ones use DPI to detect and cut various pluggable transport connections, which ones throttle protocols they don't want, etc?
When Venezuela's CANTV ISP did their IP address based blocking, they also blocked the default obfs4 bridges, which led to confusion and then unfortunate headlines like the one from Access: "Venezuela blocks Tor". (Tor worked fine if you got a fresh bridge, even a vanilla bridge.)
In Taipei I talked to some central asia experts who told me about how Tor only works in a degraded way in Belarus in the default configuration "because a few years ago they blocked all the relay IP addresses, but they haven't updated their block since then".
We need up-to-date information about Tor blocking to provide advice to our users when they ask for support, and also we want it for preemptively including good advice in Tor Launcher's UI. Knowing historical trends will help us prioritize the development of new pluggable transports vs new distribution methods of existing transports.
So, how do we get this information?
One option is that in the glorious future, the standard OONI decks will have all of these tools built-in. But that future is a long way off, and maybe it should never even arrive, since some Tor transports are huge and have no business being bundled into a little mobile testing app.
I think we instead want some combination of the following two plans:
* We have on-the-ground contacts in many countries, and it's often not just individuals but whole NGOs full of Tor enthusiasts. We should pull together our knowledge of who we know in each place, and ask them what they think the current situation is in their country, and talk to them regularly. We can prioritize the various countries that we think were, are, or might be trying to block Tor. Having these on-the-ground experts is going to be necessary no matter what else we add to the plan, and it's why I picked 'community outreach' as the ticket component.
* We should build automated tools to assist people in assessing Tor censorship on their network -- to increase the accuracy of reports that we get, and to make the reports come with actual data that we can compare over time. This idea is #23839.
This ticket is for pulling together one big-picture report. But once we have one, we will want to find ways of keeping ourselves up to date over time.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.org