BridgeDB issueshttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues2021-07-15T17:32:56Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40023Go through process of distributing private bridges2021-07-15T17:32:56ZPhilipp Winterphw@torproject.orgGo through process of distributing private bridgesOver at legacy/trac#31872, we created a process for distributing private bridges to NGOs:
https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam/NGOBridgeSupport
It's now time to go through this process with a non-tr...Over at legacy/trac#31872, we created a process for distributing private bridges to NGOs:
https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam/NGOBridgeSupport
It's now time to go through this process with a non-trivial number of censored users. Once we did, we need to document our experience and iteratively improve the process.Sponsor 30 - Objective 2.3GusGushttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40019change email distributor to provide obfs4 transport by default2022-07-18T20:33:30Zmeskiomeskio@torproject.orgchange email distributor to provide obfs4 transport by defaultCurrently if a transport is not specified the email distributor will provide a vanilla bridge. Maybe we should provide a obfs4 by default.Currently if a transport is not specified the email distributor will provide a vanilla bridge. Maybe we should provide a obfs4 by default.Sponsor 30 - Objective 2.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40012run the tests on the gitlab CI2022-07-18T20:33:31Zmeskiomeskio@torproject.orgrun the tests on the gitlab CILet's run the tests on the CI.
We can get some inspiration for the docker image on @cohosh's bridgebox: https://github.com/cohosh/bridgeboxLet's run the tests on the CI.
We can get some inspiration for the docker image on @cohosh's bridgebox: https://github.com/cohosh/bridgeboxSponsor 30 - Objective 2.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40011"Just give me bridges!" should use the default transport of the Advanced Options2021-07-16T10:08:40Zsajolida"Just give me bridges!" should use the default transport of the Advanced OptionsCurrently:
- The "Just give me bridges!" button gives me vanilla bridges.
![Screenshot_from_2021-04-10_18-32-31](/uploads/aa0cf0a9387a67712f04e09bc0bcf162/Screenshot_from_2021-04-10_18-32-31.png)
- The "Get Bridges" button in the Adva...Currently:
- The "Just give me bridges!" button gives me vanilla bridges.
![Screenshot_from_2021-04-10_18-32-31](/uploads/aa0cf0a9387a67712f04e09bc0bcf162/Screenshot_from_2021-04-10_18-32-31.png)
- The "Get Bridges" button in the Advanced Options gives me obfs4 bridges by default.
I think that both should give the same type of bridges by default, currently obfs4.
I'm also unsure whether offering vanilla bridges is useful in the Advanced Options. According to [metrics.torproject.org](https://metrics.torproject.org/userstats-bridge-transport.html?transport=!%3COR%3E&transport=obfs4&transport=%3COR%3E) vanilla bridges are only marginally used. So maybe you should consider not serving them anymore on bridges.torproject.org.
Tell me if you prefer tracking this in a separate issue.Sponsor 30 - Objective 2.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40008Attach the QR code of bridges in the email sent by bridges.torproject.org2021-05-13T13:54:02ZsajolidaAttach the QR code of bridges in the email sent by bridges.torproject.orgAt Tails we are working on usability improvements for people trying to use bridges in Tails.
Someone who tries to hide to their local network that they are using Tails might still be fine with sending an email to bridges@torproject.org ...At Tails we are working on usability improvements for people trying to use bridges in Tails.
Someone who tries to hide to their local network that they are using Tails might still be fine with sending an email to bridges@torproject.org from the Gmail on their smartphone.
obfs4 bridges require the `cert=` part of the bridge line to be typed in order for the bridge to work.
That's not something that people will be happy to type from their smartphone into their Tails. While scanning the (quite big) QR code from bridges.torproject.org using a webcam in Tails works.
Could bridges@torproject.org attach the QR code to the email, so that Tails users could scan their bridge lines into their Tails using the webcam?
If that sounds like a good idea:
- It's definitely not urgent on our side as we would have to integrate the QR code scanning in Tails first.
- I would be happy to help you rephrase the email to clarify this new possibility to users.
- We might try to submit a patch ourselves.Sponsor 30 - Objective 2.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34260Make BridgeDB take into account its BlockedBridges table2022-07-24T17:07:58ZPhilipp 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 legacy/trac#34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://g...BridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at legacy/trac#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.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32900Reimplement and generalise BridgeDB?2020-09-02T18:05:21ZPhilipp Winterphw@torproject.orgReimplement and generalise BridgeDB?Over at legacy/trac#30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking...Over at legacy/trac#30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking about a rewrite of BridgeDB. Here's how I see the (dis)advantages breaking down:
Disadvantages:
* Re-implementations are never as smooth and straightforward as anticipated. It will take a lot of time.
* We won't (easily) be able to use Stem to parse bridge descriptors. We could extend [zoossh](https://gitweb.torproject.org/user/phw/zoossh.git/) though.
Advantages:
* We could re-implement the service in golang because the anti-censorship team is comfortable in the language.
* We could generalise the concept of BridgeDB: What goes in should be an abstract type of proxy (be it bridge descriptors, snowflake-style proxy registrations, or maybe even Lantern proxies) and distributors (as we already have them in BridgeDB) determine who gets these proxies.
* We would design the service with redundancy and "containerisation" in mind.
* It would make it easier to add new features, especially significant ones, like a new distributor.
* A re-implementation may be a return on investment and save us time in the long run.
Note that we don't need to abandon BridgeDB and then redirect our focus to its re-implementation. I would instead like to spend some hours experimenting with a new design in parallel to maintaining BridgeDB. We also don't need to aim for a feature-complete replacement of BridgeDB. For example, we don't need to PGP-sign emails. If all of the above proves fruitful, we can gradually transition to the new design.
Thoughts? Any other features or architectural changes we should make in a re-implementation?Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32740Implement a feedback loop between BridgeDB and OONI2020-10-29T17:58:29ZPhilipp 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?
Child issues:
* tpo/anti-censorship/bridgedb#34116
* tpo/anti-censorship/wolpertinger#34212
* tpo/tpa/team#34089
* tpo/anti-censorship/bridgedb#34260
* tpo/anti-censorship/wolpertinger#34259
* tpo/anti-censorship/wolpertinger#34195Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31873Implement the Salmon bridge distribution mechanism2020-09-02T17:52:43ZPhilipp Winterphw@torproject.orgImplement the Salmon bridge distribution mechanismBridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is prob...BridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is problematic because bridges.torproject.org is blocked in most places that matter and our CAPTCHA is good at keeping out users (legacy/trac#29695) but not so good at keeping out bots (legacy/trac#31252). Moat remains relatively useful because it uses domain fronting but it also relies on a CAPTCHA to fight off bots.
It's time to think about new and/or significantly improved bridge distribution methods. How can we get bridges into the hands of users while making it difficult for adversaries to get them all? How can we make BridgeDB's CAPTCHA more resistant against bots and easier for users?
The Salmon bridge distribution system (first presented in a [PETS'16 paper](https://censorbib.nymity.ch/#Douglas2016a)) is promising. Let's use this issue to build a prototype and fill in the missing pieces to get Salmon deployed.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31280O2.3 - Develop new and/or improve existing bridge selection and distribution ...2020-11-20T16:28:19ZGabagaba@torproject.orgO2.3 - Develop new and/or improve existing bridge selection and distribution strategies.* A1 - Develop new and/or improve existing bridge selection and distribution strategies based on data collected about successful, effective methods per evaluation during O1.1.
* A2 - Develop methods to present bridges to users based on t...* A1 - Develop new and/or improve existing bridge selection and distribution strategies based on data collected about successful, effective methods per evaluation during O1.1.
* A2 - Develop methods to present bridges to users based on their location, potentially incorporating relevant censorship data published by OONI.
* A3 - Improve ability for bridgedb/authority to test bridges that only expose a pluggable transport.
* A4 - Update bridgeDB/gettor to give region-specific recommendations for PT and bridges.
[Milestone](https://gitlab.torproject.org/groups/tpo/-/milestones/5)Sponsor 30 - Objective 2.3Gabagaba@torproject.orgGabagaba@torproject.org