BridgeDB issueshttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues2022-06-02T16:55:50Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31268Objective O2: Ensure users in target countries have access to the best Tor b...2022-06-02T16:55:50ZGabagaba@torproject.orgObjective O2: Ensure users in target countries have access to the best Tor bridge options for circumventing censorship.Activities under this objective aim to improve aspects of bridge distribution and selection methods. We seek to automate bridge distribution for our users as much as possible, but some distribution mechanisms require minimal user intera...Activities under this objective aim to improve aspects of bridge distribution and selection methods. We seek to automate bridge distribution for our users as much as possible, but some distribution mechanisms require minimal user interaction, like solving CAPTCHAs. One example of an active distribution mechanism that is as automated as possible is “moat,” which is already integrated into Tor Browser. The fact that this distribution method is integrated into Tor Browser minimizes the number of hoops our users have to jump through. When possible, we hope to integrate distribution methods developed in this project into Tor Browser, minimizing the impact on the user. With special focus on human rights defenders in the Global South, we will increase access to Tor bridges and expand the network.
* [x] [O2.1 - Create an evaluation framework and collect data to better monitor and evaluate current bridge selection and distribution processes.](#31274)
* [ ] [O2.2 - Improve user experience and user interface of bridges.torproject.org.](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40020)
* [x] [O2.3 - Develop new and/or improve existing bridge selection and distribution strategies.](#31280)
* [x] [O2.4 - Boost security by increasing the number of bridges run by volunteers and collective entities through improvements to onboarding and better communications.](#31281)
Parent ticket: https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/31265https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/29096Run Moat using ptadapter2022-03-15T15:41:37ZMatthew FinkelRun Moat using ptadapterdcf1 suggests BridgeDB can use ptadapter for running the meek-server for Moat (instead of the current shell script). Sounds great to me.
https://github.com/twisteroidambassador/ptadapterdcf1 suggests BridgeDB can use ptadapter for running the meek-server for Moat (instead of the current shell script). Sounds great to me.
https://github.com/twisteroidambassador/ptadapterhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/29448Provide a dir-spec implementation that serves sanitised descriptors2022-03-01T17:35:40ZirlProvide a dir-spec implementation that serves sanitised descriptorsThe Metrics Team currently performs sanitizing of bridge descriptors before publishing them on CollecTor (and subsequently feeding them into other software).
The published descriptors are detailed in:
https://metrics.torproject.org/col...The Metrics Team currently performs sanitizing of bridge descriptors before publishing them on CollecTor (and subsequently feeding them into other software).
The published descriptors are detailed in:
https://metrics.torproject.org/collector.html#bridge-descriptors
The sanitizing steps are detailed here:
https://metrics.torproject.org/bridge-descriptors.html
The descriptors are transferred to the CollecTor host unsanitized by means of rsyncing a tarball. This violates one of the Tor Metrics principles in that this is a private interface and we are handling sensitive data. While the data is then sanitized and published, it is not possible for others to operate their own CollecTor instance that fetches data directly from the BridgeDB instance. Additionally, this increases code complexity in CollecTor as now we must treat the fetching of relay and bridge descriptors differently.
Ideally the sanitizing steps would be performed by BridgeDB and then we would be able to reuse (at least large chunks of) CollecTor code that currently fetches relay descriptors.
This is a project that would need co-ordination with the Metrics Team on the best way forward.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/25986Add AMP cache fronting option to Moat2022-03-01T17:35:40ZtwimAdd AMP cache fronting option to MoatThis is a followup of https://trac.torproject.org/projects/tor/ticket/25804#comment:25 (summary):
> It turns out that AppEngine is not the only option for domain fronting with Google.
> Google also provides a service called AMP cache f...This is a followup of https://trac.torproject.org/projects/tor/ticket/25804#comment:25 (summary):
> It turns out that AppEngine is not the only option for domain fronting with Google.
> Google also provides a service called AMP cache for AMP pages. What it basically does is proxying random pages on the Internet and making them load faster (e.g. on Google search results). It requires pages to comply with some format though and also strips invisible content, resizes images, etc.
> Despite it is being served via different domain names (one per real domain) it is still hosted at Google infrastructure which can be fronted.
Related tickets: legacy/trac#25807.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12807Implement an anonymous credential system for BridgeDB's Social Distributor2021-09-09T14:28:51ZIsis LovecruftImplement an anonymous credential system for BridgeDB's Social DistributorBridgeDB's Social Distrubtor is going to need anonymous credentials if it is to safely gather information on bridge usage and/or blockage (used to determine the users' good/bad behaviour). This is briefly touched upon in §5.3.1 of the [r...BridgeDB's Social Distrubtor is going to need anonymous credentials if it is to safely gather information on bridge usage and/or blockage (used to determine the users' good/bad behaviour). This is briefly touched upon in §5.3.1 of the [rBridge paper](https://people.torproject.org/~isis/papers/rBridge:%20User%20Reputation%20based%20Tor%20Bridge%20Distribution%20with%20Privacy%20Preservation.copy%20with%20notes.pdf). I propose implementing and using Camenisch-Lysanskaya 2008 (CL08) credentials, as described in [this paper](https://people.torproject.org/~isis/papers/Randomizable%20Proofs%20and%20Delegatable%20Anonymous%20Credentials.pdf).https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31274O2.1 - Create an evaluation framework and collect data to better monitor and ...2021-07-14T15:45:14ZGabagaba@torproject.orgO2.1 - Create an evaluation framework and collect data to better monitor and evaluate current bridge selection and distribution processes.[Milestone](https://gitlab.torproject.org/groups/tpo/-/milestones/4)
* A1 - Create an evaluation framework for bridge distribution and selection methods.
* [x] tpo/anti-censorship/pluggable-transports/trac#29277
* [x] #31422
* A2...[Milestone](https://gitlab.torproject.org/groups/tpo/-/milestones/4)
* A1 - Create an evaluation framework for bridge distribution and selection methods.
* [x] tpo/anti-censorship/pluggable-transports/trac#29277
* [x] #31422
* A2 - Evaluate distribution and selection methods for human rights defenders in target regions.
* [x] tpo/anti-censorship/censorship-analysis#34153
* A3 - Identify which bridge selection and distribution methods are most used in targeted regions.
* [x] #31871
* [ ] #32276Sponsor 30 - Objective 2.1Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31281O2.4 - Boost security by increasing the number of bridges run by volunteers a...2021-03-11T17:48:30ZGabagaba@torproject.orgO2.4 - Boost security by increasing the number of bridges run by volunteers and collective entities through improvements to onboarding and better communications.* [x] A1 - Improve documentation on how to set up a bridge server and different pluggable transport bridge servers.
* [x] A2 - Create scripts and configuration code for setting up a bridge on cloud providers to make it easier for operato...* [x] A1 - Improve documentation on how to set up a bridge server and different pluggable transport bridge servers.
* [x] A2 - Create scripts and configuration code for setting up a bridge on cloud providers to make it easier for operators to launch a new bridge.
* [x] A3 - Promote workshops on how to set up a bridge at relay operator meetups.
* [x] A4 - Improve documentation of bridgeDB--the code behind selecting and distributing bridges.
* [x] A5 - Increase stability and resilience of bridge authority and bridgeDB by exploring and implementing decentralizations of those services.
[Milestone](https://gitlab.torproject.org/groups/tpo/-/milestones/6).Sponsor 30 - Objective 2.4https://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.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/32117Understand and document BridgeDB bot scraping attempts2020-10-29T17:40:19ZCecylia BocovichUnderstand and document BridgeDB bot scraping attemptsWe are aware of automated attempts to enumerate bridges in BridgeDB, but lack a more rigorous understanding of the problem.
We have detected bot requests from bridgeDB's web interface and deployed some defences by forbidding requests wi...We are aware of automated attempts to enumerate bridges in BridgeDB, but lack a more rigorous understanding of the problem.
We have detected bot requests from bridgeDB's web interface and deployed some defences by forbidding requests with headers that are commonly associated with bots, and handing out fake bridges to suspected bot requests (legacy/trac#31252), and
We also suspect that these bots are solving our CAPTCHAs more accurately than users (legacy/trac#24607).
After a recent campaign to get more volunteer bridges, we set up an experiment to test the reachability of a subset of these new bridges from a probe site in Beijing and found all new bridges in our sample to be blocked (most were blocked from the very start of the experiment): legacy/trac#31701
This ticket is for documenting bot behaviour and brainstorming ways to detect and analyze the automatic scraping of BridgeDB from censor-owned bots.hanneloresxhanneloresxhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31871Identify what bridge selection and distribution methods are most used in tar...2020-10-16T22:24:45ZPhilipp Winterphw@torproject.orgIdentify what bridge selection and distribution methods are most used in targeted regionsAs part of a sponsor 30 deliverable, we need to understand what bridge distribution methods are most used in a given region. We should take several weeks worth of BridgeDB usage metrics, analyse them, and write up a report.As part of a sponsor 30 deliverable, we need to understand what bridge distribution methods are most used in a given region. We should take several weeks worth of BridgeDB usage metrics, analyse them, and write up a report.Sponsor 30 - Objective 2.1Philipp 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/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/4380Complete BridgeDB upgrades phase 12020-06-27T13:43:31ZKarsten LoesingComplete BridgeDB upgrades phase 1This project ticket replaces the milestone "BridgeDB Upgrades Phase 1" and contains all tickets as child tickets that were assigned to that milestone.
(Milestones are the wrong concept here. It's not a milestone of the sort "let's see ...This project ticket replaces the milestone "BridgeDB Upgrades Phase 1" and contains all tickets as child tickets that were assigned to that milestone.
(Milestones are the wrong concept here. It's not a milestone of the sort "let's see which tasks we need to complete before releasing a new BridgeDB version." It's a project with a given scope, and we want to remember which tasks belong to this project.)
Speaking of, which sponsor wants to see this project done, or is it a sponsor Z thing? Maybe we should assign this project ticket to a sponsor milestone, or otherwise we may never finish it.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/4568Extend BridgeDB to give out pluggable transport information2020-06-27T13:43:31ZKarsten LoesingExtend BridgeDB to give out pluggable transport informationWe need to teach BridgeDB to give out pluggable transport information in its results. The design will be discussed as part of legacy/trac#4562.We need to teach BridgeDB to give out pluggable transport information in its results. The design will be discussed as part of legacy/trac#4562.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5384Image Steganography for BridgeFinder2020-06-27T13:43:30ZTracImage Steganography for BridgeFinderRegarding the design of BridgeFinder, I suggest that it contains a plugin system in order to allow different inputs. In https://trac.torproject.org/projects/tor/ticket/5096 it is proposed to use QR codes but I think that this should not ...Regarding the design of BridgeFinder, I suggest that it contains a plugin system in order to allow different inputs. In https://trac.torproject.org/projects/tor/ticket/5096 it is proposed to use QR codes but I think that this should not be the only option.
One problem with QR codes is that they are clearly describing something that is hidden. So instead I propose an additional plugin that does steganography. In more detail I'm thinking of image steganography (although at a later stage one could add audio/video or others (random bytes)).
The basic idea:
A list of bridge addresses get sent to a trusted person. This person encodes the bridge addresse(s) into an image and sends them to a friend. This friend then decodes the bridge address contained in the image and uses it to connect to Tor (via BridgeFinder).
A bit more specific:
# The encoding will not alter the image signficantly so that it appears to be a valid unsuspicious data exchange (e.g. a holiday snapshot, avatar, signature).
# To encode the image a password needs to be entered that is known by both ends. Password suggestions:
# # a complex password known by both parties
# # name of a significant object in the image (this would allow external people easier access, on the other hand it would also allow the use of image sharing websites and blogs, automatic algorithms (object detection) to treat large amounts of images would be difficult).
# # I can also think of images that contain no password at all. But of course that would make it easier for censors to find them and block the bridges.
# The decoding process must be computationally expensive in order to avoid dictonary attacks.
# The algorithm for decoding contains automatic error correction as well as data verification.
Let me know what you think about this idea. If it is worth pursuing I can do the coding.
**Trac**:
**Username**: seamanGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5481Deploy recaptcha support for https distribution strategy2020-06-27T13:43:29ZKarsten LoesingDeploy recaptcha support for https distribution strategyFrom [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "13. bridgedb: Deploy recaptcha support for https distribution strategy. Right now our bridgedb service is getting bombarded by automated bridge requests, which look an awf...From [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "13. bridgedb: Deploy recaptcha support for https distribution strategy. Right now our bridgedb service is getting bombarded by automated bridge requests, which look an awful lot like an adversary trying to enumerate all the bridges. If we stick a manual captcha step in, we force them to move forward at the arms race."
From talking to Aaron in December:
1. We have recaptcha support merged into BridgeDB, but it is currently not enabled. (legacy/trac#1836)
2. Two subtasks of this deliverable should be "Move bridges.tp.o to a Tor VM" and "Get aagbsn access to bridges.tp.o." (legacy/trac#2301)
3. There is some question as to how Google will react to the recaptcha implementation. We should talk to Google people before enabling it. Aaron is going to talk to them, possibly after an introduction by Mike or Jake.
AFAIK, 2 is in progress and 3 and 1 have not been started.
Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?
Optimistically assigning to the July milestone.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5482Annotate and sort the social-network bridge pools by stability and reachability2020-06-27T13:43:29ZKarsten LoesingAnnotate and sort the social-network bridge pools by stability and reachabilityFrom [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "15. bridgedb: Annotate and sort the social-network bridge pools by stability and, once we have it, reachability. Right now we send a daily list of 50--100 bridges out, and...From [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "15. bridgedb: Annotate and sort the social-network bridge pools by stability and, once we have it, reachability. Right now we send a daily list of 50--100 bridges out, and half or more of the bridges are down the next day. We should track which bridges are up day after day and make them clearer in the list."
From talking to Aaron in December:
1. I think that my [tech report on bridge stability](https://metrics.torproject.org/papers/bridge-stability-2011-10-31.pdf) may be useful for the "stability" part of this deliverable. We'll want to include some bridge stability information in the bridge lists and maybe rank bridges by their stability value. (legacy/trac#3223)
2. The "reachability" part could be the same blocking information that we use for deliverable 17. We can probably just copy this information from the given file to the bridge lists. (legacy/trac#3224)
Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?
Optimistically assigning to the July milestone.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5484Make BridgeDB leave out blocked bridges2020-06-27T13:43:29ZKarsten LoesingMake BridgeDB leave out blocked bridgesFrom [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "17. bridgedb: learn to take in a list of bridges blocked in a set of countries, and learn what country a user is asking for bridges in, and leave the blocked bridges out o...From [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2): "17. bridgedb: learn to take in a list of bridges blocked in a set of countries, and learn what country a user is asking for bridges in, and leave the blocked bridges out of the answer we provide. We'll want this building block once we have bridge reachability testing working."
From talking to Aaron in December:
1. The current BridgeDB code contains a function to accept a list of blocked bridges by country to give out non-blocked bridges to users (legacy/trac#1837). This code needs testing. Also, there is a bug with how BridgeDB learns which country a user is interested in getting un-blocked bridges for, which currently conflicts with the language selection.
2. There are at least three approaches for giving out non-blocked bridges to users: a) exclude blocked bridges from results, b) replace blocked bridges with non-blocked once, or c) include blocked bridges in results and write "maybe blocked" next to them. We're currently doing a), but we should do c) to improve usability. There are variants of b), e.g., b1) Christian suggests to give out exactly one non-blocked bridge if otherwise we’d give out zero bridges and b2) Roger suggests to give out the first three non-blocked bridges in a fixed set of five bridges. One part of this deliverable should be to discuss these alternatives and agree on one of them that shall be implemented.
Can we agree on some schedule when these substeps and the overall deliverable are expected to be done?
Optimistically assigning to the July milestone.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/6513Set up separate bridge email autoresponder for SponsorJ2020-06-27T13:43:26ZRoger DingledineSet up separate bridge email autoresponder for SponsorJSponsorJ wants us to give out the 75 fast bridges through a separate email autoresponder mechanism from bridgedb's bridges@tp.o.
Since these bridges will be mostly static, I think the right way to start out would be to just have a stati...SponsorJ wants us to give out the 75 fast bridges through a separate email autoresponder mechanism from bridgedb's bridges@tp.o.
Since these bridges will be mostly static, I think the right way to start out would be to just have a static string get returned -- the same three bridges from our list. When those stop working, we can reevaluate what to do next.
It would be great to have this set up by mid August. Aaron, are you a good person to pop one of these up next to / part of bridgedb?